With the announcement of Flash 8 today, Macromedia also quietly pushed out their new detection kit. The detection kit has has been around for the last few versions of Flash, and usually changes with each version to include whatever the latest trends in Flash detection are.

It’s no wonder then, that the latest version uses Javascript as the suggested detection method. Unfortuntely, it’s not perfect. While it’s a good first try, it is greatly lacking in a few basic needs of most web developers. Here’s the issues I have with it:

• Inline Javascript code (and lots of it) – Who wants to copy a bunch of Javascript and VBscript onto every single page that uses Flash? While it might be possible to move the Javascript into an external file, you would still have a small amount of VBScript on each page (or another external file to include). I’m not sure why they decided to leave in the VBScript when there are other reliable ways to create and test for ActiveX objects. Also: what happens if you need to upgrade the Javascript for some reason? While the code should be very futureproof, you never know when a bug might pop up, and you’ll be stuck editing all of your HTML files that have Flash movies included in them.
• Tough to modify the code – It suffers from the same drawbacks as most Javascript embed techniques – placing tons of Javascript document.write() calls and writing out your object or embed tags to the page. This is a hassle to edit if you need to make changes, and makes it very tough for designers who don’t know Javascript to go in and modify attributes.
• It’s not valid HTML or XHTML – Valid XHTML documents aren’t for everyone, but when you have clients specifically asking for them it’s nice to be able to deliver. The new detection doesn’t even come close to validating.

If you want to compare the new Macromedia detection to my FlashObject script, check out this new article that shows how to use it:

Best Practices for Flash Player Detection

Then compare the steps needed to get that working with using FlashObject:

1. Include single .js file.
2. Add a few lines of code (see example of bare minimum).
3. Sit back, relax.

I think the choice is clear.

Now when you downloaded the new detection kit you may have noticed another folder hiding out in there with the name of “Express Installation.” This is Macrmedia’s new way of upgrading your Flash player without the need to go to macromedia and download the new plugin. I’ll be writing up a new entry soon that gives some tips and best practices on using this method in the very near future.

UPDATE (7-24-2005): This page refers to an old version of the FlashObject script. For questions or comments, or to download the script, please refer to the permanent home of the FlashObject script.

This post is a continuation of a previous post. Read this for more background information on the FlashObject embed method.

In the months since I posted the FlashObject embed I’ve had a chance to talk to a number of developers and use it in a few high traffic projects. In doing so I’ve picked up some tips and best practices that I’ll be outlining here. I’ve also revamped the FlashObject script so it’s a bit more light weight and fixed a few small bugs.

What’s new?

1. Alternate content is no longer written to the page by default – You may still use the fo.altText variable to add alternate content to your pages, but it is not recommended. The way to display alternate content in your pages with Flash content would be to place the alternate content on your page, and then specify the ID of the element with your content inside. The FlashObject script then writes your Flash content inside that element, replacing your alternate text/content so the end user with Flash will never see it, but users with no Javascript or without the required Flash version will see the alternate content. Google will also index your alternate content since it is just plain HTML.

   Here is an example of what your embed should look like:

   <div id="flashcontent">
     Place your alternate content here and users without the Flash plugin 
     or with Javascript turned off will see this. 
     Include a link to <a href="?detectflash=false">bypass the detection</a> 
     if you wish.
   </div>
   <script type="text/javascript">
    // <![CDATA[
     var fo = new FlashObject("fo_tester.swf", "fo_tester", "300", "150", 6, "#336699");
     fo.write("flashcontent");
    // ]]>
   </script>

   Because of this change, you should always specify the ID of an element to write your Flash content into. You should also be sure to always include alternate content on the page. If your Flash movie is purely decorational, you can leave the div empty, similar to using empty alt attributes (alt="") on decorational images. Also note that with the new version you need to place your Javascript that writes the Flash content after the element that will contain your Flash content, as in the example above.

2. Support for pulling variables from the URL string when using anchors – There have been some discussion about Flash state tracking and direct or ‘deep linking.’ Most of the methods rely on parsing variables from the URL when the movie loads, so now you can pull vars out using the built in function getQueryParamValue().

   Example:

   If your URL is:

   flashobjectpage.html#var1=value1&var2=value2

   You can pass those vars into your Flash movie by using the following code:

   var fo = new FlashObject("fo_tester.swf", "fo_tester", "300", "150", 6, "#336699");
   fo.addVariable("var1", getQueryParamValue("var1"));
   fo.addVariable("var2", getQueryParamValue("var2"));
   fo.write("flashcontent");

   The same works for normal URL parameters in URLs such as:

   flashobjectpage.html?var1=value1&var2=value2

Just to recap some of the things posted in the previous FlashObject post, here’s some of the thinking behind the FlashObject embed method:

Why Javascript?

Javascript is the best overall solution for a number of reasons, among them:

1. With Javascript you can detect the presence of the Flash Player on your user’s system and either display the Flash content or leave the existing (X)HTML on the page. This is also a huge advantage when it comes to search engine indexing since the alternate content is on the page and will be indexed as normal content. This also prevents novice users from seeing Internet Explorer’s ActiveX install box, which on Windows systems pre-SP2 is a very scary thing these days with all the Spyware and Malware running around on the internet. On most other browsers, you’ll likely see some empty box where the Flash content should be, sometimes with a broken image or puzzle piece icon which most novice users have no idea what to do with (Should they click on it? Is it part of the site?). If you include well written upgrade/install instructions in your alternate content, all of these problems are avoided.
2. No Extra configuration files for each Flash movie. Some alternate methods of embedding Flash content in XHTML documents include using extra configuration files or ‘holder’ movies that load in other movies. With this method there is no need for any extra files aside from the single .js file.
3. Easy to serve different content to different browsers. I worked on a project recently that made extensive use of the wmode=transparent option. Well when you are using IE or Firefox you can use wmode=transparent with the Flash 6 player, but if you are using Apple’s Safari browser, you need Flash player 7 to see the content properly. So in the embeds on the page, we required Safari users to have the Flash 7 player, and everyone else the Flash 6 player. Without Javascript we would have had to force everyone to upgrade to Flash player 7, something we didn’t want to do, even though the Flash 7 player has a pretty high penetration percentage.

Problems with Flash Satay/pure Object tag embedding

The main issue with using any embed method that uses only object tags to embed any plugin on a page is that Safari ignores the param tags. For very basic embeds this isn’t a problem, but when you want to start passing in variables or change the background color of the movie without re-publishing it you start to run into problems.

The one area where using pure object tag embeds shine is in using XHTML pages that are sent with a mime type of application/xhtml+xml. Since the FlashObject script uses innerHTML and sometimes document.write, it is not compatible with pages sent with the application/xhtml+xml mime type. Currently I have no plans to update it to work with these pages, as there are many issues with creating object tags using the DOM because almost every browser engine handles it differently and has little quirks that make it very hard to work around. If you are interested in seeing some of the code it would take to embed Flash in XHTML documents, check out the excellent Javascript that comes along with sIFR 2.0.

Download

Download the source to FlashObject 1.1.1.

Download the source to FlashObject 1.3.

View sample pages using FlashObject 1.2 in different Flash embed situations.

UPDATE (5-5-2005): If anyone is interested, Paul Newman has wrapped this script into a Dreamweaver extension. It costs $15 (or free to CommunityMX subscribers), but if you are a not-so-technical Dreamweaver user I think it would be worth it.

UPDATE (5-17-2005): Made a small change to the embed tag output. I changed the id attribute to a name attribute as Firefox needs it that way in order to use LiveConnect and talk to the plugin via Javascript.