As you can see, while it's now third, Internet Explorer 6 is still hanging on with unfortunate tenacity. Which means we still have great pain to deal with when trying to develop cross-browser web sites in this rich, interactive era.

I also means there's demand for people like me who know how to handle the beast, so I guess I should look to that as a silver lining…

Still, die IE6 die.

IEBlog : IE Automatic Component Activation Now Available

The IE Automatic Component Activation (IE ACA) update is now available as part of the April 2008 Internet Explorer Cumulative Update. The "click to activate" behavior, formerly required for ActiveX controls embedded in some webpages, is now permanently removed from Internet Explorer. For detailed information on IE ACA, see our blog post from last November announcing this update.

This update replaces the IE ACA previews released in December 2007 and February 2008.

Which means I can stop using SWFObject and just dump Flash into the page like I used to way back when. SWFObject is really a nice piece of code, but I'm a lot happier when I'm not relying on JavaScript for something as basic as getting Flash embedded into a page. It's just an added layer of complexity and an extra download* that I don't need in my life and I'm damn glad to be rid of it.

Want an example of the complexity I'm talking about? check out this post I wrote a few months ago:

Belt and Suspenders- Flash Embed With SWFObject and Conditional Comments

While it works, it's WAY too complicated for anyone's good.

*although I do wrap all JS into a single file now, just appending SWFObject to the bottom of the file. Even doing that it adds a few KB to the download, so even in a single file situation it's overhead I'd rather be rid of…

Say no to IE 6! Our current campaign focuses on assisting users in upgrading their Internet Explorer 6 web browser. This campaign will result in former IE 6 users having a more enjoyable experience on the web while (hopefully) creating a less stressful and complicated environment for web developers by hastening the retirement of an outdated browser.

Say it loud!

I've been writing about the slow adoption rate for a while now and it's still a source of frustration. Over the past month this site has seen 9,078 visitors using IE6.* Which is precisely 9,078 too many.

Honestly? In some sense it's a positive number, as the overall percentage of users on IE6 is shrinking. It's still not shrinking fast enough, however, so sentiments like the above speak to me like a call from up on high.

Sure, my site (and really all of my sites) looks fine in IE6, but it's still a pain to have to support it, even if it's just the extra bytes I have to serve other browsers (in the form of conditional comments.) And really, being the stickler for good experiences that I am, I still have to test and bug-fix for IE6 whenever I add new features or styles. Supporting two version of IE is awful, especially when one is so much better than the other.

I won't even get started on the issues at work.

Okay, maybe a little.

While I've got a hip, upgrading crowd that visits this site, the people we build for at work are generally running old, locked down machines running whatever browser their IT department wants to support. Care to guess what browser that might be?

Yeah.

IE6.

*sob*

*compared to 32,372 using Firefox and 15,385 using Internet Explorer 7.

Warning- not for the squeamish…

Here's the HTML:

<!--[if IE]>
   <noscript> 
   <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="1004" height="281">
      <param name="movie" value="_assets/flash/homepage.swf" />
      <param name="quality" value="high" />
      <embed src="_assets/flash/homepage.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="1004" height="281"></embed>
</object>
</noscript>

<![endif]-->
<!--[if !IE]> <-->
   <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,19,0" width="1004" height="281">
      <param name="movie" value="_assets/flash/homepage.swf" />
      <param name="quality" value="high" />
      <embed src="_assets/flash/homepage.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="1004" height="281"></embed>
   </object>
<!--> <![endif]-->

Here's the SWFObject script served to Internet Explorer and ONLY Internet Explorer

<!--[if IE]>
<script src="_assets/js/swfobject.js" type="text/javascript"></script>
<![endif]-->

And here's the SWFObject call:

        //use conditional compilation to hide this call from non-IE browsers
	/*@cc_on @*/
        /*@if (@_win32)
	if ($("home")){
		var so = new SWFObject("_assets/flash/homepage.swf", "mymovie", "1004", "281", "8", "#336699");
	   	so.addParam("wmode", "transparent");
	   	so.write("messaging");
	}
	/*@end @*/

