I’m sure by now you’ve seen the latest issue of A List Apart. Therein, Aaron outlines Microsoft’s implementation of rendering switching based on a
meta element and Eric describes how his initial feelings about the technique changed over time.
I’d like to make one thing absolutely clear. You might infer from A List Apart or from the IEBlog that there was collaboration between the Web Standards Project and Microsoft on this. That is not the case. There was collaboration between some members of the WaSP and the IE team but, as Drew makes very clear, most of us were completely in the dark about this. I knew that something was coming but I didn’t know what because Microsoft will only collaborate under NDA. That is not a good situation. NDAs are poison to free and open discussion.
With that out of the way, let me tell you what I think of the proposed
http-equiv="X-UA-Compatible" instruction. I think this could have been a great feature—exactly the kind of innovation that Alex was talking about. It could have been a way of solving Microsoft’s fear of “breaking the web” for existing customers who have coded their sites to the current level of browser support—the people who understandably don’t want to have to change their sites when a new browser is released.
Here’s how the
X-UA-Compatible works. In a
meta element or
HTTP header, an instruction such as
IE=8 tells future versions of Internet Explorer to render the document as a specific version would (IE8 in this case). In theory, any future versions of Internet Explorer will retain the ability to render documents just as they would have been rendered in previous versions.
This solution was driven by the perceived problems with IE7’s release. Personally, I believe that Microsoft did a great job with IE7 but I know that within the company, it was in some ways seen as a failure. Many customers complained of IE7 “breaking” sites that worked just fine in IE6 (where “break” is usually defined as “not looking the same”). This is a legitimate source of concern for Microsoft. The proposed
X-UA-Compatible header will solve this problem. Customers who don’t want their sites to behave any differently in future versions of Internet Explorer can lock down the rendering to the current browser.
So far, so good… great, in fact. But—and this is a huge “but”—if you don’t include a
X-UA-Compatible instruction, you are also condemning your site to be locked into the current version: IE7. This is a huge, huge mistake.
Let’s say you’re building a website right now that uses a CSS feature such as generated content. Any browsers that currently support generated content will correctly parse your CSS declarations. Future browsers that will support generated content should also parse those CSS declarations. This expected behaviour will not occur in Internet Explorer. IE8 will include support for generated content. But unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.
I can’t believe I just wrote that sentence. This shouldn’t make any sense:
Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.
That’s madness! If I don’t use the
X-UA-Compatible instruction, I won’t get the benefit of any future improvements in Internet Explorer. That sounds like blackmail to me. There is an option to activate whatever is the current browser version—which, of course, should be the default behaviour. This is achieved by using the (strongly discouraged)
IE=edge value in… yup,
http-equiv="X-UA-Compatible". So even if you want to opt out, you have to opt in. That too is madness.
Just to be absolutely clear on this, I think that the
X-UA-Compatible header is a great idea. It’s great for Microsoft. It’s great for Microsoft’s customers. But the default behaviour is wrong, wrong, wrong! This should be an innovative feature, not a mandatory part of the process of creating a document on the World Wide Web. *
IE8 has not yet been released. It’s not too late for this broken default behaviour to be changed. If enough of us make our case clearly, perhaps Microsoft will listen to us… even if we haven’t signed NDAs.
For more on this, please read
- Chris Wilson’s justification of the new feature,
- the discussion accompanying Aaron’s ALA article,
- the discussion following Eric’s ALA article,
- Anne’s reaction and
- Robert O’Callahan’s list of browser implementation issues.
*As for all the comparisons to
DOCTYPE switching, can I just point out that the reason why I put a
DOCTYPE on my documents (and the reason why the WaSP lobbied authoring tool vendors to do the same) is because valid (X)HTML documents require a
DOCTYPE; not because it makes Internet Explorer render in a different mode. The tail does not wag this dog. If I write a valid (X)HTML document with a correct
DOCTYPE, surely I should expect a browser to render it to the best of its ability rather than crippling itself?