Over the past month since the IE team announced its intentions to have an opt-in into IE8 Standards Mode, both them and Microsoft as a whole, have got a huge amount of anger directed at them.
Taking a quick look through the comments on the IE blog again, I believe a lot of this anger is quite irrational: a lot of what is being said would make sense if standards compliant sites were the majority of sites — they aren't: they are a tiny minority (i.e., a single figure percentage at most). Breaking almost every non-compliant website would cause huge issues: someone without a technical background will likely conclude that IE8 breaks sites that work fine in IE7, therefore IE8 is broken. The web is based around the fact that anyone can create a website, and increasing the barrier of entry by breaking existing sites would be a good way to make sure your product isn't used. The end user couldn't give a damn about whether IE supports HTML 4.01 or CSS 2.0 (the current recommendations), they care that their favourite site works. If it doesn't, they complain to Microsoft. Quite frankly, standards be damned. Conformance requirements are wholly irrelevant when the real-world relies on behaviour that is at odds with what is in the standard — if reality is so reliant on UAs doing something different to what is specified, the specification needs to be fixed, not the other way around.
The Age Of Opt-In Switches
Switches aren't something new, neither is opting-in (the DOCTYPE switch is exactly that, an opt-in into standards mode), nor is a switch first used by Microsoft (IE5 for Mac was the first browser to ship with DOCTYPE switching in 2000, though it was hinted at on the Mozilla mailing lists back in 1998, although nothing happened about it in Mozilla until after IE5 for Mac shipped). Just using a W3C DOCTYPE isn't enough to be standards mode — transitional and frameset DOCTYPEs can and do cause quirks mode to be used. It requires a subset of what is conformant to trigger standards mode. Likewise, requiring a meta element is requiring a subset of HTML (albeit, this time requiring a specific element/attribute combination instead of requiring a specific DOCTYPE public/system identifier combination). Yet, DOCTYPE switching is accepted almost universally within standards communities, but a proposed new switch is not.
Moving Forward From A Hiatus
Now what actually causes the issue that necessitates a new switch? With development of IE having been stopped after the release of IE6, a large number of sites have grown up that are dependant on IE being broken forever often at the same time as supporting other browsers fine. What these sites depend upon vary from relying that the DOM isn't a tree to using conditional comments that don't specify a version. Netscape won the scripting wars (with JavaScript) and Microsoft won the browser wars (with IE). With the wars being won by different products, scripting is incompatible. There were far less compatible scripting engines than JScript, it's just they died off.
Why is this an issue? IE can't overnight move from JScript to ECMAScript (a standard which is based upon JavaScript) without breaking a large number of sites which either won't be updated at all or in a timely manner. And it's not just small non-compliant sites that have issues, major scripting products like Prototype have browser specific hacks all over the place (and not just for IE, but other browsers too, including the standards community's beloved Firefox), which with any major scripting changes will break horribly. Just take a look at some of the users of Prototype to get an idea of how many major sites could easily break with a new version of IE. It's not that these major sites won't be updated ever, but most corporations aren't using the latest versions of everything on their website, even after a new browser release. If you were in the IE team's position, would you really want to break so many major sites? It's commercial suicide. The pages that won't be changed are split into those that cannot be changed: those that physically cannot be changed (e.g., HTML/CHM help files on CDs), and those that are unmaintained. It's not just intranets where content that causes issues is.
There's no point of blaming the IE team for getting the web into the situation that it's in: a large number of issues predate Trident, back when IE used Mosaic, and other issues are a result of multiple things, not least things being invented during the browser wars (DOM and CSS most notably) and browser vendors trying to extend them to outdo the opposition (Netscape is just as guilty of this), but also because of the vagueness of how they are specified (or, in some cases, the total lack of specification).
As the issue is with pages that specifically hack for IE (and those hacks now cause issues), this doesn't mean other browsers will need to spend their time reverse-engineering even more modes — the issue is mostly with sites that rely on IE's own quirky behaviour while at the same time relying on other browsers working fine. It is a non-issue for everyone apart from Microsoft.
Alternatives For A Switch
That all said, the proposed switch, X-UA-Compatible, is, in my option, a horrible solution to the problem at hand. We need another switch that behaves likes the DOCTYPE switch (i.e., it doesn't limit you to a single browser and a single version of that browser). I admit, I'm not sure how to implement this (though I think a version attribute on the MIME type, like Gecko's JavaScript 1.7 solution, is a good basis for ideas). It will need to be opt-in, like the DOCTYPE switch, without question, and also not conflict with Gecko's JavaScript version switch. Let me wave a banner saying I use CSS 2.1 and ECMA-262 3rd edition (the latest version of ECMAScript), and I'll be happy.
Only three other alternatives for switches have come up repeatedly:
- Rebranding IE
- While a quick glance at this makes it seem like a good option, looking deeper reveals the huge flaws: people equate IE as being the web, and a huge number of sites sniff the UA (try using a minor browser like Konqueror to find out quite how large an issue this is).
- Date targeting
- This is specifying the date at which a page was authored. I can assure you, that there are plenty of pages authored in the ten years since HTML 4.01 was published as a recommendation that don't use standards mode. It also assumes that the author has access to the latest version of the browser (IE7 isn't available on Windows 2000, which is still widely used, for example).
- XHTML
- The final thing that has come up repeatedly is using XHTML as a switch (and by XHTML, I mean actual XHTML served as
application/xhtml+xmland not XHTML expected to be parsed as HTML), which falls down as soon as you look at its backwards compatibility, and the difficulty of using XML in the real world. That said, there's no question in my mind that XHTML needs to trigger "edge" (as it does everywhere else).
Multiple Engines
One thing that I think IE8 needs to avoid having is actually shipping with multiple engines: everything should be doable with switches within the engine (this is already done everywhere else). The canvas element works just as well in quirks mode as it does in standards mode in Gecko and WebKit. There's no reason why this can't be the case in IE8 too: the IE team reverse engineered Netscape better than Netscape could themselves, so there's no reason why they can't do this to themselves, and create a compatible engine.
Dealing With The Future
As I see it, there is only one way for IE to move forwards with its standards support, which is with an opt-in switch. I feel that IE is in an identical position to what it was in when the DOCTYPE switch was introduced: somehow, backwards compatibility must be kept while allowing standards compliant sites to work as intended.
What would be nice for many in the web development community would be for multiple releases of the IE8 betas be made: one which switches into IE8 Standards Mode on encountering a standards-mode DOCTYPE (i.e., replacing the current standards mode), and one that only switches into it on a new switch. Let people see how widespread site breakage is.