Before I go further, let me just say I'm counting the days until I can just dump a SWF into the page and be done with it. I hate all of these script based machinations to get a SWF out to the browser. This is code overhead that really bugs me…

Anyway, here's the HTML logic.

• We use Microsoft's conditional comments to show/hide content
• In the "This is IE" block we use a noscript tag to present a traditional embed to IE users who might have JS turned off.
• Every other IE user with JS turned on will see the SWF embedded by SWFObject so no "click to activate and use this control" will be visible to the user. Since the majority of people on the web use IE and the majority of them surf with JS turned on, most users will fall into this category.
• Then, in the "This is not IE" block, we just embed the Flash the old school way. Since the Eolas suit doesn't come into play with other browsers, embedding the SWF the old way is fine (at least in terms of the "click here…" nonsense.) As an additional benefit there's no concern over whether or not the user has JavaScript turned on. JavaScript or no, the only issue is whether or not they have the plugin. Whereas with SWFObject there's a possibility (however slim) that a user could have the Flash plugin installed but be surfing with JavaScript disabled. As I mentioned, this is for the best possible coverage… Also, if they don't have the plugin they get the "download this plugin" notification. I head reports that that wasn't happening with SWFObject running* so getting that to work properly is definitely a bonus. It was actually that bug report that got me into this whole mess

As for how it works technically, the following

<!--[if IE]>

Is read by IE as a test (if the browser is Internet Explorer.) Every other browser reads it as an open comment. Since it's an open comment everything up until the close comment (<![endif]–>) will be ignored by non-IE browsers. IE, on the other hand will go ahead and process that markup normally since it recognizes that pattern as a conditional and its test will evaluate to true.

As a note, I don't like using this stuff all over the place**, but in a situation like this conditional comments are a great option to have.

On the flip side All other browsers read this pattern:

<!–[if !IE]> <–>

As a completed comment, opened and closed on the same line. Therefore everything that follows is rendered normally by Firefox, safari and all the rest. IE, on the other hand, reads it as the beginning of a "If the browser is NOT IE" conditional. Since that resolves to false, everything down to the end of the conditional endif (<!–> <![endif]–>) is ignored by Internet Explorer. That allows us to go back to the future and embed flash in the old school way for everything but IE.

Oh the pain.

Still, if you absolutely need the best possible coverage and want to use SWFObject, this is a way to go. Is it the best? Probably not, since it's horrifyingly hack-y and won't validate. But it might be useful for someone out there…

*and I could figure out how to make it happen…
**I mostly use it to attach IE specific style sheets. For those of you keeping track, that looks like this:

<!--[if gte IE 5.5]>
<![if lt IE 7]>
<link rel="STYLESHEET" type="text/css" href="_assets/styles/ie6.css" />
<![endif]>
<![if gte IE 7]>
<link rel="STYLESHEET" type="text/css" href="_assets/styles/ie7.css" />
<![endif]>
<![endif]-->

Don't get me wrong, SWFObject is a great piece of code. I just hate having to think about Flash at all. Unless there's actual communication between the SWF and the page, I just want to dump it into the doc like any other element and be done with it. I can't tell you how many problems I've had over the past year with Flash and JS embed techniques and bizarre bugs… Pain. Great pain.

IE Automatic Component Activation (Changes to IE ActiveX Update)

Back in April 2006, we made a change to how Internet Explorer handled embedded controls used on some webpages. Some sites required users to “click to activate” before they could interact with the control. Microsoft has now licensed the technologies from Eolas, removing the “click to activate” requirement in Internet Explorer. Because of this, we're removing the “click to activate” behavior from Internet Explorer!

It’s important (and cool) to note that this change will require no modifications to existing webpages, and no new actions for developers creating new pages. We are simply reverting to the old behavior. Once Internet Explorer is updated, all pages that currently require “click to activate” will no longer require the control to be activated. They’ll just work.

IEBlog : IE Automatic Component Activation (Changes to IE ActiveX Update)