4.25.2010

Flash Satay: Embedding Flash While Supporting Standards

Image representing Adobe Flash as depicted in ...Image via CrunchBase


I’ve worked with Flash for several years and have always been slightly dissatisfied with the markup needed to embed a movie in web pages. When I recently published a site in XHTML, my dissatisfaction with the markup grew as I realized that it simply wasn’t valid in this context and was bloating my pages to unacceptable levels. A leaner, standards-compliant method of embedding Flash movies was called for.
The Twice-Cooked Method

Flash has always shipped with some method of generating an HTML page to contain Flash movies. Initially, it was a tool called AfterShock. Since the release of Flash 4, authors can export HTML pages with embedded movies from within the Flash authoring environment. This markup produced by Flash is the de facto standard that you’ll find in 99% of sites that use Flash movies.

As you can see, it’s a bit of a monster. There are two main tags used to embed the movie, requiring every value to be declared twice. Internet Explorer and its followers primarily use one tag; browsers that consider themselves friends of Netscape use the other. We’ll call this the Twice Cooked method. is part of the XHTML specification, but is badly implemented here. It is used by IE style browsers to start an instance of the Flash Player and load in the specified movie. The element is its bedfellow, offering any number of parameters to be passed to the player once it is started. embed is not part of the XHTML specification and will prevent your page from validating. It is used by Netscape and similar browsers for displaying Flash movies. Parameters are passed within the element as name/value attribute pairs.


The <embed> Element

The <embed> element was created by Netscape as their method of embedding plug ins and players in web pages. It’s not part of the XHTML specification, and while some browsers other than Netscape support it, it’s not standards-compliant, so it’s out. Bye bye, <embed> ... it's been swell.
The <object> Element

Without , we’re left with the element, so it would be prudent to fully understand its capabilities. The great news is that just about every browser in popular use supports in one way or another. The element has no required attributes, but many are available for use. Below are the more interesting ones, along with edited highlights from the W3C specification. classid (URI) This attribute may be used to specify the location of an object’s implementation via a URI. It may be used together with or as an alternative to the data attribute (see below), depending on the type of object involved. codebase (URI) This attribute specifies the base path used to resolve relative URIs specified by the classid, data, and archive attributes. When absent, its default value is the base URI of the current document. data (URI) This attribute may be used to specify the location of the object’s data, or more generally, a serialized form of an object which can be used to recreate it. type (content-type) This attribute specifies the content type for the data specified by data. codetype (content-type) This attribute specifies the content type of data expected when downloading the object specified by classid. There are other attributes that allow references to archived versions, cause text to display while loading (we can do this is Flash already), and so on, as well as width, height, id, class and other common attributes. The ones listed above, however, are particularly relevant when it comes to embedding Flash movies. Another useful thing I learned is that an tag can contain child elements which can be used as an alternative if the browser doesn’t have the capability to display the object itself. In fact, this is how the undesirable nested works in Netscape browsers—but more on that later. The Process Armed with a more thorough understanding of the markup, I set about doing some testing in various browsers. My first step was to try the Macromedia markup with the <embed> stripped out, and cleaned up for XHTML:

Unfortunately, this simply doesn’t work outside IE-style browsers. After a little jiggerypokery and some Googling, I discovered that the GUID used in the classid attribute was specific to the browser’s ActiveX configuration. In fact, it was causing Netscape 7 and Mozilla to totally ignore the object. The classid attribute does, however, perform an important function: telling the browser which Player to use. So we can’t simply get rid of it without replacing its functionality with something else. Fortunately, the Flash Player is configured to respond to content with a MIME type of application/x-shockwave-flash. This is great, because the type attribute allows us to specify a content type. Therefore, out goes:

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"


... and in comes: type="application/x-shockwave-flash"

Codebase

The above change doesn’t get movies playing in Netscape browsers on its own. The next curiosity on the list is the codebase attribute. This contains a path to a copy of the Flash plug in-on Macromedia’s servers. This is actually incorrect usage of the attribute, as any paths within it are supposed to be within the same domain—a security feature. In many browsers (primarily IE) this attribute performs another function. The path contains a string on the end that specifies which version of the plug-in the server should deliver. If the version declared is later than the version currently installed, the browser will prompt the user to allow it to update. The downside is that this attribute also stops the movie from playing in Netscape and Mozilla when used in this way, so it’s gotta go. We’ll discuss a work-around for this lost functionality later on. With the codebase attribute gone, our markup is beginning to look pleasantly sparse:

