Breaking Web Standards Forever
I've been following the debate over Version Targeting on A List Apart for a little while now, and felt like I should throw in my two cents. I would suggest reading these Pro and Con articles on the subject to give you a decent idea of the arguments for and against.
Here's a brief description of what Version Targeting is - if you already know, go ahead and click 'Read More' and skip over this. There was a time when Internet Explorer 6 controlled more than 95% of the browser market – and of course everyone built their websites around IE6 - HTML/CSS standards were little more than ideals, if a developer had even heard of them at all. Then, in late 2006, Microsoft rolled out Internet Explorer 7, their first browser update in six years. This new browser still has quirks and errors, but it is far, far more standard-compliant than IE6 was. What happened next was referred to as the breaking of the web – suddenly all those websites built for IE6 didn't work, and many developers had no idea why. If you switched from IE6 to 7 shortly after it was released, you probably came across some websites that looked broken, didn't work quite right, or just flat out failed to render.
To Microsoft's credit, Version Targeting is no doubt the best option for them in rolling out their next browser – it will guarantee an almost unnoticeable transition from 7 to 8 for just about everyone. Even more to their credit, they've managed to win over a large number of website developers, including such influential names as Jeffrey Zeldman, co-founder of WaSP. Despite this, I have come to the conclusion that Version Targeting could very well bring web development back to the days before standards, as well as encouraging low quality, insecure, and confusing design and code.
Stagnation of Standards
Let's disregard, for a moment, all the people who build websites but don't actually know how – what Microsoft is doing is basically destroying the concept of depreciation of old standards. If VT were implemented five years ago, there would still be countless websites using <font/> and the like to format their sites – not because they don't know about or don't like the new standards, but simply because it's far easier to thrown in a little snippet of code saying 'Render in IE5' than to rebuild a massive site from the ground up. Now the
<font/> tag is a poor example, since CSS makes most all styling much easier, but take the
<center/> tag, for instance – that's a lot easier and more intuitive than CSS's tools for centering text or block level objects – and VT guarantees that crap like
<center/> will work just as well in IE47 as it does in IE7.
Now, that may not sound all that likely – what kind of decent web developer's going to purposefully stay behind the times? Not many. But there will be large scale sites which never see a need to update and so will just leave it sitting; functional but technically out of date. Furthermore, remember how I said disregard all those other people a moment ago? Yeah, they're all going to be doing this – since Microsoft has promised to let IE7 be the default for theoretically ever, the large numbers of uneducated website builders will continue to develop for IE7, no matter how the real standards change, grow, and improve.
Countless Different Codes
A complementary problem we'll run into as VT ages is the growing number of different versions people will have to work with. Say I flag a major website I build as IE8, and IE9 has large enough changes that I (or my client) doesn't think it's worth taking the time to upgrade the code. Now, five, ten years later, I'm not working for this site anymore, and they need to hire someone who knows how to properly develop IE8 code, even though current standards are in line with say IE12. So now web developers will need to start keeping up-to-date with all the different versions, they'll put on their resumes 'Knowledgeable in IE7-10 and IE13'. And what about when we get to IE47, which seems to be the magic example version? If you can't keep track of at least half of those forty possible versions, you're just going to be obsolete as a web developer! This isn't an improvement of web standards, or the path towards one standard system; VT is in fact sprinting in the opposite direction!
Browsers Will Grow To Gargantuan Size
Encouraging Poor Coders
One thing that I take serious issue with in both the pro and con articles I link to at the top of this article is the authors' desire to appease website coders who don't know what they're doing. “To satisfy the unenlightened... These coders and sites need the protection of a [VT] switch." This is so totally wrong, I was amazed when I read those words coming from a founder of WaSP. Poor coders deserve absolutely zero tolerance. Any move to yield ground to people who don't know what they're doing is an attempt to wear down the internet.
The ideal for developing browsers five years ago was to make a product which would successfully render an HTML file no matter how poorly it was put together. There was a logical reason for this – people would be less inclined to use a browser that output sites 'badly', even if the real reason is because they're badly built. So if you put tags out of order:
<i>some text <b> and more</i></b> or in places the doctype shouldn't allow, they'd render it as close to correctly as they could. And the ultimate result of browsers that are willing to properly render bad code is, of course, bad coders. Properly implementing standardization has been slowly but surely fixing that problem, but now we're going right back to that point with VT, allowing these clueless coders to continue building sites that work well into the future.
Learning standardized HTML/CSS is not hard; it may have a few quirks that aren't quite as logical as some of the invalid code, but by and large they're just different, and if browsers would only allow valid code, everyone would just learn how to build sites properly from the get-go and we wouldn't be seeing the problems we are today.
Making web development more accessible to people who don't know what they're doing is arguably the greatest threat to web security today. Sure, there are obscure little hacks that can break through even the best built website running on properly built browsers, but they're much harder to find, and harder to exploit. What hacker in their right mind is going to bother trying to exploit a well built site when they can hijack a weak site much more easily? And think just how much harder it will become to keep your site secure when there are half a dozen different versions of IE that could all be considered valid.
What Needs To Happen
Sadly it's too late for IE8, the wheels are already in motion, and there's no way Microsoft is going to change direction now. But when the proponents of VT claim that without it the 'internet would break,' they forget three important factors: Firefox, Opera, and Safari. All of these browsers are standardized (enough) that developing for one will almost guarantee successful rendering in all the others – and look, no need to target different versions here! Thus the key and primary course of action is to promote these 'alternative' browsers. The more we can whittle away at IE's market share, the more likely VT will just become something people need to do to make their site work in IE. If by the time Firefox 6 comes out it holds, say, one third of the market, people will be forced to start developing for these valid browsers, and might just learn that what they've been doing has been wrong, and change their ways.
The next key thing is to make sure that the valid browsers do not implement version targeting. If that happens, the Internet Explorer team will have won, and it will take many years to resolve all the chaos and confusion VT will turn standardized coding into.
What Could Happen
Jeremy Keith writes, "Version targeting is not a bad idea." He claims that the solution is to make it optional, instead of mandatory. In other words, if the browser does not find a command saying otherwise, it should render in the most current engine. Though this might be ideal from a standards point of view, it's simply not functional. Anyone who follows the standards would be happy that their site renders properly, and anyone who doesn't would not understand why it suddenly broke.
So if defaulting to IE7 and letting developers opt to something else doesn't work, and defaulting to the current browser and letting developers opt to an earlier version doesn't work, and it doesn't seem likely that IE is going to drop version targeting any time soon, what's the best solution? Here's my solution, which I think will work for standard purists, web developers, people who don't know what they're doing, and of course the general public. Each browser version should default to render in the version one previous, and then developers can specify that they want their site to render with the current version instead.
This strategy avoids all the disadvantages I discussed previously, while keeping the disadvantages of a VT-free system to a minimum. Since each version of the browser will only have two options, and with each new browser the old (default) version will retire, meaning that while standards will take a few additional years to be fully implemented across the board, there will still be continuous growth and improvement as each later edition of a browser is released.
There will only be two or three different standards that a decent web developer will ever need to know (which if you think about it is similar to now – standard, IE7, and IE6) – the current version, the default version, and maybe the default version of the last major release of the browser, for those who chose not to upgrade immediately. This is a vast improvement over having to learn and understand a new standard for each future release of a browser. Standards are designed to grow while the old standards fade away, which is exactly what this plan would do.
Browsers would not need to grow in size. IE already has two rendering versions, Valid and Quirks mode, so this would just be the logical continuation as Quirks mode becomes 'Previous Version Mode'.
And what happens to those who don't know or follow the standards? Previous Version Mode gives them a soft but forceful way to encourage them to follow the standards. They'll have a few years between each browser release to ensure that their code will still work in the next browser. When IE8 releases, they'll be able to upgrade their site at their leisure to IE8, at which time it will still work perfectly with IE9, and so on. Admittedly, this would still leave those who just don't understand what they're doing at all stranded when IE9 rolls out, but like I said earlier, it is wrong to encourage them to continue their flawed practices. Whereas IE7 broke many of their sites overnight, Previous Version Mode would give them the time they need to learn how to fix their site without pressure.
The Red Pill
Version Targeting is a temporary and personal solution to browser differences. It's easy to implement, but will slowly but surely eat away at everything standardists have fought for over the last decade. The alternative, a growing, changing and evolving library of standard and encouraged code, is more painful in the short term, especially to the uninitiated, but as we've seen over the past few years, it makes the greater task of building a uniform and logical system possible, and doable.
Well thought out post you have here. I'd heard most of the pro-arguments already and remain unconvinced that it's at all right to do version targeting; I do have to say though that I hadn't heard of security being used as a pro reason for it, and it's almost hard to believe that anyone could try to justify security as a reason to do version targeting. Seems a little insanity has taken over since there is no way to increase security by widening the attackable surface of a product.<br />
I do like your suggestion to just have the two rendering modes and default to the older one which goes away each update to the browser. I do believe it's the best idea I've heard put forth in all the discussion and arguments that have taken place over this topic. Hopefully someone at MS gets half a clue and implements it in IE9.