I’ll be giving a talk called Progressive Enhancement with Flash that will cover stuff like:

• Using SWFObject (maybe SWFFix by then) to embed Flash content
• Using progressive enhancement to allow search engines to properly index your content and increase SEO for Flash websites
• Flash content vs. Flash style, and how to treat them differently
• Deep linking and back button support in Flash

And a few other areas. I should also be able to talk about SWFFix a bit (hopefully it will be fully released by then, but who knows).

Go check out the Flashbelt page for more info. I can’t give you a direct link to my session, but it’s listed there in the session list. Hopefully I’ll see some of you there!

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.

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

Today is the start of a new semester at Cooper, which means a new XHTML + Flash class! Next week I’m off to Austin for Flash Forward, where I’ll give a presentation about SWFObject and general Flash embedding. If you are going, feel free to stop and say ‘hi.’ If you can’t make it to Flash Forward, I’ll be heading to the UK in December for Flash on the Beach, where I’ll be giving another presentation, this one will be geared more towards Flash and Web 2.0 stuff living in harmony (Yes! It’s possible!).

Also: “The most influential Flash site of the decade” uses SWFObject (FlashObject actually, but same thing).

Also (again): The 5th edition of Javascript: The definitive guide is out. I got a copy yesterday from O’reilly (I did a tech review of one of the chapters a while back) and I must say that it’s fantastic. The 4th edition of the book was great, and is one of the only books that has a permanant spot on my desk, so this is a very welcome update.

That’s about it. What’s new with you?

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.

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 ¹.

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.

¹ 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.

• [Changed] When calling FlashObject.write() you can now pass an HTMLElement reference. Previously you needed to pass a string (the Id of the element to write the Flash content to)
• [Changed] Made changes to the plugin detection routine that would cause a crash in browsers running certain versions of the Flash plugin. Read a comprehensive description of the issue and the fix.
• [New] You may now specify a specific URL to redirect the user to after they complete an ExpressInstall process. Previously the script would always redirect them to the page the Flash movie was embedded in, but when using a popup window this is not always the best solution. See the ExpressInstall section of the FlashObject page for more information.
• [New] FlashObject now integrates seamlessly with the Javascript Integration Kit. More information on this is forthcoming in a new blog post.
• [New] I’ve used Dojo Shrinksafe to strip out the extra space in the flashobject.js file. FlashObject now weighs in at just a hair over 6kb. Super tiny! The FlashObject ‘source code’ (un-shunken Javascript) is included in the FlashObject zip file in the ‘source’ folder. I also made a number of small syntax changes to reduce the size even more.

I’ve updated the FlashObject page to reflect these changes. I recommend that everyone should upgrade if you are using any older version of FlashObject. If you are upgrading from v. 1.2, you can simply replace your flashobject.js file and you should be ready to go. Versions earlier than 1.2, you may need to make minor adjustments to your embed code (see the changes to v. 1.2 for help with that)

UPDATE (1-25-2006): Found a small bug in this latest version that caused the Flash movie to not load on IE 5.01 on PC. The bug has been fixed and the zip/source has been updated. Please update to the latest version if you are using 1.3 and have a lot of users using IE 5.01 (does anyone have a high number of those anymore?). The new version number is 1.3b.

If you are into nerd things, head over to the BarCamp website and register.

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.

I’ve also given FlashObject a permanent home at http://blog.deconcept.com/flashobject/.

Here’s the full list of what has changed:

• fo.write() now requires an element ID. In previous versions you could call write() with no parameters and the FlashObject script would write the Flash movie to the page wherever the script was placed on the page. This is no longer the case and now you must specify an element ID.
• fo.altTxt no longer exists. You must now place all your alternate content or upgrade message in the div where your Flash content will be written.
• fo.redirect no longer exists. When using FlashObject to redirect users to a separate upgrade page, you now specify the redirect url like this: fo.setAttribute('redirectUrl', 'http://www.example.com');

I highly recommend upgrading to this version. While I was adding the minor version detection, I found a bug that will cause Netscape plugin based browsers to fail the Flash detection once the major version gets up to two digits. That means it will work fine up to Flash 9, but then return 0 if the user has Flash player 10 (this is all assuming Macromedia keeps incrementing the version numbers, and that Adobe doesn’t change everything around when they take over).

So that’s it. This will probably be the last version update to FlashObject, since there isn’t much else I could add that would be useful to everyone. So go tell your friends about it – there’s really no reason you shouldn’t be using this to embed your Flash movies.

UPDATE: Dave Benjamin pointed out a flaw in the new detection checking function, and that has been fixed. I also fixed a very small issue with the version check that would cause it to fail if you had version 9.1.0, and the page required 8.2.0 (for example), so make sure you get the latest version.