Try this code, and it still won’t load a movie in Netscape. Having gotten this far, I worried that there was literally no way to use valid markup to deliver Flash in Netscape browsers, and every response to this question online told me as much. So I did what I always do and started trying crazy things.


Making Progress

When I tried out the data attribute, I nearly had kittens, as movies suddenly started playing in Netscape and Mozilla. Flipping back to IE revealed that the movies played there too.

After testing with some largish movies, I noticed something amiss. While every other browser was getting it right, IE/Windows was not streaming—it was waiting for the entire movie to download before playing it. This is fine for small movies, but for anything serious, the lack of streaming is unacceptable. I concluded that valid markup for Flash movies was possible, but only once Microsoft had fixed this problem with IE/Windows.


The Satay Method

A few days later I was discussing this issue with Jeffrey Zeldman, explaining how I’d come close to a solution but hadn’t quite found it. He was interested that I’d managed to come close, having experienced the problem himself on recent projects. This got me thinking, and while driving home that evening the solution hit me. The only problem with the code I had is that IE/Windows doesn’t stream the movie. It waits for the whole movie to download and then plays it. This is fine for very small movies, as the wait isn’t that noticeable. So, how about creating a very small container movie, which in the first frame loads in the real movie we want to play? I tested it, and it works. It’s a bit of a hack, but a valid and justifiable hack in my opinion. The greatest thing is that you don’t have to create a separate container movie for each “real” movie—one smart container can work with any Flash movie having the same proportions. No matter if your movie is made from beef, chicken, or pork, you still need to skewer it and dip it in the sauce to make it work. We call this the Satay Method.
The container movie

I created a new Flash movie and put the following ActionScript on Frame 1 right in the root of the movie: _root.loadMovie(_root.path,0);


This instructs the Flash Player to load a movie, whose name is in the variable path on the root, into Level 0 of the current movie. All we need to do is make sure that the name of the movie we want to load is held in the variable called path. Flash makes this part easy. The Flash Player loads any name/value pairs that are passed to a Flash movie on a query string into the root of the movie. This is useful for many different applications, but in our case it means that we just need to call the movie like this: c.swf?path=movie.swf


The container movie is c.swf. I’m passing it a variable called path with a value of movie.swf. This means that our ActionScript, when evaluated, would equate to this: _root.loadMovie("movie.swf",0);


You can modify the behavior of the container movie to do whatever you like—as long as it’s kept small. You can use GET and POST to pass variables through the container if you need to, for example. This method, however, will only work well if the container movie is just a few kilobytes in size.
The markup

This leaves us with just the markup to finalize. We’ve dropped a lot of attributes, added some sparkling new ones, and tidied it all up:

So there it is—meaner, leaner, and altogether better for the environment. But what about that functionality we lost when axing the codebase attribute?


Compensating

The main problem with getting rid of the codebase attribute was that in IE and similar browsers it caused the user to be prompted to update their Flash plug-in if it was out of date. This is really useful, as it’s likely the only way that most ordinary web users get their players updated. The workaround is simple: just include one sacrificial movie at the front of your site with the codebase attribute left in. This needs to be a movie with no purpose within the site—just a 1k empty blob of nothingness that causes the user to be prompted if they have an old version of the plug in. Not the cleanest approach, but a practical one. It shouldn’t lose you any friends.
Alternative Content

Remember that behavior of the <object> tag I was talking about earlier, where the browser will try to parse a child element if it can’t work with the object itself? It’s very cool. If you were to look at the source code of the home page at Macromedia.com, you’d see that they serve up an alternative image if the user can’t view Flash movies. They are detecting the Flash Player with JavaScript, and then using JavaScript to dynamically write out HTML based on the detection. Ugly, ugly, ugly. Here’s how I’d do it:
If the browser doesn’t know how to play objects with a MIME type of application/x-shockwave-flash, it will simply go for the next child element and give that a try. I’m guessing that a simple image element should be okay for most people. Failing that, you can simply use text.


Work in progress

I’ve written this article with the knowledge that it’s simply one man’s findings and thus a work in progress. Consider it like a scientific theory: what I state today is only proven until it’s disproved.

via alistapart.com
 
Reblog this post [with Zemanta]