Ogwaros Iwenâl

Sense: this ad makes none.

(P.S. - the cake is a lie…)

After much moaning on my part, and eventual acceptance of the idea, Microsoft turned around and announced that IE8 will default to IE8 mode after all.  To this I can only say:  stop toying with my emotions, Microsoft!

Seriously, though, this is great news.   The old default didn’t make any sense from a design standpoint (though it made perfect sense from a business standpoint).  While this change doesn’t ameliorate all my concerns with browser version targeting, it will at least stop IE7 from becoming a de-facto “web standard.”  That was one of my largest concerns in the first place.

So if the original decision was a business decision, why the sudden change?  I very much doubt it was all the complaints across the web.  The announcement does give us a hint:

We think that acting in accordance with principles is important, and IE8’s default is a demonstration of the interoperability principles in action. While we do not believe any current legal requirements would dictate which rendering mode a browser must use, this step clearly removes this question as a potential legal and regulatory issue. As stated above, we think it’s the better choice. [emphasis mine]

The whispers around the internets is that this change is to avoid anymore potential legal trouble with the EU.  I can see this angle, and it would be fixed if IE were entirely separated from Windows itself.  Since it’s unlikely Microsoft will ever release standalone versions of IE, they had to make this change to avoid the appearance of locking customers into IE7 mode HTML+CSS+Javascript.  I don’t know if this line of thought was what caused the change of heart, but it seems like it would be a factor.

At any rate, IE8 will function like every other browser out there, thus minimizing browser specific hacks.  And in the end, that’s a lot more important to me than the whys.

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.

The good news: IE8 will be much more standards compliant. It will even pass the Acid 2 test.

The bad news: the above is not really true.

The news about IE8’s three rendering modes. You can read all about that at the IEBlog, or one of two A List Apart articles. The quick version of it is this:

• By default, IE8 will render pages identically to IE6.
• If you use a DOCTYPE (like you are supposed to), it will render pages identically to IE7.
• If you actually want to take advantage of the new rendering engine, you must insert a specialized meta element.

The real sticky part is this new meta switch. It introduces the idea that a browser should be able to render a page as it would in any older version of the browser. This wouldn’t be that big of a deal, if the default behavior were to render in the most standards compliant mode available - the meta switch only needing to be applied where the developer has specifically hacked the page to a particular version. This is not the case with IE8.

So rather than forcing people to add the meta switch to pages that are currently not standards compliant, the onus is on developers already targeting standards to turn on IE8 standards mode. The outcome - rather than write to standards and then tweak as necessary, developers will not target for standards, they will (continue to) target browsers. It’s the bad old days of “This site is best viewed in Netscape 3 at 1024 x 768″ all over again.

Worse will be if developers still writing broken code will want this feature in browsers other than IE (and they will). Want to release a new version of a browser? You better include every version of your rendering and scripting engines. This isn’t a problem for Microsoft - IE is so ingrained into Windows that they can afford the bloat. Firefox? Larger, but manageable (for a while). Little guys like Opera, who regularly release updates? Forget about it.

IE8 cannot possibly “pass” the Acid2 standards compliance test. Doing so would require adding the magical meta switch to the test in order to activate standards mode. IE8 may be able to render the test properly, but only by modifying the test itself.

You really can’t envy Microsoft. It’s a no win situation. If they had enabled standards by default, developers whose code broke (which is already broken to begin with) would scream bloody murder. But this solution is hardly optimal and disregards the entire idea of standards compliance across the board in favor of per-browser-per-version standards. Which is no standard at all.