Jan22
Standards & Complications
Aaron Gustafson’s Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 is something I’ve been anticipating for a while.
Read that article. Then come back here.
It’s the answer to a question that has been on many of our minds ever since the Acid2 announcement, one in which Dean Hachamovitch makes passing reference to “IE8 Standards Mode.” Yes, this is an actual thing. Yes, it goes beyond ordinary Standards Mode, which requires only a DOCTYPE declaration.
In other words: Acid2 was the good news. This is the bad news. I don’t mind so much, really, because it’s the least painful solution to a problem that needed to be solved.
Why IE needs it
Since soon after IE7’s release, the IE team has been canvassing the JavaScript community for what we want most out of IE8. At the top of the list, to no one’s surprise, was support for DOM Level 2 Events, the nicer and saner alternative to Microsoft’s crazy event system.
But also on the list were myriad and sundry bug-fixes to IE’s astonishingly broken implementation of DOM Level 1. Consider, for instance, how hard it is to make getAttribute behave sanely. Consider how, in IE, document.getElementById will search both the name and id attributes.
It’s clear to me that if the IE team is going to embrace the DOM spec, at long last, it’ll need a clean break from this sound and fury. A more compliant scripting environment should not come at the cost of support for the existing web, one that has accepted IE as the special-needs child. So we need a shibboleth — one that is separate and distinct from the DOCTYPE switch that gives us Quirks Mode and Standards Mode.
Why other browsers need it
They don’t.
Issues
I have reservations about how this will work in practice, but I can tell that each of them has been anticipated by Aaron and others involved in this decision.
-
It’s one more variable to worry about. A particular script will have different effects depending on which version of IE has been specified in the
X-UA-Compatibleheader.Flipside: Of course, this has been true for years because of DOCTYPE switching — the effects of quirks mode propagate all the way to the scripting environment. This time it’s a bit different, but it’s a necessary evil if IE is going to support the DOM standard.
-
Where does it end? The whole point of standards is that you’re coding toward a specification, not towards a particular browser.
X-UA-Compatible: IE=8;FF=3;WebKit=3;Opera=9;OmniWeb=5;Lynx=1;OtherUA=4… there are more browsers in heaven and earth, Aaron, than are dreamt of in our philosophy.Flipside: I don’t know whether other browsers will end up supporting this new header. But I doubt I’ll need to use it for browsers other than IE. At any rate, it’s intended as a “hint” for the browser’s rendering engine, not a bouncer at the door that lets only certain versions into your site.
-
Great that we have the
edgeoption, but why is it “strongly discouraged”? I’m married to standards mode, for better or for worse, and I’m willing to deal with the occasional breakage if it means that I don’t have to update every single page when IE introduces a new version.Flipside: Yeah, but that’s the brilliance of the HTTP header approach. Best practice is to specify an explicit HTTP header, rather than the
meta-tag equivalent, so that there’s a single point of modification when you need to alter that string later on. And that leaves themetatag as an override to whatever has been declared in the HTTP header.
Conclusion
I’m torn about this. But my verdict is a tentative thumbs-up. It’s clear that Aaron and other smart people settled on this approach as the least awful of all possible options. It’s opt-in, it’s quick to implement, and it’s independent from the versioning models of both HTML and ECMAScript.
JavaScript developers, even those who evangelize standards, have long had to make compromises for the real world. I welcome the conflict; it’s a proving ground for the ideas we espouse and can only make our faith deeper and more nuanced.

January 22nd, 2008 at 11:14 pm (Quote ↓)
Well said. I too am kind puzzled about the
edgeoption… not just why it’s discouraged, but why it would even need to exist when you can simply declareX-UA-Compatible: IE=OneMillionAndOne.January 23rd, 2008 at 11:02 am (Quote ↓)
A solid evaluation Andrew, I’m with you on the pros and cons of all of it, but, like you, I think this is the best solution given the massive hurdle we had to overcome.
Unfortunately, I think a lot of people have gotten caught up on the CSS end of things without realizing all the implications on the scripting side, it’s nice to see your post focus on that.
Also, to address your note about other browsers, in retrospect I probably would have rephrased that discussion to say that we tried to engineer the switch in such a way that it would be easily implementable by other browser vendors, should they need it. As you mention, they currently don’t, but that doesn’t rule out the fact that one day they might and this mechanism provides an easy way to allow developers to transition their sites to new browsers when the necessary testing has been done. Furthermore, if IE8 gets it right (and we hope it does), even Microsoft may not need to use version targeting every time a new browser comes out.
January 26th, 2008 at 11:31 am (Quote ↓)
[…] Dupont gives the proposal a “tentative thumbs-up” after breaking down the issues and the flipsides, especially as they concern Javascript […]
February 13th, 2008 at 6:36 pm (Quote ↓)
Looking forward to full DOM support in IE8 too!
However there are so many bugs in IE’s DOM at the moment, I don’t think they can possibly solve them all by the RTM date.
This one alone is Huge!
http://webbugtrack.blogspot.com/2007/08/bug-242-setattribute-doesnt-always-work.html
Not to mention all the .innerHTML bugs.