Version Targeting: Defaulting to the Past to Spite the Future?
The topic of version targeting has been all the rage the last 2 days, following Aaron Gustafson’s article for A List Apart and Eric Meyer’s companion piece. IE8 has not only passed the Acid2 test, but in this release it will be taking a new direction on version control, allowing us developers to, rather than rely on the DOCTYPE declaration to attempt to keep our sites in rendered intact, asign a meta element with the browser versions for which the site was coded and tested against. This meta element would look like this:
<meta http-equiv=”X-UA-Compatible” content=”IE=8″ />
Of course, in theory, if all browsers adopt version targeting, you would be able to enter content=”IE=8, ff=2.1, saf=3.0;” so all browsers would perform as though it was the day you coded it.
The logic Microsoft uses to explain their reasoning for going this route in IE8’s development makes perfect sense:
We realized that “Don’t Break the Web” should really be translated to “Don’t change what developers expect IE to do for current pages that are already deployed.”
The benefit, of course, is that if you code and test in IE6, you state this in the meta element or HTTP header, and the browser “pretends” to be IE6 and renders the site accordingly, behaving as the back version of the rendering engine would have. Great. So your code is locked in time, and no matter how many versions of a browser come after, your site will not break. It’ll look the same forever.
However, if you omit the meta http-equivalent, the browser just acts as the backdated version – so IE 8 will act like 7 and render the page using the IE7 rendering engine instead of defaulting to the current standards mode. Jeremy Keith finds this problematic in that the current standards will not be supported by future versions of IE unless you opt in, and include the meta element:
That’s madness! If I don’t use the
X-UA-Compatibleinstruction, I won’t get the benefit of any future improvements in Internet Explorer. That sounds like blackmail to me. There is an option to activate whatever is the current browser version—which, of course, should be the default behaviour. This is achieved by using the (strongly discouraged)IE=edgevalue in… yup,
http-equiv="X-UA-Compatible". So even if you want to opt out, you have to opt in. That too is madness.
IE8 will have the solution to the woes we developers have felt for a long time by defaulting to the IE7 rendering engine, but at the cost of asserted progress. For future releases, progress is only felt by those who “opt in” for it’s benefits by declaring ie=”edge” in the meta element. And as we all know, the masses fear change and unpredictability. I hate going back and recoding the breakage after a new browser release as much as anyone, but this has the benefit of forced evolution.
Nonetheless, Zeldman has a good point – IE has been under fire time and time again with each new release breaking the old. All the hard work Microsoft developers put in toward creating a standards compliant rendering engine will not be viewed in a positive light by most if everything breaks. Avoiding breakage throughout the evolution of technology is key to keeping the web standards movement in good favor.
It leaves a bad taste in my mouth to think that new browser versions will default to rendering their old bugs. The idealist in me thinks this wreaks of stunted growth and conservativism. I fear stasis like many fear change. But at the same time I understand why at least at this point in time, defaulting to the old rendering engine with all of it’s problems is beneficial for Microsoft as they make the transition to supporting standards. This is a big step for the proprietary giant who holds captive the biggest market share of browser users – any backlash against their support of the movement and we’re liable to see them jump ship. At least they’re on board for now.
At first glance, my greatest fear was that the “opt in/opt out” aspect of version targeting would create laziness, and discourage best practices for web standards. If it ain’t broke, don’t fix it. After a bit more consideration, I don’t think that it is necessarily the eminent fear of breakage that propels the web community to work hard to write clean, compliant code.
The web standards movement is not just about making things “not break” – it’s about increased accesibility, faster load times, stronger sites with newly supported features. And it is about pride in doing things the best way possible. Those of us in the dev field have ample reason to continue to progress and evolve with the technology even if our past projects aren’t broken.
On February 5th, 2008, Jeremy Anderson said:
You raise some good points. It’s a complicated matter and I can see both sides of the argument. I especially relate to Jeffrey Zeldman’s concerns about derailing the web standards movement.
I don’t like the smell of anything proprietary, and Microsoft’s version targeting has that stink about it. But it really isn’t. Making a smooth transition is exactly what they need to do. And, if version targeting works as it should, it becomes a very useful tool for developers to quickly assess compatibility issues. That would be a much preferred alternative to hunting for back version clones.
The one concern I do have, and maybe this is residual distrust in Microsoft, is the fact that they encourage other browser makers to follow suit. This make no sense to me. Let IE provide a compromise to make up for their lack of foresight. Let the others push them forward in developing to standards. Maybe that’s just me.
On March 16th, 2008, Microsoft Sees the Future: Support for Standards by Default » said:
[...] my views expressed in Version Targeting: Defaulting to the Past to Spite the Future? were primarily favorable of the new technique, I expressed my concerns with Microsoft’s [...]