Painfully Obvious.

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-Compatible header.

  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 edge option, 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 meta tag 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.