Skip to content
Biz & IT

Wisdom and folly: IE8’s super standards mode cuts both ways

Microsoft plans for Internet Explorer 8 to be the most standards-compliant …

Ars Staff | 0
Story text

Unpacking Internet Explorer 8's multiple rendering modes

Internet Explorer 8 is going to be the most standards-compliant IE yet, but it's going about it in a way that has some people scratching their heads. With Internet Explorer 8, you have a choice in standards compliance modes. Sound oxymoronic? Shouldn't there be one standards mode by default? Heck, shouldn't the only mode be standards mode? Ah, idealism.

One of the nastier things about being a web developer, I'm told, is the existence of Internet Explorer. Massively popular, but full of "quirks," coding around IE can be a real pain. When IE7 shipped, many web developers recoiled in horror as sites that worked fine in IE6 broke.

The problem, as is so often the case, is backwards compatibility. IE5.5 (and below) was decidedly nonstandard in its rendering behavior. Hundreds of millions of web pages were written to look "right" in IE5.5's broken rendering. The result was something of a quandary for Microsoft when it came to release IE6. They wanted to improve the standards conformance in IE6, but couldn't afford to break pages dependent on the older behavior.

The solution was the "doctype switch". The doctype switch allowed IE6 to support both the old IE5.5 behavior—"quirks mode"—and new, more standards-conforming behavior—"standards mode." Doctypes are an optional part of HTML pages, which specify which version of the HTML spec a page is using. In the olden days of the web, most web pages didn't bother to specify—they barely heeded the mandatory parts of the standards, let alone optional parts. So the presence of the doctype could be used to pick between modes—if someone used a doctype, they probably knew what they were doing, and wanted "standards mode." No doctype (or a doctype specifying an old version of HTML) and they were probably assuming nonstandard behavior, and "quirks mode" would be picked.

At least, that was the theory. The thing about IE6's "standards mode" is that it wasn't all that standard. Although it fixed some of the bigger issues IE5.5 had, it still had plenty of its own. With IE7, MS tried to fix a few more of the nonconformance problems. The intent was to keep "quirks mode" the same as it always had been, and to further improve "standards mode." What the company discovered when it did this was that people using the doctype weren't actually expecting "standard" behavior. Rather than writing pages to target the HTML specifications, these pages were written to work with IE6's still-not-standard-but-better-than-before behavior. So, they didn't work with full-blown "quirks mode" rendering—but they didn't work with 100%-standard rendering either.

Sometimes this was deliberate—developers taking standard pages (that work properly in, say, Safari) and adding hacks to them in order to get an acceptable appearance in IE. Other times, it was accidental; developers added the doctype because it was fashionable to do so, or because their design tools added it automatically, without fully understanding the consequences of the switch. Whether by accident or by design, most pages using "standards mode" are expecting IE6's own unique take on "standards mode", and not true standard behavior.

The upshot of this is that IE7 broke pages that used to work in IE6. Both business-critical intranet apps and the Web in general stopped working—not normally fatally, but enough to throw out layouts and make pages look wrong. This undoubtedly hurt IE7's uptake, and that has Microsoft concerned. IE7 is finally going to be put out as an automatic update in the next few weeks, and the reason it has taken so long is this reluctance from businesses. If the standardization changes were made to "standards mode," using the doctype switch, all those pages demanding not-really-standards-mode will break. That's a lot of pages, and they'll break even more badly than they broke with IE7.

Which brings us to IE8. With IE8, Microsoft wants to further improve the standards conformance of the browser, to bring it up to a level that's comparable to Firefox 3, Opera, and Safari. Experience with IE7 and the doctype switch leaves the software giant concerned that further fixes to "standards mode" will, in the company's words, "break the Web."

The IE8 solution: add another layer

When IE8 eventually ships, it will have three rendering modes, two of which are the already familiar "quirks mode" and "(not so) standards mode." In an IE team blog entry, IE Platform Architect Chris Wilson revealed a third mode that can be invoked by developers:

  1. "Quirks mode" remains the same, and compatible with current content.
  2. "Standards mode" remains the same as IE7, and compatible with current content.
  3. If
    you (the page developer) really want the best standards support IE8 can
    give, you can get it by inserting a simple <meta> element.

This third mode will use a <meta> tag to specify that a page should use the behavior of a specific browser version. To get IE8 really-standard-this-time-we-mean-it behavior, a page will include an element like <meta http-equiv="X-UA-Compatible" content="IE=8" />. That says that a page should use IE8's behavior—and should use it even in IE9, IE10, or any future version. The first two modes will continue to use the doctype switch to choose between them.

