IE8 And Version Targeting

Since the earliest days of the IE/NS browser wars, developers have struggled with inconsistent rendering issues across not only the Great Browser Divides, but also across versions. In 2000, Microsoft released IE6, which changed significantly from the previous version. To help protect sites that were developed around IE5.5's... unique... rendering bugs design features, Microsoft initiated DOCTYPE switching. In the early days of web development, not many sites put much focus on standards compliance. Just getting it working in two browsers was a feat in and of itself, nevermind trying to work in such trivialities as well-formedness or semantics.

So Microsoft's idea was to use the invalid nature of websites to their advantage. If a website had an outdated, malformed, or non-existent DOCTYPE, the designer probably didn't know what they were doing, and IE6 would render the site using IE5.5's incorrect (but designed for) box-model. The so-called “Quirks Mode”. If the site had a valid DOCTYPE, IE6 rendered it using the new engine and a (more) correct CSS implementation, “Standards Mode”.

A great idea, but it just isn't sustainable, as shortly thereafter, the Standards Police came in and everyone started doing things the right way. Skip ahead 7 years, and out comes IE7, which is leaps and bounds ahead of IE6 (though certainly still with faults). Now sites are presenting valid DOCTYPE's, but were still relying on their outdated box-model hackery, which IE7 promptly chokes on. We'd been developing for IE6 for the better part of a decade, and when we finally get used to all of her little quirks, BAM! IE7 is sprung on us and destroys it all. The developers at Microsoft had broken their cardinal rule for IE development, “don't break the web.”

Apparently, the boys from Redmond have learned from their mistakes, and are planning an interesting version targeting system for IE8, which is due to be released later this year. In concert with the Web Standards Project, MS has proposed a new meta declaration, X-UA-Compatible, which will allow designers to specify which version of IE should be used to render their pages. If you want IE8's brand spankin' new rendering engine to take a crack at it, set X-UA-Compatible to “IE=8”. If you'd rather stick with tried and true IE7 rendering, “IE=7”. If you always want to use the latest engine, from IE8 through IE666, use “IE=edge”. Now, you no longer need to worry about your site breaking if a visitor upgrades their browser before you've fixed any issues with it, and at the same time, you can take advantage of the better rendering capabilities if you need to.

Some other benefits offered include no longer needing multiple instances of IE running on the same machine. Get IE8, and just switch your X-UA-Compatible to 7 or 6, and you can test your site in all three versions with little more effort than hitting refresh. It also changes our entire method of browser targeting. Now, we look forward. If the browser's UA string contains this, do that. But that quickly breaks if the UA's change (a la Safari's questionable decision to include “Gecko” in it's UA, thus defeating almost all browser sniffers). Version targeting puts the onus on the browser, not the developer, and renders back to a specific version, instead of us trying to predict how future versions will handle things.

Of course, there are also significant issues that arise from this new system. For instance, just how faithful will the older renderings be in IE8? Can we really rely on the new system to exactly match that which we've come to expect? How many versions will be available, and how will we know which are available to our users? If IE8 includes multiple rendering engines, how long do we have until browsers become bloatware?

Fortunately, IE8 is still a few months out, and we can hopefully get some answers to these questions before our sites start exploding.