Rendering Mode Switching Reloaded
22 January 2008
There's been quite a number of negative reactions to the recent announcement that the upcoming version of Microsoft's Internet Explorer will introduce a new way to switch between rendering modes. I personally think the proposal makes sense and is technically okay.
I always wondered how
DOCTYPE switching was supposed to be a long-term solution to the challenge of evolving browsers and standards. It only has two modes: quirks mode and standards mode (plus “almost standards” mode in some browsers). What this means is that rendering bugs in standards mode would need to be fixed without being able to provide compatibility with existing sites relying on the incorrect behavior, or otherwise would need to be left unfixed forever. Talk about a rock and a hard place.
The proposed version targeting, on the other hand, allows a web site to declare specific versions of browsers that it is compatible with. It's not just quirks versus standards, it's (for example) IE7 versus IE8. That's a lot more flexible, plus it's much easier for the average web designer to grasp. And it's a completely different beast than the browser sniffing that we used in the dark ages of the web: Just like with
DOCTYPE switching, it's the browser doing the sniffing on your web pages instead of the other way around, so there'll be no “your browser is not supported” crap going on. And of course a browser can simply ignore the hint and render the site as close to the specification as it is able to.
This might make evolution in at least some web browsers a whole lot easier. As Eric Meyer puts it:
Version targeting allows browsers to much more easily develop new features and fix bugs and shortcomings in existing features, which has the potential to speed up the evolution of web design and development. That alone is reason enough to give it a chance.
What's being suggested is an HTTP header that browsers can use to determine which version of a browser a site has been tested and deemed compatible with:
Depending on such a header, the browser can choose to simulate the rendering bugs present in that version. And of course this also works via
<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3">
If that header is not specified (or the
IE= value is less than 8), IE8 will render mostly the same way as does IE7 today. That's a good thing because you don't need to worry about your existing sites being broken by new IE versions. On the downside, you'll have to use this header/tag if you want to take advantage of rendering bug fixes in those versions. To make IE8+ always use the most current (and hopefully closest to the standards) rendering mode you can use the magic
Obviously you won't want to do that on any mainstream site.
It's pretty clear that the IE team thought that something like this was absolutely necessary due to their experience with IE7, which apparently broke a ton of sites. They had underestimated the number of sites using a proper
DOCTYPE (thereby triggering standards mode), and the kind of workarounds those sites used to actually make things work in IE6. Given the requirement, I think that the design choice made here is pretty nice. The alternatives that were considered included conditional comments (which are plain evil) and XML processing instructions (which don't really fit that well into the non-XML web we have today and for the foreseeable future.)
I hope that version targeting will only affect bugs in the rendering engine. For example, if IE7 gets some margins wrong (a rather common occurrence), and you need to work around that by passing it incorrect margins (using CSS hacks or conditional comments), those workarounds should not break your site when IE8 comes out with that bug fixed.
If, on the other hand, IE9 finally makes
<textarea>s resizable (a feature pioneered by Safari 3), and you've targeted your site at IE8, the users of your web site should still be able to resize their text areas. If, in a couple years from now, you use some new HTML elements introduced by HTML5, targeting your site at IE8 should not take support for those elements away.
The scope of version targeting should be limited to fixes to the rendering engine. The browser should not completely morph into the piece of software you were using four years ago. It should just provide the compatibility needed to render your site correctly. Thus, on some level I hope that version targeting will not lessen the need of using virtual machines (or multiple browser version installations) to test web pages, as Eric Meyer suggests in the article linked to above.
One question is why the IE team thinks such a mechanism is so dearly needed, while other browser vendors say it isn't necessary. One reason may be the larger installed base of Internet Explorer. Another reason may be the comparitively low level of standards support—and the number and severity of rendering bugs—found in current versions of IE. But the main difference is that there are many, many web developers out there who still design their sites solely with (and for) IE. Sometimes it's because they're working on Intranet applications for companies that only use IE. Other times it's just ignorance and incompetence. Often it's both.
On the other hand, those web designers who primarily develop their sites with Firefox, Safari, or Opera, are a lot more likely to test their stuff on all of the major browsers (which includes spending way too many hours getting stuff to work correctly in IE6 and IE7). Constantly testing across multiple browsers naturally leads to developing closer to the specifications.
I don't think we'll see the other browser vendors adopt this mechanism in the near future. But if there's ever a need for one of those browsers to change something in a way that might break existing standards-mode sites, using version targeting to avoid or at least minimize that breakage would be a viable option. (Although I don't want to imagine what the implementation of a rendering engine might look like after a couple such iterations. Hello complexity.)
Now, it'd sure be better if version targeting was not needed at all. That is, if browser vendors never introduced rendering bugs that various web sites would rely on staying around. But that's not what reality looks like, at least not for Internet Explorer. And given the choice of no fixes to rendering bugs, and fixes that first need to be enabled using version targeting, I'd rather take the fixes.