Category Archives: webstandards

The SWFFix alpha is up

Posted on by

Bobby put up the SWFFix alpha earlier today – I’ve been at the Ajax experience (with no wireless internet access, wtf?!) so haven’t had time to put together a post about it, but here’s a quick one.

We also announced that we are now working with Micheal Williams from Adobe – the author of the Adobe Flash Detection kit to make sure SWFFix can cover all the bases and be used by anyone. Very cool!

Go check out the dev blog and grab the files, then read the docs and try it out. Feedback is very welcome, so soak it in and let us know what you think.

Announcing the SWFFix project

Posted on by

SWFFix is a new joint project from myself and Bobby van der Sluis. The project’s goal is to replace SWFObject and UFO with a single method that is (hopefully) more standards compliant and doesn’t rely entirely on Javascript.

We’ve put up a dev blog on the site, and will be asking for help and feedback throughout the development cycle, so head over and watch the blog for updates in the coming weeks.

Bobby also has a great A List Apart article out today that talks about the problems with current Flash embed techniques.

Flash vs. Ajax

Posted on by

I’ve been hearing a lot of Flash vs. Ajax arguments lately, and unfortunately, they almost always start off in the wrong way.

It’s very common to hear people argue about Flash websites or RIAs vs. Ajax websites or RIAs, but this is always the wrong way to approach building any website. Would you have an argument with an architect about whether to build a house out of wood vs concrete? Of course not, they would use each material to build the parts of the house that the respective material is best for. Sometimes you might want to build a shack or barn out of all wood, sometimes you might want to build an all brick house, but many times you’ll want to use the best material for each section of the house. Build the foundation out of concrete, the walls and roof out of wood.

Websites and web applications should be treated the same way. Break things down to a component level and go from there. Use the right tool for each component. If you can do it well with HTML/Javascript, go for it. If it would work out better with Flash, then why waste time recreating something with Javascript that you could build 3 times faster with Flash? There are plenty of great examples of this today around the internet:

One of my favorite examples is Google Finance. They use HTML and Javascript for the stuff that is best suited for that, and then when they need to show a nice graph, they drop in a great interactive Flash graph and talk to it using Javascript as needed. The Flash controls the Javascript, and the Javascript can control the Flash as needed.

Another example is Flickr. They started out using Flash to display all of the images, including the image notes and the other toolbar options along with each image. While this might have been a good choice as the site started out, it was soon replaced by a more efficient HTML version of the toolbar and notes system that works just as well as the Flash version. They did end up keeping one small bit of Flash so users can rotate images and see a preview before they save it.

So the next time you start planning a website and you start thinking: “Hmm, Flash or Ajax?” Instead of looking at it from a site-wide perspective, try thinking about your site as a series of components, and then choose Flash or HTML/Javascript for each individual component instead.

Using progressive enhancement with Flash

Posted on by

There’s a fantastic article on Adobe’s devnet site that Bobby wrote (he’s the guy who wrote SWFObject’s biggest competition, UFO*). All about progressive enhancement with Flash. It includes helping your Flash content get picked up by search engines, supporting people without the Flash player, and a ton of other good info. Go have a read.

* But hey, it’s not really a competition, use whatever works best for you.

On embedding Flash content using Web Standards (yes, again)

Posted on by

Lately there’s been a bit of buzz around embedding plugins while adhering to Web Standardsâ„¢. First this ALA article came out and said “bye bye embed”, then yesterday one of the WaSP nerds posted something about “Valid Flash, video and audio embed (object) markup”.

It’s understandable to want to try and force browsers to display your plugin content in a way that adheres to “Web Standards”. It’s a very popular subject, and it’s been covered a few times before. These two recent articles don’t uncover anything new, other than bringing to light (via the comments on them) that Javascript is the only viable method of embedding Flash (and other plugin based) content on the web today.

Now I’m going to say something here that might seem a little controversial, but I really want to get the point across, so I’m going to use some ‘shock and awe’ tactics:

Using only the object tag to embed your plugin content (especially Flash content) is fucking stupid.

There. I said it.

You may say that I’m a bit biased because I wrote some fancy pants Javascript Flash embed script. Maybe I have a hidden agenda of world domination based on plugin detection. So while I no doubt would like to dominate the world, let me say that my reasons for advocating the use of Javascript are much more mundane.

This post was originally going to be titled “Flash Satay considered harmful,” and since the main topic are these “Web Standards” compliant ways of only using the object tag to embed plugin content, I’ll focus on the issues with doing so:

  • “Click to activate” in IE. The only way to get around this is to use Javacript.
  • No plugin detection. While Ben says ‘meh’ to this, it’s a very important aspect of the user experience. If I have Flash Player 6 installed, and I visit a site that uses Flash 9 content, my player will go ahead and try to play that swf anyway. I could end up seeing half of the content, or broken content, or who knows what. Do you really want to show your users broken content?
  • Issues in older Safari versions: Safari pre 1.2 will completely ignore param tags, which are often used to pass information to the plugin. This means broken content for your users.
  • Support for the object tag varies widely from browser to browser. Do you think that just because you work around all the quirks in the 3 main browsers today, it will still work when the next new browser is released?
  • A bug in Flash Player 9 can cause the browser to crash if you have more than one swf on the page and are using ExternalInterface to communicate with Javacsript. While this isn’t specifically related to how the swf is embedded, SWFObject does include a fix for this issue.
  • Using Flash Satay or other ‘object only’ methods will not stream your Flash movies to the user – this means extra work for you in creating a ‘loader’ swf
  • JAWS will ignore it.

It’s a pretty long list, right? Now if you compare that to the user experience when using SWFObject (or other Javascript based techniques), you can see a noticable difference:

  • The only time a user doesn’t see Flash is if they have Javascript turned off, or they don’t have the required version of the Flash Plugin. This one is a two parter: One, do you think that people really turn off Javascript but leave Flash on? Consider the type of person who turns Javascript off. They are probably the über nerd user who considers anything that isn’t text to be completely evil. They browse the web using Lynx. They probably stay a mile away from the Flash Plugin anyway. The beauty of the way SWFObject works is that even these people get content if you set it up right. Since you put alternate content ‘under’ your swf, they will just see the alternate content. As long as you set it up right (you do, don’t you?) they may never even know they are missing out on Flash content.
  • They don’t have to click your movie once to ‘activate’ it
  • Their browser doesn’t crash just because you had two swfs on the same page that use ExternalInterface
  • They only see Flash content if their browser and plugin support it.

Taking all of the above into account, the choice is very clear: Javascript wins hands down. Any questions?

Now that all of that is taken care of, I wanted to address a couple of things:

First, these types of posts are not good for the Web Standards community. Basically what’s happening is highly visible people (even if they aren’t that well known, they still carry the WaSP name, or have articles on well respected online publications like A List Apart) are posting information that is bad for your users. Even worse is that they are doing it in the name of “Web Standards” and not taking into consideration any of the other options outside of pure HTML. This is extremely bad for the Web Standards movement. It makes the standards advocates look like crazed zealots who don’t care about user experience, but only care about adhering to the written rules exactly how they are stated even if it hurts them.

Second, you may be saying “well, if I can’t use the object tag, then what good is it?” and that is a FANTASTIC question. What good is it? Beats me, because the object tag is completely and utterly broken in nearly every web browser out there. Want to do something about it? Maybe you could join WaSP and create a task force to fix how browsers handle plugins?

UPDATE: I added this as a comment below, but wanted to put it in the main post as well: I want to say that as for Flash Satay: It was fantasic for the people who use(d) it, and in it’s time it was great. But now that certain big issues with it have been discovered, and Flash has changed over time, it’s time for it to retire. This is something I’ve been meaning to mention for a while, and it was sort of implied on the SWFObject page. So, since we are on the subject, it’s time to give it up.

UPDATE (8-17-2006): Ben has posted a follow up.