UPDATE (07-27-2005): Matthew Richmond set me up with a better looking test file, that also shows the full page version much better, so the download / example pages have been updated.

UPDATE (08-01-2005): Just fixed a bug in the detection function that would throw an error when no Flash player was installed, thus casing the redirect to fail if you were trying to redirect users to an upgrade page. Thanks to Carl Wurtz for pointing that out. I also took the chance to update the ActiveX plugin detection code. No more VBscript in there (not even an execscript() call). New version number is 1.2.2 – make sure you have the latest version!

Here are links to the projects we showed or talked about:

• Winged Migration
• Badasssss
• iVillage
• Fog of War
• CosmoGirl
• National Sleep Foundation
• Adobe CS2 Web Photo Galleries (source files)
• FlashObject

And if you couldn’t make it, Brandie posted some pictures.

UPDATE: Here’s the presentation in PDF format. (44MB)

Here’s a screenshot of the new player:

This new version should be much more accessible and easier to use, and also takes up fewer system resources, so people who want to tune in a channel and leave it playing in the background while they work should be happier.

This was an excellent project to work on – while I’ve done quite a bit of DHTML/Javascript work in the past, I’ve never used it as a base for an entire application. This was also the first time I used xmlHttpRequest, but I found that applying my Flash knowledge to the AJAX model worked out great – the only tricky part was figuring out a few browser inconsistencies and working around those.

If you want to check it out, you can sign up for a free 3 day trial.

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.

Well, after a few hours of tyring different ways to hack Safari into submission, I decided that the only way I could get it working was to use some Javascript, so I thought I should share the code since there were a few pages on Google also looking for solutions.

Here is what the Javascript looks like:

var targBox = "box";
function init() {
	if (document.getElementById) {
		var atags = document.getElementsByTagName("A");
		for (var i=0;i<atags.length;i++) {
			var ca = atags[i];
			if (ca.href.indexOf("#") > -1) {
				ca.onclick = function() {
					scrollDivToAnchor(this.href.split("#")[1]);
				}
			}
		}
	}
}
function scrollDivToAnchor(a) {
	var b = document.getElementById(targBox);
	b.scrollTop = document.getElementById(a).offsetTop - b.offsetTop;
}

Sample page with the working code:

View Example

It was a very… ehm… colorful project to work on :). As mentioned in my other post, the site is XHTML 1.0 transitional with CSS used for layout, with a little Flash content peppered in there for some extra flavor. More and more of the sites we are working on these days entail an XHTML/CSS layout and then a few Flash movies embedded around in various locations to spice things up a bit, and I have to say it’s working out great. I really think a lot more designers will go in the direction of hybrid sites rather than the old full Flash site or straight HTML in the coming year.

Another thing to note is the validation problem. It seems that most of the problems (if not all) stem from a few sloppy Javascript embeds and unencoded ampersands that were added in by the iVillage development team. Unfortunately with the way the site was developed – doing the design and template coding first, then integrating those files with the content management system – and without someone on the development side constantly cracking the validation whip, I suppose these things are bound to happen.

Anyway, enjoy the site: www.ivillage.com.

Embedding QuickTime movies in websites presents many of the same problems as embedding Flash. Since QuickTime relies on a third party plugin, your users will need to have this plugin installed before they can view your content. If they don’t have the plugin, they will be greeted by either an AcitveX install window (Internet Explorer) or an ugly ‘broken plugin’ image on other browsers. I prefer using Javascript to detect the presence of plugins because it gives you more control over what your users see when they visit your site. Most web browsers handle plugin installs terribly, often giving the user cryptic looking placeholders (broken puzzle pieces) or strange sounding legal notices on ActiveX install dialogs (of which people may have been trained to always say ‘no’ to since the same dialog box will often install spyware).

Anyway, enough chit-chat. On to the Javascript:

To use the QTObject embed, you simply create a new QTObject, add the parameters you want, and then write it to the page. The script will check to see whether the QuickTime plugin is available and write the embed code to the page or the alternate content if the user doesn’t have the required plugin. Here is an example of what a simple movie embed would look like (I used a fun little video I found floating around the Internet as a sample movie, but it can be any .jpg, .gif, .png, or even another .mov file.): (View Example)

var myQTObject = new QTObject("bushuncensored.mov", "bushfinger", "320", "255");
myQTObject.addParam("autostart", "false");
myQTObject.write();


In this example the ‘myQTObject.addParam()‘ isn’t needed, but it’s a nice addition that will keep the movie from starting before the user figures out what they are looking at.

The parameters from left to right are the path to the mov file, the ID of the mov file, the width, and then the height of the file. If you are showing the QuickTime controls, you need to add 15 pixels or so to the height of the movie or the controls will be pushed down and the user won’t be able to see them.

If you want to do some more advanced embedding, such as the method Apple uses on their QuickTime site, your code would look something like this: (View Example)

