Peter Quinsey has a website

Field Notes - January 22

Reassigning Responsibility

By now, you will have read Aaron Gustafson's Beyond DOCTYPE to get worked up, and then Eric Meyer's From Switches To Targets to calm yourself down. Perhaps you even poured yourself an extra cup of coffee while you sat and let your brain churn over this crazy thought which is speeding towards reality. I did, anyway, and here's what it came up with.

Browser-based version targeting will be a useful tool, but it will not be for everyone. When it comes to browsers and standards, there are three general types of designers: those who design for standards compliance, those who design for browser compliance, and those who design for both.

Some design for browsers, some design for standards, most design for both.

Those who design for standards compliance build their sites according to W3C technical recommendations, and often the latest versions thereof. If any feature is supported in any browser, they'll use it. If that feature isn't supported in your browser, their site will degrade gracefully for you, and still remain fully accessible. Their sites generally aren't concerned with cross-browser pixel precision, especially for mythical future browsers with backwards-incompatible bug fixes. They don't need version targeting.

Those who design for browsers have a set list of browsers, often a small one, and jiggle their tags and styles until everything looks just right, often at the expense of web standards. It's possible that their instructions were “make it look good in IE6, that's all that's important”. It's impossible to say whether or not they would use version targeting, although it's tempting to say that if they were smart enough to use it, they'd be using web standards as well. For our needs today, they are irrelevant.

The relevant group is the rest of us, those who design for both standards and browser compliance. We use doctypes and validate our XHTML and CSS, yet we still use conditional comments and CSS hacks to address browser bugs. We run accessibility tests, yet we still use empty XHTML elements to control visual spacing. We have an impossible mission: to make our websites forward-compatible and attractively consistent across all modern browsers, including those which have not yet been created. We have clients who demand as much, and they are real people with real budgets whose livelihood depends on it.

Version targeting simplifies that mission for us. It allows us to state that here, on this date, this site worked in these browsers, and worked well. It allows us to work to the best of our ability and not have that work degrade over time. It takes the responbility of forward-compatible maintenance, and reassigns it to the browser makers, who can actually do something effective that doesn't involve hacked aural CSS syntax.

It allows us, for the first time ever, to declare a site finished.

That said, there are aspects of the proposed implementation which are worrisome, in particular the default behaviour, which Jeremy Keith explains in detail. Version targeting needs to be an optional tool, not a mandatory layer to be written into the permanent future of the web. While tying sites to browsers may help the future arrive a little more quickly, the whole point of that future is to free the site from the browser. When IE10, Firefox 5, Safari 4, and Opera 27 all render sites the same, I don't want an extra HTTP header stating the obvious.

Maybe I'm a little optimistic on that count. But when Microsoft comes up with ways to bring web design into the year 2008, it's tough not to be.