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
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
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
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
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<wbr>;OmniWeb=5;Lynx=1;OtherUA=</wbr><wbr>4</wbr>… 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 the
metatag as an override to whatever has been declared in the HTTP header.
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.