var myQTObject = new QTObject("bushplaceholder.jpg", "bushfinger", "320", "255");
myQTObject.addParam("href", "bushuncensored.mov");
myQTObject.addParam("target", "myself");
myQTObject.addParam("controller", "false");
myQTObject.write();


This uses a few extra parameters that allow you to use a placeholder image that will load in the place of your movie until the user clicks on it. Your movie would then load in the place of the image and start when it has loaded enough to start playing. You simply replace the mov source from the first example with your placeholder image (you remembered to add 15 pixels to the height of the image to account for the QuickTime controls, right?) and then an extra few parameters to tell the QuickTime embed where to find the real movie, the target QuickTime object, and finally telling it to hide the controls before the real movie loads.

There is also the option of redirecting the user to another page if there is no QuickTime plugin found by using this code: myQTObject.redirect = "upgradepage.html";, and there is a built in bypass of the detect script by including detectqt=false in the query string when you request the page. This link is included in the ‘upgrade’ notice so if for some reason a user has QuickTime installed but the Javascript detect fails, they can still attempt to view the QuickTime content.

Also, be sure you use this in combination with <noscript> tags just in case some of your users have Javascript disabled.

That’s it! Since it uses Javascript to create the embed and object tags, it will validate as XHTML 1.0 (strict or transitional). Please note that it will not work with pages sent as application/xhtml+xml since it uses innerHTML and document.write(). Another note: I’m not checking for the version of the QuickTime plugin installed, and I couldn’t find any older QuickTime players for testing, so I’m not sure how this will treat users who are using QuickTime 4 to view content that requires QuickTime 6. I seem to remember QuickTime having an auto-update feature or some built in notification if you need to upgrade, so I’m not too worried about it, but if anyone has some experience in this area, I’d love to hear how this embed method behaves under those circumstances.

I’ve tested this on IE 6, 5.0, 5.5 on PC, Firefox on Mac and PC, and Opera and Safari on Mac. It has worked great every time, but everyone knows there can always be little bugs that pop up, so if anyone finds something wrong with the code, let me know.

Download source and example files (1.09MB)

UPDATE (02-11-2005): Just fixed a few bugs – one that was giving problems if the user didin’t have QuickTime installed on Internet Explorer for PC, and adjusted the default Alternate text.

UPDATE (02-16-2005): Not sure how something like this slipped past, but Thiago found a little bug in the VB Script that was giving some problems in IE on a PC. The files have all been updated.

View example: 100% width and height stretched Flash embed.

It’s actually pretty simple. Here’s some of the CSS I used:

/* hide from ie5 mac \*/
html {
  height: 100%;
  overflow: hidden;
}
#flashcontent {
  height: 100%;
}
/* end hide */
body {
  height: 100%;
  margin: 0;
  padding: 0;
  background-color: #eee;
}

Setting the html tag to 100% height and then placing the Flash movie inside a div that is also set to 100% height does the trick.

Notice the overflow: hidden on the html element since IE will show the scrollbar even if the page doesn’t need to scroll. This line will force IE to hide any content that is outside of the browser window, and therefore hide the scrollbar as well.

To embed the Flash movie, I used my FlashObject Javascript embed so the page will validate and I have access to all the various Flash parameters I might need to pass to the Flash movie.

UPDATE (01-05-2005): Someone pointed out a bug with this in IE 5 on Macintosh, so I’ve updated the CSS a bit to make it work. Current verified working browsers are: IE 6 (PC), IE 5 (Mac), Safari, Firefox (PC, Mac), Mozilla (PC, Mac), Opera 7.54 (Mac).

If you have other browsers available for testing I would love to know if this displays properly or not. I’m mainly interested in IE 5 and 5.5 on a PC.

UPDATE (1-17-05): Tested in IE 5.01 sp2 and IE 5.5 sp2 on a pc today, and it works great.

This was one of the first projects I worked on when I moved to New York. We decided on a CSS layout using XHTML 1.0 transitional (sent as text/html), with some Flash peppered around. Right now only the entertainment section is using the new design, with the other sections to follow as their internal team takes our template and adapts the content in the other sections. Unfortunately the site doesn’t validate because of one little error(!) that I’ll be passing along to their internal team along with a few small visual errors to fix.

It uses a similar method to the suckerfish dropdowns for the flyout menus on the left navigation, and some basic CSS rollovers for the main navigaion tabs at the top.

I would have liked to use my FlashObject embed for the Flash content, but this was handed over to their internal team way before I had even thought it up, so it uses generic Javascript to detect and embed the Flash movies.

UPDATE (12-22-2004): Looks like the one validation error was in some content that has now rotated off of the homepage, so now it validates!

UPDATE (01-31-2005): The whole site went live this week.

