Putting The 'Backward' in 'Backward Compatibility'
- Wed Jan 23 2008
-
So some recent decisions and announcements by Microsoft’s Internet Explorer team regarding how standards-compliant rendering will work in the forthcoming IE 8.0 has sparked a big discussion on these internets of ours about whether
DOCTYPEswitching — up to now the only way to force IE to even try to render pages correctly — is the same thing as browser sniffing, and whether the IE 8 team’s proposed “solution” is or is not stupid.Before you keep reading (and before I keep writing), let’s all get up to speed by catching up on the discussion:
- Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 and From Switches to Targets: A Standardista’s Journey on A List Apart
- Standards mode is the new quirks mode on 456 Berea St.
- Versioning, Compatibility and Standards on the WebKit project’s Surfin’ Safari blog.
Just to give you the nickel tour of the issue: Microsoft developers, being a pack of craven, cowardly nincompoops who wouldn’t know innovation if it walked into Steve Ballmer’s office and did an interpretive dance, have committed themselves to maintaining backward compatibility in IE 8 for any web site authored for IEs 6 and 7. On the one hand, this is admirable. After all, for many non-technical users (grandmothers, office workers, my trainer) IE really is the web, and they’re the folks least likely to understand that a web site they use every day is broken because its code was written for a browser older than the War on Terror.
On the other hand, if the IE team is in agreement that standards are good and the way to go for the future, why are they encouraging nearly a decade’s worth of lazy code and practices by continuing to support them? The obvious reason is that Microsoft’s core business is catering to large enterprises, who’ve invested billions of dollars building web-based applications on the IE platform and would be upset if those apps suddenly quit working because a bunch of nerds decided in between Magic tournaments that CSS padding should make a box wider, not narrower.
Anyway, I digress. The real concern behind what we’re talking about is not (just) IE 6 quirks mode, which deserves to be left on the ash heap of history, but also the flawed “standards” modes in IE 6 and 7 which have caused web developers to spend millions of hours researching and using hacks and workarounds to make Microsoft’s browser behave. If IE 8 were to apply its standards mode the same way IE 7 does (via
DOCTYPEswitching), it’s likely that any IE hacks present on a given site would cause it to break.So the IE 8 team, in consultation with the Web Standards Project, have come up with a “sweet” (in the sense of iPhone web apps, that is, not at all) solution: requiring web page authors to include a
METAtag specifying which version of IE their site should work on in order to activate standards-compliant rendering.First, to get down to brass tacks: yes, it is good that IE 8 has passed the Acid2 test and will most likely render my web sites the way I intended, the same way they render in Safari 3, Firefox 3 and Opera. And if a one-line
METAtag is what I need to make that work, I’m down with that. Standards are good. Standards are great. Yay standards.However, let’s just step back a moment and return to the true nitpicky issue here: why is it my problem that Microsoft’s idiot customers locked themselves into IE 6’s grotesque interpretation of HTML and CSS?
Standards should be adhered to not because they work a certain way in a certain version of a certain browser, but because they’re standards. Smart web developers don’t put
DOCTYPEs on their web pages just to activate IE’s standards mode; they do it because it’s part of the HTML/XHTML specification and it helps user agents understand how to interpret the document. And yes, triggering standards mode is part of that, but it’s not the only part nor the most important.When you write broken code, things should break, or else you have no incentive to write non-broken code. Microsoft is trying to make bad rendering the permanent default behavior for Internet Explorer, by forcing anyone who wants standards to opt into them. Meanwhile, they continue to make it difficult (if not impossible) to run older IE releases concurrently with new ones on the same machine, so you can’t just tell someone to install and run IE 6 if they need to use a site with some deprecated code.
Here’s a brain-teaser for you: if you have to add a harmless-but-unusual
METAtag to standards-compliant HTML code to make it work properly in one or more browsers, is the code still standards-compliant? Technically the answer would be yes, since theMETAtag is part of all the current HTML specifications and the proposedX-UA-Compatibleheader would be harmlessly ignored by browsers that don’t support it.But you could hardly say the browser is standards-compliant. Unless I’m remembering wrong, the XHTML and CSS specs do not say I need to send a certain HTTP header or
METAtag for my code to be interpreted correctly. Sure, IE 8 may be able to pass the Acid2 test after it’s received that special header, which means it ought to be able to passably render web pages I wrote for Safari 2 two years ago. But calling it a standards-compliant browser is a bit of a stretch.