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.
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
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
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
switching, and the latest and greatest.
So we already have an example of version targeting
DOCTYPE switch. Once I came to that
realization, my instincts were thrown into confusion.
After all, I was a big proponent of
switching, and still rely on it to this day. Did I hate
this whole idea, or not?
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
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
DOCTYPE switching, but on an ongoing
basis. Just imagine how much sooner “
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
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
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.
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.
I’m definitely not a fan of the “
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
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,
DOCTYPE will be used as a proxy
for version targeting. For example, all the
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
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
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
DOCTYPE switching did. In other
words, we need to make sure it’s forward-compatible.
I guess those instincts came in handy after all.