Ogwaros Iwenâl

The latest edition of A List Apart is once again dedicated to the IE8 browser targetting controversy. I am thankful that this edition is more balanced than the initial announcement, with “They Shoot Browsers, Don’t They,” an article against the mechanism by Jeremy Keith, and “Version Targeting: Threat or Menace” by Jeffrey Zeldman in tentative favor of it. Having read these, comments on them, and a lot of individual blog posts on the subject, I’ve come to an obvious conclusion: this whole thing is a mess.

Very few people seem to be truly in favor of the X-UA-Compatible mechanism. Most seem to be against it. The few that do support it do so because this may be the only way that Microsoft will increase their support for web standards in general. Zeldman in particular warns that Microsoft going their own way would only serve to fracture the web once again and web standards as we know them today would day. As depressing and defeatist as that sounds, I don’t think it’s an exaggeration at all.

Like it or not, Microsoft still holds the vast majority of the browser market share. Yes, Firefox and other alternative browsers have slowly but surely chipped away at that, but the fact remains: if you don’t support IE in some form, you are locking out most of your potential audience/customer base. If Microsoft were to suddenly say “To hell with HTML, CSS, and Javascript!” and build a new web based on Microsoft Markup Language and Silverlight, the web as we know it would die. Instantly the web is fractured into W3C and Microsoft camps. And due to Microsoft’s market share (both browser and OS), Microsoft’s proprietary web would certainly win.

That dire scenario is of course the worst case. But even if Microsoft just starts extending W3C standards to fit their own needs again, it will be harmful to the web. So if the X-UA-Compatible switch is the only way Microsoft will start to move forward once again with the rest of the web, if it is the only business decision that will let them catch up, so be it.

None of this changes the fact that the solution is simply wrong headed. The default of rendering in IE7 mode may be the correct business decision, but it is wrong from a standards point of view. In fact, targeting browsers at all seems like the wrong approach. Instead, standards should be targeted directly.

Currently, most browsers have two rendering modes - standards mode, which tries its best to adhere to W3C recommendations, and quirks mode, which tries to interpret the page as best it can. Quirks mode is almost whatever the browser wants. In order to choose which mode the browser will use, the page is checked for a DOCTYPE:

< !DOCTYPE html ...>

If an appropriate DOCTYPE is available, standards mode is activated. The problem? This has always been a hack, nothing more. A hack that made a modicum of sense. A useful hack. But a hack nonetheless.

As per HTML 4.01 recommendation, an HTML document must include a DOCTYPE to be considered a valid document. This means any HTML document without any DOCTYPE at all must be considered invalid. So booting the document into quirks mode makes sense.

However, the DOCTYPE only specifies the version of HTML. It says nothing about the versions of CSS or Javascript used within the document. It should only mean “use this specific set of HTML rules.” But standards modes kicks everything - HTML, CSS and Javascript - into the highest mode supported by a browser. In short, it’s all or nothing.

This is the problem Microsoft faces with IE8. While IE7 was leaps and bounds above IE6 in terms of CSS standards support, Javascript standards support still lagged. With IE8, they are supposedly being improved significantly. This means that while the transition for CSS between the two versions will be relatively painless, the transition for Javascript will not be. Because as Microsoft’s proprietary JScript is phased out and replaced with ECMAScript-based Javascript, code will break. This isn’t just a matter of pages not looking correct - some pages will indeed stop functioning correctly.

Therefore, my preferred solution would be targeting standards versions, not browser versions. The Zeldman article even points out an example of this in the wild - Firefox supports version targeting for Javascript to some degree. Just as DOCTYPE targets HTML features, you can use the following to target Javascript features:

script type="application/javascript;version=1.7"

One can imagine a similar syntax for CSS as well:

style type="text/css;version=2.1"

I read a comment hitting on this idea somewhere, but I’ve done so much reading on IE8 over the past 24 hours I can’t locate the original comment. In any case, this makes a great deal more sense than an all-or-nothing system. You already have to specify the version of HTML you are using. Why not CSS, Javascript, and any number of other standards that are used daily on the web but are not actually a part of HTML?

It makes a great deal more sense to me to specify what features you intend using rather than what browsers you intend the page to be viewed in.  If one of those features doesn’t work correctly in a certain browser, the onus is on the browser vendor to fix that feature in the next release.  The responsibility on the developer should be to make sure that the document will degrade gracefully in non-compliant browsers or progressively enhance for compliant browsers. Lock down your document to a set of standards, rather than say “well, it worked in this version of this browser, pretend it’s this browser.”

Much like a missing DOCTYPE sends a browser into quirks mode today, style and script elements would be thrown into quirks mode if they were missing the version= specifier.  Or barring quirks mode, a semi-standards mode if a DOCTYPE is present.  Mixing versions should probably throw the entire page into the lowest version listed, with quirks mode being a catch all if an element has no version listed.  This would neatly solve most of the problems I have with X-UA-Compatible.

• Standards would be targeted, not browsers.
• It would end the all-or-nothing system in place right now.
• IE7 would not become a de facto “standard” for HTML, CSS and Javascript by being the default IE mode from now until eternity.
• It would be useful beyond solving Microsoft’s immediate problems.

This is no more than a thought experiment, though, because:

• It would encourage the same browser bloat as X-UA-Compatible, though at a notably slower rate.
• It would be an even bigger engineering feat than simply including each version of a browser’s rendering and scripting engines.  The interactions between the various versions of CSS and Javascript make my brain squirm.  Unless you declare that version X, Y and Z of CSS only work with versions A, B, and C of Javascript.  Even then…
• It could end up breaking Firefox, Opera and Safari in the short run, should they implement the idea that lack of version= means quirks mode.
• It seems highly unlikely that Microsoft will change their mind on this one for IE8, as it is more of a business decision than anything else.

And so ends the five stages of learning about X-UA-Compatible:

1. Denial: “There’s no way that happened.  Microsoft promised us standards!”
2. Anger: “Stupid Microsoft!  This mechanism is entirely backwards!  BLARGH!”
3. Bargaining: “Why are all these smart people going along with this?  Maybe they can convince Microsoft to change their minds.”
4. Depression: “Sigh.  Maybe it’s time to find another profession…”
5. (Incredibly reluctant) Acceptance: “Well, this is the way it’s going to be.  Alright, let’s get to work.”

What remains to be seen is if they’ll stick with this mechanism when IE20 rolls out the door.  I am incredibly doubtful.