As I read through Aaron Gustafson’s Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, my immediate gut reaction was deeply negative. The version-targeting mechanism Aaron described was just wrong, completely backwards, the exact opposite of what we ought to be doing. Every one of my instincts, honed over a decade-plus of web development, was in opposition.

Why did I react that way? Partly because version targeting looked like the revenge of browser sniffing. True, before browsers supported standards correctly, sniffing was often a necessary way of coping with their incompatibilities, but it never really worked in the long run. No sooner did you finish uploading your script than a new version of an old browser came along to break it. The fragile, self-defeating nature of browser sniffing was one of the forces behind the rebellion that eventually brought standards to our browsers. And here it was, I thought, being legitimized and enshrined in the code base of a web browser.

Primarily, though, I was bothered by version targeting because it runs contrary to the principle of forward-compatible development. This has been the best practice of our industry for years now, a way-of-being learned the hard way in the browser wars. We develop with an eye to the future, using features that are widely and stably implemented and only adding “cutting-edge” features when they don’t impair use of the site—this last practice known as progressive enhancement. One example of this approach is the techniques described in “Going To Print”, which add URLs in printed pages for advanced browsers but don’t prevent or break printing in less capable browsers.

With version targeting, the incentive to plan ahead, to be forward-looking, is almost entirely destroyed. Instead, the browser makes a promise to always be backwards compatible. In effect, version targeting is like Time Machine for web browsers. The idea is that when IE10 loads up my IE7 page, it rewinds itself to act like IE7 did, all those years ago—no matter what changed in the meantime.

Thus, as a developer, there’s no need to look beyond the current state of browsers. I can just assume that browsers will always support what I’ve done even if it’s the worst kind of short-sighted, browser-specific, who-needs-standards-anyway type of development possible. And as for the expected direction of browser support for CSS or JavaScript or HTML5 or whatever…who cares?

Reality check

Well, who does care? The readers of A List Apart, surely, and there are a great many of us. But as survey after analysis shows, the vast majority of web content is produced without much regard for standards-based, forward-compatible principles.

Yes, we have made great strides; yes, the work of educating developers has borne some fruit. Still, we need to be honest about this. We’re not reaching everyone, and probably never will. Some sites will be developed according to what the browser-of-the-moment does, no matter how incorrect that might be in comparison to a specification or even other browsers’ behaviors.

This creates a dilemma for browser vendors when faced with bugs in their implementations: fix it or preserve it? The classic example of this was the original implementation of height and width in Internet Explorer, which was wrong per the CSS specifications. The IE team at the time became aware of this fairly soon after they shipped it in IE3…and yet the problem wasn’t fixed until IE6, a delay that slowed the adoption of CSS and gave rise to a whole family of JavaScript sniffers and CSS hacks.

DOCTYPE switching came to the rescue there, of course, allowing IE6 to preserve its old (wrong) behavior in “quirks mode” and do the right thing in “standards mode”—a mechanism introduced in IE5 for the Macintosh and quickly adopted by other browsers.

Let’s consider that for a moment. With the DOCTYPE switch, web browsers effectively recognized two version states: old and current. There was the way things were done in Ye Olden Days, before DOCTYPE switching, and the latest and greatest.

Speeding advances

So we already have an example of version targeting in the DOCTYPE switch. Once I came to that realization, my instincts were thrown into confusion. After all, I was a big proponent of DOCTYPE switching, and still rely on it to this day. Did I hate this whole idea, or not?

Like DOCTYPE switching did in 2000, version targeting negates the vendor argument that existing behaviors can’t be changed for fear of breaking web sites. If IE8 botches its implementation of some CSS property or DOM method, the mistake can be fixed in IE9 without breaking sites developed in the IE8 era.

This actually makes browser vendors more susceptible to pressure to fix their bugs, and less fearful of doing so. That’s huge, as fundamentally game changing as was DOCTYPE switching, but on an ongoing basis. Just imagine how much sooner “height” and “width” could have been fixed in IE, had this mechanism been in place from the beginning.

Furthermore, if this all works as advertised, it’s eventually going to make web development a lot less reliant on virtual machines. If you need to support the current and previous versions of a browser, you just change your X-UA-Compatible value to the older version and see how things are—no copy of VirtualPC required. That won’t happen right away, but it’s a reasonable eventual outcome.

The new sniff test

We’re over browser sniffing, though, aren’t we? Didn’t somebody call it “fragile” and “self-defeating”? (Ahem.)

Well, yes, but there are crucial differences between “browser sniffing” as we know it and the proposed version targeting. For one thing, “browser sniffing” at present means “writing code to check what browser is being used and make adjustments to the markup/CSS/JS/server response/whatever accordingly.” Version targeting reverses that completely, making it “the browser checking the page to see when it was developed and making adjustments to its behavior accordingly.” In other words, version targeting frees web developers from sniffing and places the onus on browser developers instead.

