There are several key points worth bearing in mind whilst you read this:
- In the spirit of openness and community-driven standards, Microsoft took the decision to impose an HTTP header in order for standards-compliant sites to render and operate in a standards-compliant fashion in IE 8 behind closed doors and without consulting with the web development community/industry at large.
- The problem apparently looking for a solution, “don’t break the web”, is horribly underspecified, but the consensus appears to be that this primarily refers to intranet/extranet sites and corporate web applications rather than the public sites.
- When IE 7 was released, it did “break the web” as far as Microsoft was concerned [because IE 7 didn’t respond to IE-specific hacks the same way that IE 6 did], and developers ultimately did one of three things: (a) nothing (didn’t care), (b) wrapped up the hacks using conditional comments such that only IE 6 saw them (additional IE 7-specific hacks were wrapped up in similar conditional comments), (c) nothing… yet, but intend to when the corporate desktop has IE 7 (or are otherwise in the process of fixing things for IE 7).
- X-UA-Compatible is apparently a done deal: the decision has been taken, code written. The IE team didn’t ask web developers what they thought, if they had any better ideas (as smart as the IE team are, the collective experience of the web development community specifically and Internet community in general when it comes to issues like this significantly outweighs that held internally), they just said “this is what’s happening, leave comments below [no guarantee we’ll do anything except defend our position]”.
- Other browsers don’t suffer from any of this because, barring minor issues, they’re pretty conformant with the heaviest-used portions of the standards: there is no similar legacy (and they’ve never paid attention to any of the IE-specific hacks by definition). IE, on the other hand, is playing catch-up: persuading it to render a complex page based upon standards that have been in the wild for many years without any hacks is very difficult indeed.
- Having been bitten by the “the current version of IE is the only version of IE” problem when IE 7 hit the streets, developers are a lot more savvy now and specifically target particular versions for particular sets of hacks. If pages behave correctly in Presto, Gecko and WebKit, they should (see below) behave just the same in IE 8.
- …except, we don’t know what on earth is actually in IE 8, because there are no nightly builds available; the whole culture of secrecy is far more likely to “break the web” than anything else.
- The intention of Microsoft is to essentially set IE 7’s behaviours in stone from here on in: IE 7, warts and all, will be the de facto baseline unless you say otherwise.
Now, with all of that in mind, read on…
First of all, there is a class of site which will be affected when IE 8 is released: those sites which don’t render correctly in browsers such as Firefox, and the authors (for whatever reason) don’t care, but that do work correctly in IE 7’s “standards-mode”. This is the only class of site deemed problematic. The other class of “risky” site—the ones that render in quirks mode, won’t be affected because they behave pretty much the same way in IE 5.5, IE 6, IE 7, and (when it appears), IE 8. The number of sites out there that fall into the latter category is huge compared to those who fall into the former. The ones in the latter category are basically built by people who don’t actually care about the standards at all, and generally couldn’t care less if your glaucoma-suffering aunt can use the the thing, or anything else about “that accessibility rubbish”—you get the idea.
No, the problem is the former category: sites who claim to the browser to be standards-compliant, and render properly in IE 7 and do so using hacks which will cause the pages to behave differently in IE 8 if it actually complies with the published specs. This is the “web” that Microsoft thinks it must not “break”, and indeed would rather the rest of the web development world went out of its way in order to stand still than make any attempt to persuade the authors of these sites to do something similar.
With me so far? Or are you reading this, furrowing your brow, wondering if there can possibly be quite so many of these sites in existence for it to be a problem? I know I am, because I know how long IE 7 has been in the wild for, and compared to IE 6, it’s not very long at all.
All web developers wanted from IE 8 was a browser that worked as the others did: you build a site, do some cross-browser testing (which usually turns up bugs in your code because some rendering engines are more permissive than others), and off you go. That is, without having to tweak, tune, hack or work-around oddities in behaviour to make it work. The X-UA-Compatible proposal is essentially completely contrary to that, because web developers will always have the choice of (a) hack the pages for IE 7, or (b) add the header/tag to state that it’s really built to the standards. For a while yet, we’ll have to do both (because IE 7 will be in the wild for some time to come), but eventually it’s a choice between (a) or (b).
If all of this sounds like it could be slightly anti-competitive, you’d not be the only one thinking that: it actively encourages people (because it’s the default) to dumb down for IE 7, just as people did for IE 6 and previous; it’s a self-perpetuating lock-in, because so long as there are pages out there without the X-UA-Compatible header/tag (and trust me, there will be for… well, ever), it makes the case to Microsoft’s management gurus that IE 7’s broken rendering engine needs to be supported.
Now, I don’t know about you, but I consider “you have to actively modify your standards-compliant pages in order for them to render and behave correctly” the definition of a non-conformant user-agent. This means that, from the outset, and forever more, Microsoft has failed to deliver the one single thing that IE was supposed to.
So, we’ve established that:
- The number of problem sites is actually pretty small;
- in order to work around their issues, Microsoft proposes to never produce an entirely standards-compliant browser;
- Microsoft’s solution to the problem actively encourages lock-in;
- rather than encourage fixing of the problem sites, or making it possible for people to specify “compatibility zones” (akin to the security zones; pushed out via Group Policy Objects), everybody else has to do the hard work;
- IE 7’s behaviours will be preserved by Microsoft for as long as IE exists.
Preserving IE 7’s behaviours isn’t a bad thing, if things out there—things Microsoft considers to be critical—are in widespread use. Making IE 7’s behaviours the default, on the other hand, defeats the purpose of updates. Some folk, such as Bruce Lawson have already identified reasons why this is a very bad thing for not-necessarily-obvious reasons. One could argue that Microsoft could make minor changes to the behaviour of its IE 7 compatibility engine to fix glaring issues, but then some site out there would likely depend on those issues being present and the prospect of that is the sort of scary thing that got us into this mess in the first place.
Of course, there is one angle to this that I haven’t discussed: the fact that an HTML 5 DOCTYPE being present is equivalent to specifying via X-UA-Compatible that you really do want your site to be rendered in proper standards mode. The slight wrinkle in that is that there are virtually no pages out there that actually do use the HTML 5 DOCTYPE, so we’ve still got to make changes (add the tag, change the DOCTYPE? Which do you think would need more cross-browser testing?). Indeed, last I tried using the HTML 5 DOCTYPE, I ran into all sorts of issues—though they may well have been resolved in the current releases of pretty much everything now.
In short, the whole concept is broken: the identification of the problem, the identification of the solution, the negative effects of the solution, and it places an undue and inappropriate burden upon those of us who’ve done it all correctly from the outset.