This should solve the problem that so hurt IE7. The developer expectation that IE's "standards mode" should remain the same indefinitely should be met. As long as a page works in IE7, it should continue to work in the same way in IE8.

The idea for this new tag was not developed by Microsoft in isolation. The company worked with the Web Standards Project (WaSP) to devise this mechanism, to allow the existing web to work, and the future web to be standards compliant. Aaron Gustafson, one of the members of the WaSP-Microsoft task force who devised this scheme, published an article on A List Apart further detailing the specifics of the declaration.

The problem with the third mode

Although the reasoning behind the decision is understandable—the Web has a huge legacy of pages expecting a particular rendering mode, and breaking those pages is undesirable, or even a blocking issue that prevents uptake of a new browser—it nonetheless feels somewhat unsatisfactory.

The accuracy of web page rendering is a big problem. On the one hand, the idea of "standards" is that development doesn't target a particular vendor, but instead the "standard," and can trust that the page will look as it should in any standards-compliant browser. This meta tag, for picking a specific rendering mode, feels like it is missing the point, because it goes against this notion of coding to the standard so fundamentally. On the other hand, the reality is that developers do limited testing and expect their pages to look and work a particular way, and don't expect their page to break just because someone is using a newer browser. Changing how a browser interprets the standards (even if it's to make that interpretation closer to what it should be) changes how a page looks, and by and large that is not something any web developer wants or expects.

In an ideal world, "standards mode" would have been, well, standard. If it had been, this problem would never have arisen. The doctype switch would do the job. Quirks mode would still have to exist, of course—for all those really old, nonstandard pages—but there need only be one "standards mode." But the world we live in isn't ideal. Although IE is the worst offender here, it is not the only browser to fall short of the standards. Other browsers have minor gaps and omissions, not to mention bugs in their implementations. The problems that IE suffers are felt by the other browsers too, albeit to a lesser extent.

The price of continuing to improve "standards mode" is quite reasonably felt to be too high to make this a viable strategy. "Don't break the Web" is one of IE's guiding principles, and it's a pragmatic principle. The Web is not all actively maintained—all-but-abandoned pages are abundant—and demanding that web developers update sites to ensure they continue to work properly in any future browser version is probably too much to ask.




Image courtesy of Alan Foreman

This is not the easiest option for Microsoft to choose, either. It would be simpler to scrap "IE7 standards mode" and instead just have a "true" standards mode, to work alongside quirks mode. Going into the future, the company will effectively have to maintain a mode per browser version. So IE8 will offer "IE8," "standard," and "quirks" modes. IE9 would add a fourth, "IE9" mode, and so the number of modes will proliferate as new versions of the browser are released. Whether this is really tenable is not obvious; it seems liable to make the browser larger and more complicated than it should be, and this will surely leave it at a disadvantage, especially if competing browsers go down a different path. If the Firefox, Opera, and Safari developers decide that "standards mode" will always track the standards and so (potentially) change a page's rendering, they will be able to stick to the dual rendering modes they have today, and so their browsers will be comparatively more svelte. (Unofficial) statements by Opera and Mozilla employees and/or developers are quite critical of Microsoft's plan, so it certainly looks as though other browsers will not follow in IE's rendering footsteps.

Further, once Microsoft goes down this path, it looks difficult to see how it could renege on the (implicit) promise that it will retain accurate versioned renderings. If Microsoft goes ahead with the plan, the company will be stuck with it for a long time. That said, changes probably will creep into the old modes anyway, even if only by accident. Fixes for security issues or other bugfixes are liable to inadvertently change the behavior. It would be pretty surprising if the version-specific rendering were to remain truly version-specific without any deviation, and if it does not achieve that then one must question the point of the whole exercise.

Professionally, I have a vested interest in retaining "accurate" rendering (by which I mean "as the author intended" rather than "as the specification dictates") of old web pages; one aspect of my day job is to provide authentic access to obsolete technologies, including web pages, and mechanisms of this kind tend to make that easier. So I am absolutely sympathetic to Microsoft's desire to not "break the web" and provide strong support for broken pages in its browser.

But equally, I think that short-term pain can provide long-term gain. Cleaning up the Web, by making developers produce standards-compliant code, and developing browsers that offer a consistent rendering experience (which IE8, FF3, Opera, and Safari should manage, for the most part) should make browsers simpler, and hence faster, smaller, and more reliable. Even Microsoft cannot relish the backwards compatibility demands that this approach will force it to deal with. I can't help but feel that we would be better off if IE's development team bit the bullet and fixed up "standards mode" to be as good as the competition (and keep it that way), and just accept that there will be some number of broken pages as developers transition to "true" standards compliance. This may superficially break the Web, but it would give it a much more solid foundation for the future, and that is arguably a trade-off worth making.

0 Comments