A few days ago, the web development community exploded into an uproar concerning the IE team’s plan to introduce a new method of triggering standards compliance mode in Internet Explorer 8. Web developers, with justifiable but thinly veiled vitriol, ripped into Microsoft and the Web Standards Project for going along with this scheme.
In essence, what the IE team wants is web developers to “opt-in” to new renderer features using a custom meta tag or HTTP header. Pages will then be frozen at that renderer, ensuring they remain consistently rendered from now until the end of time (or at least, until Microsoft stops supporting that rendering model or breaks it accidentally). We went down this path once before, using the Doctype declaration to differentiate between “quirks” mode and “standards” mode. IE7 is, unfortunately, also quirky in standards mode, so apparently we need a new “super-standards” mode for the next version (and so forth).
From the perspective of the IE team, this solution makes sense. They can effectively freeze HTML rendering at today’s IE7 baseline and proceed with enhanced features in later releases. Maybe I’m looking at this the wrong way, but I never considered HTML content to perfect screenshots that should remain immutable. Well designed HTML is flexible — it can be rendered by a desktop browser, or stripped to it’s barest essentials by a mobile parser. (Note that I’m drawing a clear line between web content and web applications — web apps are by their very nature a snapshot of the present). The IE team should be encouraged to fix their mistakes at the expense of breaking badly developed content, just as users should be encouraged to update their rendering engines as frequently as possible. Notice that the IE team is the only browser developer that seems to have this problem.
As a web designer and developer, apparently I’m supposed to help Microsoft maintain their dominance in the web browser market by tagging my pages for their benefit. But what do I get out of the bargain?
Let’s assume for a moment that IE8 has been released with a spectacular new rendering engine, on par with Firefox or Safari or Opera in terms of “write once, render anywhere”. Let’s also assume I have a pretty good idea of what my target audience’s browser technology will be: 50% “IE8 compatible” (meaning IE8/FF/Safari etc), 30% IE7, and 20% IE6. None of these markets are small enough to ignore or deliver reduced functionality to. I would still need to optimize for three different version of Internet Explorer. IE7 doesn’t go away, and neither does IE6. I can’t just freeze the renderer at the IE7 level — I want to use all those fancy new features in IE8 that have been available in alternate browsers for years now.
So where does this leave me, the web developer? Still coding for multiple releases of IE. In fact, the problem gets worse as Microsoft accelerates it’s release schedule — people simply don’t update quickly enough. IE6 is still estimated to have a 35% market share — over a year after IE7’s release. How do we solve the problem of supporting multiple renderers?
Simple. We deprecate IE6. We no longer support it. And we provide a clear, direct upgrade path that involves little to no effort on the part of the user. Maybe this involves just swapping out the rendering engine, leaving the browser’s UI intact (to minimize the impact on the user’s day-to-day experience interacting with their browser). I’m certain part of the resistance to upgrading to IE7 today is the horrendous overhaul to the UI that occurred between versions.
Apple doesn’t seem to have any problems keeping it’s Safari users (or iTunes users) on the latest release through an effective software update system. Firefox also has a fairly effective system, although it could be improved. But web developers don’t complain about supporting multiple, ancient versions of those browsers because the system, and the users, are proactive about updates.
We need to get over the idea of preserving out-of-date content as a snapshot of the day it was released. We need to stop worrying about breaking 5-year-old browsers and just get on with it.
Update: After further reflection, there is another (possibly better) approach Microsoft could take. They could include the IE6 and IE7 rendering engines in each new update, and provide a user-accessible toggle for enabling it on specific sites. Using the info bar, much in the same way they do when blocking popups or enabling ActiveX downloads, a message could be displayed along the lines of “This page may not be compatible with the Internet Explorer 8 display system. Would you like to switch to Internet Explorer 6 compatibility mode for this site?” IE would remember the setting and use it on subsequent visits. The compatibility message could be triggered by detecting known CSS hacks, or even based on the Last-Modified date of the document.