IE8 and Standards compliance

It’s been quite entertaining to read the comments in IEBlog’s latest post on the IE8 Standards Meta Tag. It comes as no surprise that some people react like they have their head up their ass pretty far. The sentiment seems to be that the IE team is following the wrong course by providing yet another way to indicate how to render a page. After all, this is what the doctype switch was invented for.

The problem is that we both have standards and implementations of those standards. No browser fully supports each standard, and subsequently has it’s own implementation of each standard (which could also be: we don’t have an implementation).

X-UA-Compatible

Therefor, I think the solution as it is explained in this article at A List Apart is good enough for the situation web developers are facing. It allows to lock in a implementation of a site/webapp to a specific version, which makes sure that that site/webapp will still work as intended when a new version of a browser (with new standards, and new implementations) is released. Of course, this means that the onus is on the developer to actively support every new standard and implementation, but that’s already the case for the most part. The work you need to do to support IE8 (or IE9, or IE10, …) is minimal: just add or update the X-UA-Compatible metatag, spit out the correct HTML/CSS/JS and you’re done with it.

The good thing is that you won’t need to check if your site will actually work in IE-new (or any newer browser), because it doesn’t need to unless you specifically say it will (by updating the tag). In effect, this creates explicit side-by-side browser versions in the same browser. Sites targeted at older versions will still work as they were created (which was not the case with IE6->IE7), and it’s easy to start supporting new technology when it comes out.

Side-by-side versioning

This is actually the same kind of system as the .Net frameworks use: the generated binaries not only know what framework it needs to run, but also what versions of any supported libraries are needed. When you update your code to use a new framework or a newer library, the old binaries still work (provided that the old framework and libraries are still present) as they were intended when the author compiled them. When you want the new version, upgrade to a new framework/libraries and you’re done.

In other words, instead of coding against standards, you’ll be coding against implemetations of standards. While this seems to be more work (and it is), it’s actually better because you know what to expect even in the future. It means that your work will keep on working and displaying correctly.

I think that other browsers should incorporate the same mechanism. I also think they will, because it’s the best solution for the standard+implementations versioning problem.

CSS support

On thing that I think is missing: have support for the X-UA-compatible tag to reference implementation specific CSS and possibly Javascript. Why? Because it represents a minimal effort to add support for a new browser version (with new features) to an existing site while maintaining support for older versions. While this means that you’ll have version specific CSS files, I still think that’s better that having your site break. This is easier to do in Javascript (most sites already do this, eg check for document.getElementById or document.all) but not in CSS. Getting the CSS spec changed to support this will be too hard, so I guess providing a x-ua-compatible=”ie8″ to any CSS reference (beit a <link> or <style>) will suffice.

Getting it right

This is all assuming that IE8 gets it right this time. The sole reason for this hack is the lack of correct standards support (I’m not talking about partial standards support). Most of the CSS hacks in existence are there because IE screwed up an implementation in the past. This is also the reason that browsers like Firefox and Opera don’t really need a solution like the X-UA-Compatible tag: there aren’t many glaring (layout) bugs, and most of the time they’re fixed quickly when found. The 5 year gap between IE6 and IE7 established an acceptance of the bugs in IE6 (not in the least because of IE6’s large marketshare).

Of course, this doesn’t mean that IE8 will get away with a lousy implemenation the standards they’re implementing. It’s in their best interest to actually provide a solid implemenation. I hope they get it right this time. The fact that they stepped to the WASP for a solution to this specific problem, is a very good sign indeed.

Like Jonathan Snook puts it: I for one welcome our X-UA-Compatible overlords.