[there are still many sites that] require third-party products such as Flash to work

I think this point should be looked at from the other side of the fence. Flash is not going away. It’s way way too popular and useful for too many websites.

Once you think of it like this, the problem becomes how tough it is to use Flash in a way that doesn’t invalidate your documents, which is where I think much more fucus needs to go these days.

Standardize the browser plugin architecture and I bet you’ll see way more XHTML valid Flash websites.

It seems that there are a few people spreading the word that sending XHTML documents as text/html is not only improper, but downright bad for you (gasp!). The basic argument goes something like this:

Dude[ette] sends XHTML document as text/html instead of application/xhtml+xml and therefore is gaining no advantage over plain old HTML 4.01. Since XHTML ‘should’ be sent as application/xhtml+xml, doing it any other way is wrong and you will burn in hell. Instead you should use HTML 4.01 because more browsers understand it, and when the time comes to switch, you can just use HTML tidy or make the small changes your pages need by hand.

Ok, I added the ‘burn in hell’ part, but you get the general idea.

Now I’m not going to go into why you should use application/xhtml+xml or all the benefits and differences between that and text/html. Instead, I’m going to let you read up on the subject yourself, and then tell you why it’s quite acceptable to keep on using text/html for the time being.

All of these links are full of excellent information and everyone building XHTML websites should know this whether they agree with them or not. Go ahead and take a few moments to read them. I’ll wait here.

• Sending XHTML as text/html Considered Harmful
• RFC 3236: The ‘application/xhtml+xml‘ Media Type
• Pretending to Use XHTML

Ok. Wasn’t that fun? Now here are some reasons why sending your XHTML pages as text/html is just fine. It is important to realize that the real argument here is not whether they should be sent as application/xhtml+xml or not, but what to serve as an alternative to user agents that can’t support it, such as IE.

1) XHTML 1.0 is like a gateway drug. It’s not HTML, and it’s not quite XML, but it’s a nice middle ground. It teaches you to close your tags, use lowercase attributes, always quote your attributes, never ‘minimize’ your attributes, and a few more. All of these are outlined here: The difference between XHTML 1 and HTML 4. This is a great benifit in that it teaches developers to follow stricter rules when building pages, and when the time eventually comes when they need to switch to application/xhtml+xml, there will be fewer changes to worry about than with HTML 4.

2) The XHTML standard allows you to use text/html. A short excerpt:

XHTML Documents which follow the guidelines set forth in Appendix C, “HTML Compatibility Guidelines” may be labeled with the Internet Media Type “text/html” [RFC2854], as they are compatible with most HTML browsers.

So the way I see things is that sending XHTML as text/html isn’t a bad thing at all. Using XHTML teaches developers to write well-formed documents, and teaches them the basics of XML, which will be more and more valuable as we progress from HTML to XML documents on the web. I think it’s important that people know the differences when sending documents with different mime types, but discouraging the use of XHTML sent as text/html doesn’t help anyone, and telling them there are no advantages at all is misleading.

Other reading:

• DOCTYPES not relevant?
• XHTML Media Types
• Serving XHTML with the Right MIME Type

UPDATE (11-10-2004): I just came across this post about content negotiation and saw an excellent conversation in the comments about converting your XHTML to HTML and the issues you will encounter.

One of the readers makes this point:

Your situation is different, though. I totally agree that XHTML should be served as application/xhtml+xml to browsers that support it. With respect to IE, you have some choices.

You could just serve it the XHTML content as text/html. Provided you’ve authored it in HTML-compatibility mode, IE will handle that perfectly well (or, at least, no worse than it handles HTML4).

Alternatively, you could decide, as you apparently have done, to serve IE HTML4, using a conversion that

1) only works with XHTML written in compatibility mode

2) runs the risk of seriously munging your text. (This is, after all, a weblog about web design!)

What’s the benefit of doing this instead of just sending IE the unaltered XHTML document (as text/html)?

And the response:

Nothing, probably. I’m reworking the “CMS” at the moment, and if I ever finish it, I will use a better system for converting to HTML. In fact, since XHTML is currently useless unless you actually need it (like your blog), I’m thinking about serving HTML 4.01 Strict to all. I’ll still store the posts as XML, though, for various reasons, so some kind of rewriting will be necessary.

So it seems to me that the optimal solution for most websites these days would be this:

1. Author your pages as XHTML 1.0 strict or transitional in ‘compatibility mode‘
2. Use content negotiation to send application/xhtml+xml pages to user agents that favor XHTML content
3. For user agents that don’t like application/xhtml+xml, send them ‘compatible’ XHTML 1.0 as text/html

This way user agents that can handle XHTML get it, and if the user agent doesn’t understand application/xhtml+xml, you will have a very minimal amount of work on the server side to convert your XML content to ‘compatible’ XHTML.