Flash is a third party file type that may not be supported by your site visitor’s browsing software. It’s our job as Web developers and designers to ensure Flash movies are as accessible as possible and to provide relevant alternate content when required — as recommended by the W3C.
This is accomplished by employing Flash Player detection.
This article will show you how to do just that. It will give a survey of current and future detection methods, and will put forward ideas and solutions to give your users seamless access to your Flash data — along with access to alternate content if their installed Player happens to be below the required version.
We will look at client side detection using Javascript and Microsoft’s VBScript for Internet Explorer on Windows, inbuilt version detection and markup based detection. Server side detection, available since Flash Player 6.0r65, will also be discussed.
I’ll round out the discussion with recommended detection techniques for different situations, and finally, I’ll provide some links to further reading on the methods discussed here.
So let’s start!
About the Macromedia Flash File Format
Macromedia Flash content for the Web is encapsulated in an open file specification (SWF) and generated by proprietary authoring software such as Macromedia Flash MX, Adobe Livemotion, Swift3d and Swish.
The SWF file format is non-native to browsers. That is, the graphical browsers we use, such as Mozilla, Safari, Opera and Internet Explorer cannot run SWF files on their own, as they can HTML, XML, GIF, JPG and PNG files. To handle SWF content, browsers require the free Macromedia Flash Player.
Macromedia Flash Player handles the Shockwave Flash (SWF) and FutureSplash (SPL) file formats (FutureSplash was the precursor to Shockwave Flash). SWF is by far the more populous of the two so I’ll focus on this file format for the purposes of the article.
Flash Player has been a standard third party plugin for Web browsers since the late 1990s. Flash Player 3 was the first to have significant impact in the market, dot syntax was introduced in Flash Player 5, and the current Player, version 6, has the highest uptake rate of any Player released to date.
The Flash Player comes in many forms:
- A standalone player
- A plugin for browsers that support the Netscape Plugin API
- An ActiveX control for Internet Explorer browsers running on Windows operating systems
As a matter of semantics, whenever I refer to the Flash Player throughout this tutorial I am referring to the downloadable plugin available at http://www.macromedia.com/go/getflashplayer — not the standalone Flash Player packaged with Macromedia Flash MX.
Finally, all Flash Player versions incorporate minor releases. These are described throughout the article as, for instance, 6.0r65, meaning the 65th version of Flash Player 6. It’s a bit like WD40 (#40 being the attempt upon which they got the mix just right). Bet you didn’t know that!
Why is Flash Player detection required?
As noted above, it’s because the SWF file is not handled natively by browsers that we need to employ some form of Flash Player detection to ensure that our SWF movies run smoothly, or not — as the case may be.
Other reasons why we need to employ Flash Player detection are:
- Flash Player can be optionally installed and uninstalled.
- Some browsers have the ability to turn off plugins.
- ActionScript for the latest Player may not run in older Flash Players. This is most evident with the transition from Flash Player 4 slash syntax to Flash Player 5 dot syntax. Furthermore, Flash Player 6 classes such as LoadVars, callback functions and dynamic loading of JPEG images are not supported by older Players.
In my opinion, detection should be viewed as a way of ensuring:
- Smooth deployment of the movie for targeted versions
- Transparent identification of older versions and
- Deployment of appropriate alternate content as per the W3C recommendation and a link to the Flash Player download page if required. The user should be provided with an option to upgrade if they wish.
Flash Player detection is not something that we should just slap onto the start of a Flash application or site as an afterthought. Poorly executed detection scenarios can present an insurmountable barrier to users who want to access Flash or alternate content.
Remember above all else who your target audience is. A Flash site lacks in the accessibility and usability stakes if you prompt the user to
“click here if you have Flash Player 5 or greater”
A Web user shouldn’t have to decide this (and how many of them know what version they have installed?), regardless of whether we present the user with a plain text choice to alleviate potential accessibility issues. As developers, we should employ transparent Flash Player detection methods in all scenarios.
Which Version Do I Target?
The release of each new Flash Player typically offers attributes that aren’t found in previous versions (see the Flash Player 7 link at the end of this article). Features such as dynamic loading of Jpegs, the XML object, LoadVars and movie clip event handlers are just some of these.
Which version of the Flash Payer you should target will depend on your target audience. If your audience is Flash developers, it’s most likely they will have the very latest (or near to that) Player installed. On the flip side, the general public tends to be wary of downloading plugins and ActiveX controls — they tend to lag behind by a version. In this case, it might be good to use Flash Player 5 ActionScript to ensure maximum playability, with a view to upgrading as your user base grows more accepting of the technology.
I generally don’t develop for version 4 or less, as at Flash Player 5 the transition to dot syntax took place and ActionScript grew immensely. Designers, though, may want to deploy for Flash Player 4 if they’re using simple motion tweens and very basic ActionScript. Bear in mind, though, that doing this will only increase the impact of your movie by a few percent.
At the time of writing, Flash Player 5 is by far the best version to target in order to reach the widest possible audience — although Flash Player 6 is growing at a considerable rate.
Handling the Flash Player Download
For the average Website visitor, being prompted to download and install anything on their machine so they can view content can be a hair-raising affair. Many site visitors are extremely wary of installing anything on their machine that they think could cause harm to it, and wisely so.
It’s our job then to make the download and install a seamless, friendly process. What we want to avoid are any ActiveX pop-up windows or automatic redirections to Macromedia’s Flash Player download page. User experience tells us that these can turn visitors away in droves.
An ActiveX warning: scary, isn’t it?
The Opera7 version — less intimidating, but still pretty uninformative for the non-Web savvy user (that ‘click’ button is the Flash movie).
What we want to achieve is a more sensible method of ensuring download of the Player if it is required — one that matches our site design and leaves the user in complete control of the download process.
The first thing to do is employ some standards-compliant markup — which you’ll see in use throughout the code in this article. The advantage of writing markup like this is that it allows us to deploy a consistent download experience to all compliant browsers.
Here’s what we need to do:
- Remove the Netscape specific Embed tags — Mozilla , Safari, IE5+Mac and Opera7 will still run your movie just fine with a few tweaks.
- Change the codebase tag from the default Internet Explorer specific attribute to the W3C recommended attribute.
- Place alternate, descriptive content within the object tags, after the optional param tags — as specified by the W3c recommendation.
Note that, for users of Internet Explorer on Windows who have no Flash Player, changing the codebase attribute like this will cause their browser to do one of three things (depending on the user’s ActiveX security settings for “unsigned” controls):
- Prompt: A pop-up window will appear with selections of Yes, No, and More Info.
- Enable: The browser will attempt to render the Flash object, fail, then display the alternate content as noted above.
- Disable: The browser will fire a warning saying it can’t render the object due to security settings, then render the alternate content within the object tags.
These responses are occur as a result of the way IE for Windows supports the object tag, not the W3C recommendation, and it should be noted that in all cases alternate content would be displayed.
If you don’t want this to happen, I suggest you leave the codebase attribute as default — you will need to reference your movie absolutely in both the data attribute and the movie <param> tag when doing this, so that all browsers can find it.
On the flipside, now that the embed tag has been removed from the equation, Mozilla, Opera7 and other compliant browsers will render the alternate content within the object tags if they can’t run the designated file. No annoying jigsaw pieces or popup windows will appear for these browsers — just your specified alternate content.
So there we have it — a reasonably robust way to maintain control over the Flash Player download process — in a transparent fashion. Moving forward, we can employ this code in all the detection scenarios to be discussed, starting with the “Manyana” method.
Do Nothing – The ‘Manyana’ Method
This, the Cosmo Kramer of detection methods, is a reflection of the impact that Flash Player has in the market — it’s such a prevalent third party plugin that, when used correctly, this method will have a good success rate. Current statistics put the population of Web browsers capable of handling Flash Player 5 content (the best player to target for general sites) at about 96%. At the time of writing, Flash Player 6 has an audience of about 80% and growing.
This method is the simplest to employ of all those described here. Use the Publish Settings (File>Publish Settings…) in Macromedia Flash to generate the required markup, then make any changes to the (X)HTML — your title tags, head tags, and CSS file linkages, for instance. All that’s required now is to put the files on the Web server.
You can also employ Flash publishing templates tailored to your project, as discussed in the Online Flash Help files.
That’s the biggest advantage — ease of implementation.
Major disadvantages include that there are no control methods in place to assist a site visitor when something inevitably goes wrong, and the fact that we’re assuming that most site visitors will be using Flash Player 5 and above. Things can go wrong if you serve Flash Player 6 content, for instance, to Flash Player 3, and there’s no support structure in place for the user. It’s good programming practice to ensure that we have appropriate fallback methods when something does go wrong, which means this is not the best method to implement for a general audience.
Code example
Below is the markup described in the section “Handling the Flash Player download”. The browser will attempt to run the file, or display the alternate content if it can’t.
Note that there is no version detection inherent in this method.
<object
data="manyana.swf"
type="application/x-shockwave-flash"
codebase="http://www.example.com/"
width="550"
height="400">
<param name="movie" value="manyana.swf" />
<param name="menu" value="false" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ededed" />
<p>
Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.
<br />
This text will be rendered if the user-agent cannot render the file specified in the object tag.
</p>
</object>When should this method be employed?
When you know accurately what Flash Player version is installed on your users’ computers. Examples include:
- Intranets with standardised settings.
- Sites for active Flash developers, who will generally have Flash Player 5 or later installed.
- When you are employing simple animations that are Flash Player 2 compatible.
When should this method be avoided?
- When you are building a site for an anonymous audience with unknown Flash Player versions — basically anything on the Web for the general public.
- When you are serving version-specific Flash content.
Of course, you can use this markup just as well when employing client side scripting detection…
Client Side Scripting using Javascript and VBScript
This method is the most widely used among the development community. It involves employing client side scripts to check for Flash Player version information, then uses conditionals (if…else) to determine what to do based on the results that are returned.
To employ client side scripting, we have to know how the Player is installed and handled by different browsers and operating systems.
All browsers, apart from Internet Explorer 5, 5.5 and 6 for Windows, handle the Player using the Netscape Plugin API. This means that once the Player is installed, version information is available to scripts via the Javascript Navigator.plugins array.
As with most things on the Web, the Internet Explorer versions noted above handle things differently. These browsers support Flash using Microsoft’s ActiveX technology and do not support the Navigator.plugins array. To detect version information in these situations, Microsoft’s own scripting language VBScript needs to be employed.
Luckily for us, Netscape-compatible browsers such as Mozilla, Netscape 7, Internet Explorer 5 for the Mac, Safari, Opera and Netscape Navigator 4 ignore VBScript entirely, and we can use this to our advantage when developing client side detection techniques.
Code example
Below is script that checks for Flash Player 6 on the user’s machine. If a version that’s lower than this is detected, or no version is detected, alternate, descriptive content is displayed — as per the W3C recommendation. Note that the script tags are XHTML compliant.
<script type="text/vbscript">
<!--
//check for Flash Player X
//script for IE on Win32 systems
on error resume next
//set a variable to hold the detection result
Dim checkForFlash6
//assign a boolean value
checkForFlash6 = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.6")))
//note here that if the object is demoted to ShockwaveFlash.ShockwaveFlash.5 or less, checkForFlash6 will still return true
//this is ok as Flash Player 6 can run previous version content.
//change 6 to 7 and you will see the alternate content (if 7 is not installed).
//check that Shockwave Flash Plugin 6 is available
//if false display alternate content, if true show object tag
//quotes need to be doubled in vbscript in order for IE to render them in markup.
if checkForFlash6 = true then
document.write("<object data=""index.swf"" type=""application/x-shockwave-flash"" codebase=""http://www.example.com/"" width=""550"" height=""400""><param name=""movie"" value=""index.swf"" /><param name=""menu"" value=""false"" /><param name=""quality"" value=""high"" /><param name=""bgcolor"" value=""#ededed"" /></object>")
else
document.write("Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.<br />This text will be rendered if the user-agent cannot render the file specified in the object tag.")
end If
-->
</script>
<script type="text/javascript">
<!--
//check for Flash Player X
//check the navigator.plugins array exists, IE for Windows will fail on this.
if(navigator.plugins.length)
{
//some variables
//a counter
var i;
var xhtmlContent = "<object data="index.swf" type="application/x-shockwave-flash" codebase="http://www.example.com/" width="550" height="400"><param name="movie" value="index.swf" /><param name="menu" value="false" /><param name="quality" value="high" /><param name="bgcolor" value="#ededed" /></object>";
var alternateContent = "Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.<br />This text will be rendered if the user-agent cannot render the file specified in the object tag.";
//loop through all the plugins installed
for (i=0; i < navigator.plugins.length; i++)
{
//put the plugin string in a variable
var pluginIdent = navigator.plugins[i].description.split(" ");
//The Flash Player identification string is ([] = the array index) [0]Shockwave [1]Flash [2]6.0 [3]r21
//if less than Flash Player 6 is detected, run this code.
if(pluginIdent[0] == "Shockwave" && pluginIdent[1] == "Flash")
{
//set a toggle to show that some sort of Flash Player (of versions 1-5) was found
var isSwfEnabled = true;
//an array of the Flash version number (major.minor)
var versionArray = pluginIdent[2].split(".");
if(versionArray[0] < 6)
{
//show alternate content
document.write(alternateContent);
}
else
{
//Flash Player 6 or greater has been found, roll out the <object> tag.
document.write(xhtmlContent);
}
//need to break this loop as some browsers may have two versions installed
//eg my Firebird release has r65 and r79 installed!
break;
}//end if pluginIdent
}//end for
//check if no Shockwave Flash was detected in the array (no Flash Player installed)
if(!isSwfEnabled)
{
document.write(alternateContent);
}//end if
}
-->
</script>The code used above shows how alternate content can be deployed to a browser depending on the script results. It doesn’t utilise redirection, as I’m endeavouring to stick with the W3C recommendations in this article.
When should this detection method be employed?
This method currently has the best chance of getting the exact version information for nearly all visitors to a page. As such, it’s most useful when you’re dealing with an anonymous audience:
- Pages for the general browsing public.
- Intranet sites when Flash Player version is not known.
- When you want to show alternate content based on what the script finds.
When should this detection method be avoided?
- If the site visitor does not have scripting enabled on their machine, this method will fail. Your decision to check whether scripting is enabled should be based on the knowledge that approximately 98% of users will have client side scripting running. Employ <noscript> tags to get around this and supply alternate content in those cases.
- This method will not work in browsers that do not support client side scripting, such as Internet Explorer for the Mac versions 3 and 4. It’s time to be forward-compatible in this case, and if required a sniff can be performed for the small population of these browsers.
- When you want your alternate content available for access by screen readers.
- When you don’t want to bloat pages or lock your content up in script, which leads us to a few lightweight detection methods.
Cascading XHTML: the Object Tag
The object tag is the w3c recommended element for deploying any object within a markup based setting. “Object” in this sense means any non-text content, such as a Quicktime movie, a Java applet, an image, a Flash movie and so forth.
The recommendation states that if a browser has no way to deploy the content targeted by an Object tag, it should attempt to render the content held within the Object tag. If this is not possible, it should attempt to render the first available content it finds.
This is an elegant and accessible way to handle Flash detection. For instance, the first object tag can link to the required Flash movie, the next nested object tag could attempt to deploy an image. If this were not possible, nested in this tag would be some descriptive text about the movie.
It’s a wonderfully simple method, based on the cascading ability of the Object tag. It is the W3C recommended way for user agents to handle objects, and works in all standards-compliant browsers. In respect to Flash detection, it’s an extension of the “manyana” method described at the start of this article.
Code example
Below is the same valid XHTML described at the start of the article, with some additions:
<object
data="index.swf"
type="application/x-shockwave-flash"
codebase="http://<?=$_SERVER['HTTP_HOST']?>/sitepoint/flashdetection/testmovie/"
width="550"
height="400">
<param name="movie" value="http://<?=$_SERVER['HTTP_HOST']?>/sitepoint/flashdetection/testmovie/index.swf" />
<param name="menu" value="false" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ededed" />
<!-if no Flash Player present, render an image -->
<object
data="alternate.gif"
type="image/gif"
width="550"
height="400">
<!-if images turned off, or a text only browser, render the text -->
<p>Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.
<br />
This text will be rendered if the user-agent cannot render the Flash file or the GIF image.
</p>
</object>
</object>Alas, elegant as this detection technique is, and even though object is an HTML4 recommendation from 1997, this solution seriously lacks browser support. Internet Explorer for Windows will attempt to render all object tags present in the code, so you will see a Flash movie and a GIF image if the Player is installed.
In XHTML2.0, object will be the method used to deploy images, so we should hopefully expect better browser support for this in the future. For now, though, it is but a coder’s dream.
When should this method be employed?
- When you know that your site visitors are using standards-compliant browsers. For example, an Intranet with a Gecko-based browser used as default.
When should this method be avoided?
- When you’re dealing with an anonymous audience.
- When your audience uses predominantly Internet Explorer for Windows as a Web browser.
Note that version detection within the markup is unavailable, so if this is important (for instance, if you use Flash Player 6 ActionScript), use inbuilt version detection within Flash:
Inbuilt Flash Player Version Detection
Flash ActionScript itself has three ways of detecting the version of the Flash Player on the client computer:
$version(introduced in Flash Player 4 release 11) returns an operating system string together with version information (eg WIN 6,0,79,0)getVersion()(introduced in Flash Player 5) returns a similar string to$version- System.capabilities.version (introduced in Flash Player 6) according to Macromedia returns a version number (eg 6.0) but in my testing it returns similar information to
$versionandgetVersion();
ActionScript’s String methods allow the version information to be garnered from both $version and getVersion();
Which version detection method you use will depend on your target audience, something that cannot be stressed enough when developing Flash content for the Web.
Employing this method involves checking for the version number. If the version number is less than that required, take the user to a frame of the movie that displays some descriptive content and then prompts them to upgrade their browser. If the user has the required Flash Player, the movie can then continue loading.
Code example
Below is some ActionScript developed to handle the version detection. In my testing it worked well with Flash Player 4 and above. Flash Player 2 and 3 failed the test and displayed a blank movie — probably due to the ActionScript used. Note that some of this code is used with the Server Side detection technique described further on in this article.
function checkPlayerAgainst(requiredPlayerVersion, thisPlayerId)
{
//----- first get the user's player information -------//
//make an array of the client player's version numbers
//thisPlayerId will be "WIN 6,0,21,0" or similar
thisVer = thisPlayerId.split(",");
//get rid of the gunk before the major player version number
//eg "WIN 6" etc - the first entry of the array will old OS information
thisVerSpaceNum = thisVer[0].indexOf(" ");
//finally, a major version number (eg 6)
thisMajorVer = Number(thisVer[0].substr(thisVerSpaceNum));
//---------------------------------------------------------------------//
//if the passed variable is not set
//or the major version number is equal to the minimum required
if(thisPlayerId == false || (thisMajorVer == requiredPlayerVersion))
{
gotoAndStop("upgrade");
}
//if the major version number found is greater than the required version
else if(thisMajorVer > requiredPlayerVersion)
{
//play the movie
gotoAndStop("init");
}
//default to upgrade information
else
{
gotoAndStop("upgrade");
}
}This function is called by the following code:
//Flash Player <4 doesn't like >=
//so set minimum to 5 if checking for 6
//set minimum to 4 if checking for 5 and above
minimumVersion = 5;
//just for display
youNeed = minimumVersion+1;
//get the installed Player version
installedVersion = getVersion();
//less than Flash Player 5
if(installedVersion == "")
{
//debug = "mime type not found";
gotoAndStop("upgrade");
}
//Flash Player 5 or later
else
{
//Flash Player 6.0r65 or later and mime-type found
//the mime-type can be found using server side detection
if(skipVersionCheck=="true")
{
gotoAndStop("init");
//debug = "skipped version check as mime-type was found";
}
//Flash Player 5 or later and mime-type not found
else
{
//debug = "mime-type not found";
checkPlayerAgainst(minimumVersion, installedVersion);
}
}
stop();When should this method be employed?
- When you are sure whether users will have Flash Player 4r11 installed as a minimum. Note that this method doesn’t break with Flash 3 and 2 — the movie starts but doesn’t run, probably due to the ActionScript involved.
When should this method be avoided?
- When you may have a significant number of Flash Player 2 and 3 users (unlikely).
- When you want to provide markup based alternate content for users with less than the required Flash Player version.
This detection method fits neatly with what is probably the most elegant of all Flash Player detection scenarios, server side detection:
Server Side Flash Player Detection
This method uses scripting languages such as PHP, Coldfusion, Perl and the Microsoft stable of server side languages. No client side version detection is required, as this detection method can be handled internally by Flash ActionScript itself.
Macromedia’s release notes for Flash Player 6 state that the Flash mime-type “application/x-shockwave-flash” is added to the HTTP-ACCEPT header when Flash Player 6 release 65 or later is installed on all available browsers. On the face of it this is great — it takes Flash detection away from an unknown browser and places it in a stable, managed environment.
In practice, though, we find that this method still relies on support from browsers. Mozilla allows the mime-type to be written to its header, Internet Explorer 6 allows the same to happen but does not send the header when the page is refreshed, and no changes are made to Opera 7’s header at all.
Don’t worry. As with most things on the Web there is a workaround — in this case relying on the Flash Player footprint and inbuilt version detection.
So how does this work?
The HTTP-ACCEPT header that’s sent to the server includes a listing of all mime-types the browser can handle, such as text/html, image/gif etc. When the latest Flash Player is installed, it attempts to add this entry to the header:
"application/x-shockwave-flash"Using PHP, for instance, we can check whether this string is present in the header:
<?php
//flash detection -- search the HTTP_ACCEPT string for the Flash mime-type.
//use $HTTP_ACCEPT for PHP versions <4.1
if(eregi("application/x-shockwave-flash", $_SERVER['HTTP_ACCEPT']))
{
$hasFlashSupport=true;
}
//eregi is the string (case insensitive) comparison function in PHP
//it will return a true or false depending on whether the substring is found
?>What an elegant solution to Flash detection! If the variable $hasFlashSupport is set to true, we can assume that Flash Player 6 .0r65* or later is installed. We can also send markup to the browser based on what is found in the HTTP-ACCEPT header, rather than rely on client side scripts rendering alternate content, and so cut down on bandwidth issues associated with bloated client side scripts.
(* Flash Player 6.0r65 for Windows and Mac Classic, 6.0r67 for Mac OSX and 6.0r69 for Linux)
There is, however, a big problem with this solution. Anyone with a Flash Player that’s lower than the above versions (including earlier releases of Flash Player 6), those using Opera, and users who refresh the page with Internet Explorer will be seen by the server side script to have no Flash Player installed!
We have a few options to get around this sticky issue:
- completely ignore this and stick with client side scripting (until the population of Flash Player 6.0r65 and above grows) or
- Deploy a Flash movie, then use our inbuilt version detection method above to check for a required version. Users of the latest Flash Player can skip version detection completely, thanks to the ‘flashvars’
<param>tag, as you’ll see below. Those with no Flash Player will see our descriptive content, as per our XHTML compliant markup.
Let’s look again at a portion of the previous PHP code:
<?
//check for flash!
if(eregi("application/x-shockwave-flash", $_SERVER['HTTP_ACCEPT']))
{
$hasFlashSupport=true;
}
<object
data="index.swf"
type="application/x-shockwave-flash"
codebase="http://<?=$_SERVER['HTTP_HOST']?>/sitepoint/flashdetection/testmovie/"
width="550"
height="400">
<param name="movie" value="http://<?=$_SERVER['HTTP_HOST']?>/sitepoint/flashdetection/testmovie/index.swf" />
<param name="menu" value="false" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ededed" />
<?
if($hasFlashSupport)
{
//tell actionscript to skip the version check (we know version 6.0r65 or greater is installed)
//flashvars makes a variable called skipVersionCheck available on the _root timeline.
?>
<param name="flashvars" value="&skipVersionCheck=true" />
<?
}
?>
<p>
Alternate descriptive content can go here, plus a link to the Flash Player download page for the user to optionally activate.
<br />
This text will be displayed if the user-agent cannot render the Flash file specified in the object tag.
</p>
</object>
?>That flashvars param tag is very important, as we can use server side detection with inbuilt version detection. If we want to skip the inbuilt version detection completely we can check for the value of _root.skipVersionCheck in ActionScript.
When should this method be employed?
- Where you want to show this detection method to a developer audience.
- When you want to deploy a Flash movie for the latest Player — with the next generation of Flash Players (7 and beyond), this method will be of key importance for those wanting to distinguish player versions, e.g. movies for Flash Player 7 and up only.
- When you aren’t that concerned about your Flash movie possibly breaking for Flash 2, 3 and 4 users.
- When you want a quick and easy Flash Player 6 detection implementation that can be used for any number of Flash movies in a site (that
$hasFlashSupportvariable can be used throughout the script environment or even attached to a session variable).
When should this method be avoided?
- When you want to deploy Flash content for a general audience.
- It can’t be used if you do not have access to server side scripting languages.
- When you may have a large number of Flash Player 2 and 3 users (unlikely).
Server side detection is definitely the way of the future, and it’s up to you to make the decision on whether to employ it now. Hopefully, browsers such as Internet Explorer and Opera will support this far better in the future.
Best Options for Different Situations
After running through these options, you may be wondering what the best detection scenario is for your site. Outlined below are two lists, based on reaching the widest possible audience and ease of implementation.
Detection methods that will reach the widest possible audience:
- Client Side Detection
- Inbuilt version detection
- Server side detection
- Manyana method
- Nested HTML tags
Detection methods that are the easiest to employ:
- Server side detection (including Inbuilt version detection)
- Inbuilt version detection
- Manyana method
- Client side detection
- Nested HTML tags
Conclusion
We’ve covered five major Flash Player detection methods here, each with varying degrees of complexity and browser support. In addition to this, we’ve investigated some useful ways of making the detection process both transparent to our end users and degradable for those without the Flash Player.
In writing the article I was surprised at how important the role standards support played in building more elegant version detection methods than client side scripting.
If Internet Explorer for Windows supported the Object tag to w3c recommendation and sent its HTTP-ACCEPT header correctly, we would find detection methods such as tag nesting and server side detection far more enticing to implement, which would lead to lighter markup and smarter Flash support.
Unfortunately, the monopoly this browser has in the market leaves us with client side scripting as currently the most robust detection method to use across sites for the general public.
To further other, more elegant detection scenarios I would recommend Flash developers investigate server side detection, inbuilt version detection and tag nesting, as discussed in the article.
I would also recommend developers and designers start employing the object tag-based markup used in this article and others, discarding the embed tag. Dealing with one tag only for deploying Flash files does assist in controlling the Player download and brings detection within your control, rather than handing it to whatever browser the visitor uses.
The more Web developers and designers start pushing for better browser support, the faster we will be able to implement smarter, less bloated Flash Player detection scenarios for the majority of users.
Footnote – Flash Player 7 Beta
As this article was completed, Macromedia released a beta version of Flash Player 7. At first glance, there are numerous additions in this Player including a new Flash Player Update Mechanism (currently only for Internet Explorer browsers running on Windows). For more information on this beta Player visit http://www.macromedia.com/software/flashplayer/public_beta/
Code Download
Download a zip of all five methods discussed here. Read the readme file to determine what is required for installation.
Links to Resources
Macromedia Flash SWF file format information
Macromedia Flash SWF file format download links.
http://www.macromedia.com/software/flash/open/licensing/fileformat/
Downloads of older Players for testing.
http://www.macromedia.com/support/flash/ts/documents/oldplayers.htm
How to uninstall Flash Player to test detection methods with no Player present.
http://www.macromedia.com/support/flash/ts/documents/remove_player.htm
Manyana Method
Flash Player population census
http://www.macromedia.com/software/player_census/flashplayer/version_penetration.html
Client Side Detection
Colin Moock’s FPI (Flash Player Inspector)
http://www.moock.org/webdesign/flash/detection/moockfpi/
Navigator.plugins in the Javascript dictionary.
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/nav.html#1193425
CreateObject in VBScript.
http://support.microsoft.com:80/support/kb/articles/q183/2/84.asp
The Flash Deployment Kit is Macromedia’s contribution to client side detection.
http://www.macromedia.com/support/flash/player/flash_deployment_readme/
Cascading XHTML : the object tag
The Object element in the HTML4 W3c recommendation.
https://www.w3.org/TR/html4/struct/objects.html
Internet Explorer problems with nested object tag support.
http://www.xml.com/pub/a/2003/07/02/dive.html
Inbuilt Flash version detection
$version in ActionScript.
http://www.macromedia.com/support/flash/ts/documents/version.htm
getVersion() in the ActionScript dictionary.
http://www.macromedia.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary378.html
System.capabilities.version in the ActionScript dictionary.
http://www.macromedia.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary719.html
Server Side Flash Detection
Macromedia Flash Player 6 release notes.
http://www.macromedia.com/support/flash/releasenotes/player/rn_6.html#new
A Macromedia Devnet article relying on redirects and Browserhawk.
http://www.macromedia.com/devnet/mx/flash/articles/browser_hawk.html
Coldfusion and Server Side Flash detection with HTTP-ACCEPT.
http://cfm.blogspot.com/2003_03_01_cfm_archive.html#90765995
Other Resources
HTTP-ACCEPT from the W3C.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Web Content Accessibility Guidelines – Use W3c technologies.
https://www.w3.org/TR/WCAG10/#gl-use-w3c
The Embed tag – a relic from Netscape 4.
http://devedge.netscape.com/library/manuals/1998/htmlguide/tags14.html#1286379
Flash Satay – standards compliant markup to deploy Flash movies.
http://www.alistapart.com/stories/flashsatay/
A Netscape Devedge article on Object and Embed.
http://devedge.netscape.com/viewsource/2002/markup-and-plugins/
James EllisJames owns Web firm Quantum Serendipity, based in Sydney, Australia. He has worked on projects for Clairol Australia, Gatorade, and most recently, the 2003 Melbourne International Comedy Festival.
