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.
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:
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:
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:
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.
Search engine optimization is one of the most popular subjects when nerds sit around and talk about Flash. “Does Google index your swf files?” seems to be the most popular question, usually garnering plenty of ‘yes‘ and ‘no’ and ‘maybe’ answers. The real answer to this question, once and for all, is this:
It doesn’t matter.
To understand this answer, you need to understand what Flash is. And to do that, you need to understand modern web development philosophy. First off, you need to embrace web standards. Semantic markup and separating content from style and behavior is the only way you should be building your sites. Many web standardistas have been recommending this method of web development for years, and rightly so. However, this post isn’t the place to go into the whys of this type of development, so I’ll skip that part and just say this about how it’s done: There are three areas of front-end web development: Content, Style, and Behavior. You should always keep these three things separated as much as possible.
That brings up the question: “Where does Flash fit into this three pillar method of web development?” Is it content? Is it behavior? Is it style? While it could be considered all three, most professional Flash developers will remove the content from their Flash movies and load it in using Flash remoting or XML files. That leaves us with style and behavior.
Style is added using CSS. Generally when you add images to your HTML that are purely presentational (no text or required content in them) you should add them in using CSS. In most cases you don’t want Google to index them because people don’t search the web for ‘top left rounded corner gif.” They search for content. Even if Google upgrades their crawler someday to read CSS files and index the images, they probably wouldn’t use the information for more than statistical analysis because of this.
Behavior is generally added using Javascript. Maybe you want a new window to open set to a certain size, or you want to use some fancy Ajax to let users rate something without refreshing the page. This should all be added unobtrusively, and if the browser doesn’t support Javascript, it will hopefully still work. Unfortunately, not everyone considers this, and these days Javascript is becoming more and more of a requirement to use most websites. So you should always provide some sort of alternative for non-Javascript users. When it comes to indexing behavior, Google will for the most part not index your Javascript files. Even if it did, most web users would have no idea what the .js file they are looking at actually does. When using Javascript to change your document, Google will not read the ‘final’ page, but only the raw HTML file. Google does not render Javascript 1.
Now that you know all of this, it’s time to look at how to treat your Flash content. Since we’ve determined we don’t want Google to index our swf files, but we do want it to index the content displayed inside them, what is the best way to go about this?
As stated before, if you are building Flash sites professionally, you probably move all your content out of your Flash movie and into an XML file or keep it in a database. This makes it much easier to allow Google to index this content by using progressive enhancement.
Progressive enhancement is a method of web development that goes hand in hand with Web Standards. You start with your HTML (your content), then add CSS (your look and feel), then add in additional behavior (Javascript, Ajax, Flash, any other interactivity that isn’t handled automatically by the browser).
The best way to add Flash progressively is by using Javascript, or more specifically, a script like FlashObject. First you lay out your page as if you aren’t using Flash. If you are using a database for your content, you can spit out that data as HTML where the Flash movie will go on the page (or maybe just a preview of the content, it’s up to you to show Google the content you would like indexed). Then you use FlashObject to replace this content only if the user has Javascript enabled and the required Flash plugin version.
Here’s a small example of what that might look like:
<div id="flashcontent">
This is replaced by the Flash content if the user has the correct version of the Flash plugin installed.
Place your HTML content in here and Google will index it just as it would normal HTML content (because it is HTML content!)
Use HTML, embed images, anything you would normally place on an HTML page is fine.
</div>
<script type="text/javascript">
// <![CDATA[
var fo = new FlashObject("flashmovie.swf", "flashmovie", "300", "300", "8", "#FF6600");
fo.write("flashcontent");
// ]]>
</script>This causes Google to skip the Flash swf files and only index the HTML (the content!) you place on the page. You can place links to other pages, images, whatever you want Google to index, and when a viewer with a browser that supports Flash visits your site, they will then see the Flash content. This gives you full control and much greater predictability over what content Google will index. And if your content is pulled from a database that is editor controlled, your pages will update and be re-indexed as the content changes without the need to re-publish all your swf files.
1 Currently Google does not render the Javascript on a page, but there are rumors that they are developing a new crawler based on Firefox (they employ a number of Mozilla foundation members) that will index pages based on how the browser sees them, instead of the raw HTML content. This means HTML hidden by CSS may not be indexed, and pages that are altered by Javascript after they load will be indexed how they appear to the user. However, this is all rumors and until it happens Google will ignore your Javascript content.
Note: In this article I use the ‘Google’ name often, but it can be interchanged with any search engine, as they all work roughly the same way.
David Flanagan (you probably have his O’reilly Javascript book next to your desk right now) has been doing some experimentation with exposing the Flash drawing API -vector, not the bitmap stuff (yet)- to Javascript. In his example he uses the ExternalInterface class to expose a few of the drawing methods and then uses those to draw shapes in the Flash movie.
His example only had an embed tag, so here is another example embedded with FlashObject so you IE people can see it too.
Note: Opera does not support ExternalInterface (yet), so if you want to see it in action, use just about any other browser. Opera users: you may want to take a moment to send a new feature request to Opera and tell them to add in the NPRuntime stuff so this will work!
There’s an interesting article over on the Macromedia Accessibility blog. They take a look at some popular Flash embed techniques and see how they perform in screen readers. The thing that caught my eye, though, was the performance of the Flash Satay embed method. It looks like if you are using Flash Satay, JAWS won’t read your Flash content.
Unfortunately, they didn’t test FlashObject, but they did test UFO – which works in a very similar way – so I think it’s pretty safe to say that they would behave the same way in a screen reader.