Justin Young's blog

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

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.