Fear and Loathing in Standardsville: The IE8 Opt-in Debate

As covered last week on SitePoint by Matt Magain, Microsoft has announced that IE8 will introduce a new “browser version targeting” system that will see the browser default to rendering standards-compliant pages the same as in IE7, and will require developers to explicitly opt in to IE8’s new, Acid2-compliant rendering engine if they want it.

For web developers that have pinned their hopes for a better world on web standards, the change Microsoft is trying to make is a scary thing.

The fundamental new idea that the ability to “lock” pages to a particular browser release would be a nice thing to have takes a little getting used to, but it’s gradually gaining acceptance. After all, browser releases come along much more often than new web standards, which makes standards-based rendering modes like the DOCTYPE switches in current browsers insufficient.

Seeing your favourite web sites suddenly go wonky when you install a new browser version may be acceptable to developers like you and me, but it will never make sense to end users, who naturally expect better of the Web. Browser version targeting lets us cleanly sidestep such unpleasantness, and enables browser developers to spend more time working on new features and less time weighing the pros and cons of fixing bugs that many sites have come to depend on being present. I recommend reading Eric Myer’s From Switches to Targets if you’re still not convinced.

“Now Life Has Killed the Dream I Dreamed”

But even if we accept browser version targeting in principle, there’s the small matter of the billions (trillions?) of web pages out there, none of which currently specify the browser versions for which they were written. Microsoft would see these pages rendered as IE7 currently renders them for the rest of time.

Some see this as letting the lazy developers of the world—who build sites for the current version of IE and nothing else—get away with writing shoddy, non-compliant code. Others see it as forcing developers to put an ugly “stamp of Microsoft” on all their pages just to get support for standards that IE should have supported for years.

Still others are simply unwilling to give up the notion that web pages are written to standards, and that it’s a browser’s solemn duty to render those pages according to those standards, or as closely as they are able, unless instructed otherwise.

Jeremy Keith is one of this last group. In Broken, he calls for developers to rally against Microsoft in an effort to convince them that the default behaviour in the absence of version targeting information should be to provide the most standards compliant rendering possible.

One of the staunchest advocates of progressive enhancement—enhancing sites using standards that are not yet supported by all browsers so that they will work better in future browsers—Keith sees in Microsoft’s default proposal the death of this promise of a brighter future for the sites we are creating today.

Shockingly to some, Web Standards Project co-founder Jeffrey Zeldman disagrees. In his piece In defense of version targeting, Zeldman comes out and tells the ugly truth: that forcing practitioners of progressive enhancement—a tiny and elite minority in the developer community—to add <meta> tags to their old sites to benefit from new IE features is a small price to pay in order to keep Microsoft on the road to better web standards support.

“It’s The End Of The World As We Know It
(And I Feel Fine)”

Taking Microsoft’s proposal at face value, you might think it was a sad day for standards-minded developers, who for years have imagined a future in which it would be enough to write sites to web standards for them to be displayed as intended in all browsers.

Call me crazy, but I believe there’s still hope, and this can be seen in some of the responses we’re seeing from other browser vendors. In <META HTTP-EQUIV=”X-BALL-CHAIN”> and Slipping The Ball And Chain, Mozilla developer Robert O’Callahan discusses the challenges of actually implementing Microsoft’s version targeting proposal in the long run. He doesn’t expect any of the other major browsers to support version targeting for several reasons, including:

1. All the other major browsers’ standards support is now so good that, in recent history at least, bug fixes in new browser versions haven’t caused significant breakage to existing web sites.
2. Shipping and maintaining an ever-increasing number of legacy rendering engines with each new browser release while ensuring security and interoperability is impractical, if not downright impossible.

The thing is, if this logic can be applied to browsers like Firefox, Safari, and Opera today, it might well be applied to Internet Explorer in a few years’ time. I asked Chris Wilson about this when I interviewed him at Web Directions South late last year:

SP: “Now, with this developer opt-in model that Internet Explorer […] will eventually adopt, are browsers over time going to have, you know, five, six, seven, ten, eighteen different rendering modes […], or will this tendency of the differences to tend towards zero over time mean that one day this can go away?”

Chris Wilson: “I think that my personal hope, certainly, is that one day this gets to go away, that the differences between browser versions are not what we call internally ‘breaking changes.’ […]”

Chris went on to say that he feared there would always be room for interpretation in even the best standard specifications, which would later require browsers to make changes that could break existing pages, but that the work being done on standards today is definitely much better than it has been previously.

That, in combination with the mounting maintenance burden of preserving security, interoperability, and backwards compatibility with multiple rendering modes might give Microsoft reason to wonder whether version targeting is still necessary when IE10 rolls around.

IE8: Means to an End?

To sum up my thoughts this issue, I believe Microsoft’s move to add browser version targeting to IE8 will be difficult for standards-minded developers to accept, but is ultimately a solid solution for the real problems that are currently holding back the evolution of the Web today. If only for tackling the problems that were keeping it from fully embracing web standards, Microsoft should be commended. It could have simply put Internet Explorer on the back burner for another six years!

The decision to make HTML4/XHTML1 pages target the IE7 rendering mode by default, while understandably controversial and certainly worthy of further discussion, I believe strikes the right balance between current real-world needs and the vision of a standards-compliant future.

The silver lining for the standardistas here is that the other major vendors see little use in supporting version targeting in their browsers—certainly not enough to justify the huge development burdens that would be involved. This could be a sign of things to come for Internet Explorer.

Version targeting may just prove to be the key to getting Internet Explorer to stop dragging its heels on the road to that web standards utopia we’ve always dreamed of. And once we get there, Microsoft may well find itself in a position to rejoin the other browsers in supporting the latest standards by default, instead of by request.