That’s not a change to be lightly dismissed. Browser implementors, for all they frustrate us with (often justified) pleas of limited resources, still command far more resources and expertise in regression testing than any of us can muster. Furthermore, browser developers have a far more vested interest in making sure the version targeting works as promised and doesn’t break old sites than site authors do in updating their old sites to work in new browsers.

The benefits of hindsight

The second major difference between browser sniffing and version targeting is that browser sniffing looks forward while version targeting looks back. Looking forward is one big reason browser sniffing is fragile: it’s hard to predict the future. To pick one example, Safari’s inclusion of “like Gecko” in its user-agent identifier broke a fair number of sniffer scripts—even those that were comparatively well done. The authors of those scripts had simply failed to predict that a non-Gecko browser from Apple would include the word “Gecko” in its user-agent identifier.

Now we have the prospect that browser sniffing will be done by the browsers, and will look back. This is inherently far more stable: the past is always a lot easier to predict than the future.

Besides which, we’ve written enough scripts and hacks to make our pages adjust to browsers. Isn’t it about time browsers started adjusting to our pages?

To sum up

We know forward-compatible development works. More to the point, though, it’s all we’ve had. Since the inception of the web, with the sole exception of DOCTYPE switching, browsers have been a “what I do is what you get” proposition. Developers have been forced to conform to past browsers’ behaviors while making educated guesses about what future browsers would do.

Forward-compatible development and its cousin, progressive enhancement, were necessary and proper because they were the only hope we had of sites continuing to work into the future. The mantra of forward compatibility was necessitated by the world in which we worked.

In a world where browsers had done version targeting from the outset, there would have been another option. Who knows what might have happened? Perhaps we’d find the very idea of forward-compatible development hopelessly fragile, even laughable.

We say forward-compatible development is the mark of a professional because that’s what the profession demands. With the advent of version targeting, that need may simply evaporate, rendered not wrong but moot. And though my deeply-ingrained instincts still fight that conclusion, I have to do my best to look at this possible future and ask myself if it looks better or worse than what we’ve known.

It looks better.

So in the end, and much to my surprise, it turned out that I don’t hate the idea after all. Version targeting allows browsers to much more easily develop new features and fix bugs and shortcomings in existing features, which has the potential to speed up the evolution of web design and development. That alone is reason enough to give it a chance.

Yes, but…

Of course, I still have concerns.

The biggest concern is fidelity. Will the backwards-compatible code for IE8 always act exactly like IE8 did, or will there be subtle changes that still break old sites? Might there even be, dare we mention it, new bugs that affect the backwards compatibility of future browsers? After all, the door swings both ways: vendors might get lax about their backward-looking code just as developers might get lax about their forward-looking code. Talk about irony.

A small concern is the effect of version-targeting code on the size of browser applications themselves. Could this be a step toward browsers becoming bloatware? Someone will chime in with “Who cares? Hard drives are huge now!” but I remain solidly unconvinced by “resources are cheap” arguments. No matter how cheap they are, people still keep filling them up. I sincerely hope the browser of the future won’t require a gigabyte or two of storage space, chained to every previous version of itself like Jacob Marley to his past misdeeds.

Terminology

I’m definitely not a fan of the “edge” keyword. The reason for its existence seems to be so that nobody has to hack their way around the targeting mechanism with “IE=1024” or some other large number. The problem is that providing a keyword equivalent for that creates an aura of official blessing that I don’t think Microsoft wants to give. It’s in their interest to have everyone use this mechanism, and the keyword acts as a wink and a nod to people who want to avoid it. I’m all for people hacking around the targeting mechanism if they want—I may well do it myself—but that should be done with a hack, not an official keyword.

DOCTYPE as version targeting

I wish I could be happy about the way pages are handled in the absence of any version-targeting information. If a page doesn’t have any version-targting information, then the DOCTYPE will be used as a proxy for version targeting. For example, all the HTML4 and XHTML1 DOCTYPEs will be targeted to IE7 by default. In the future, HTML5 DOCTYPEs might by default be targeted to IE9 or IE10, depending on how things shake out.

Of course, a developer can avoid all that by providing an explicit browser version: an HTML2 document can be targeted to IE9; an HTML6 document can be targeted to IE7. But in the absence of explicit version-targeting information, the DOCTYPE will be used as a stand-in and map to a specific version. From Microsoft’s point of view, this is necessary: without this, untargeted pages could be broken by new versions of IE. I get that. But it means that in order to have pages handled they way they’ve always been, essentially moving forward with browsers, you have to hack around the targeting mechanism with a really large version number—or the edge keyword, if it doesn’t get dropped.

The biggest challenge, it seems, will be to make sure that version targeting is done in such a way that it will work into the future and not break down over time like DOCTYPE switching did. In other words, we need to make sure it’s forward-compatible.

I guess those instincts came in handy after all.