Has Internet Explorer Just Shot Itself in the Foot? | January 22, 2008
If you haven’t read the latest posts on A List Apart, you should pop over now. Don’t worry. I’ll be here when you get back.
- Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8
- From Switches to Targets: A Standardista’s Journey
Oh hello! So what did you think then? If you’re anything like me your first reaction was probably a mixture of intrigue, confusion and disbelief, followed by an expletive along the lines of “what the f#@k”!
To quickly summarise, the Internet Explorer team have floated the idea of setting a meta tag in your document to defines what version of their browser your site has been designed for. The logic is somewhat similar to the current process of DOCTYPE switching, but with more granular control. So if you’re worried that your site may break on IE8, you can add the following line of code at the top of your document, freezing it to IE7 style rendering.
<meta http-equiv="X-UA-Compatible" content="IE=8" />
I’m not exactly sure how the browser plans to implement this, but I imagine it would involve multiple rendering engines or a really complicated set of rules and exceptions. This seems like extra work for the IE team, but it’s an interesting idea.
This idea has come about because Microsoft are worried about “breaking the web”. Essentially they’re concerned that new browsers will stop rendering older pages correctly, annoying site owners, browser users and—probably more importantly for Microsoft—corporate customers. If we look at the bigger picture, this logic does make a certain amount of sense. If I, as a regular Joe user, download the latest version of IE, I expect it to do etter job at displaying websites. I don’t expect my favourite Geocities page to suddenly break.
Backwards compatibility is a legitimate concern, and one that keeps cropping up in the discussions over HTML5. After all, we do risk losing some of our digital heritage. However this issue obviously needs to be put in perspective. By constantly worrying about the past we risk missing out on the possibilities of the future. Imagine if all new media players had to be backward compatible? We’d end up with a device that could play anything from 8mm film right the way through to Blu-ray disks. It would be nice, but incredibly bloaty. Eventually we’d start dropping support for old media, or just stop inventing new ones.
But I digress. As developers what we want is the ability innovate and use new tools to create better experiences. One of the great things about CSS is the way it allows us to use the concepts of progressive enhancement or graceful degradation to seamlessly supply different experiences to different browsers. This forward compatibility is one of the fundamental tenants of the web standards movement, so if something comes about to threaten that, it’s understandable the developers would react badly. Browser targeting appears, on the surface at least, to threaten this, so developers are understandably a little miffed.
Now the main problem isn’t with the concept itself. After all, if developers want to freeze their site at IE7, that’s all fine and dandy. The problem is the default behaviour. Logic would suggest that unless a developer actively chooses to freeze their browser version, the browser should go on rendering a page in the fail-tolerent way they always have. If a site then breaks—usually because of browser specific coding—the developer can add in a single line of HTML in order to fix the problem.
Unfortunately the default behaviour doesn’t currently work this way. Unless you explicitly set a version number or use the “edge” keyword to target the latest version, the browser will automatically render in IE7 mode. My esteemed colleague Jeremy Keith, puts it thus.
“Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”
When you put it that way, it does sound kinda nuts. No matter what future version of IE you’re using—be that IE8 or IE80—if the developer hasn’t added the appropriate meta tag, you’ll be viewing the site as if in IE7.
While I disagree with this default behaviour, I do sort of understand where it comes from. It’s all to do with fail-safes and perspective. From a developer perspective, unless I’ve asked my browser to behave differently, the fail-safe should always be to act in the most open, modern and standards compliant fashion possible. However from the average users perspective, the browser should always attempt not to break stuff that used to work just fine. This forms a bit of an impasse and it the crux of the problem.
The big irony is that, by doing this, Microsoft have set up the ideal conditions to marginalise their own browser. Clueless developers won’t know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers. Users will see less benefit from upgrading and will be more likely to turn to other browsers. In fact the only people to benefit are the small minority of web standards developers who use Internet Explorer as their primary browsers.
No matter what great leaps forward the Internet Explorer team make from now on, the majority of developers won’t use them and the majority of users won’t see them. By doing this the Internet Explorer team may have created their own backwater, shot themselves in the foot and left themselves for dead.
Posted at January 22, 2008 7:20 PM