Where we are

Four years ago I wrote a small piece on conditional comments in IE7, and whether there should be an institutionalised Opera CSS hack, in the style of @opera or @browser opera. While IE's standards support isn't stellar, it is still better than it was four years ago, and the desire to make specific hacks for the shortcomings of IE, Opera, or any other browser hasn't gone away and is unlikely to go away in the next decade either. This entry is triggered by a comment this Friday asking for Opera conditional comments. For all the talk about the ills of browser sniffing, and using capability detection instead, it is not going to go away. In that case wouldn't it be better to make browser sniffing less bad? …

As that piece said, conditional comments may be the best way to allow for browser hacks, less messy than CSS and more clearly delimited than with JavaScript. So shouldn't the other browsers follow IE's lead?

In the case of a minority browser like Opera the benefits to sniffing are less clear-cut than with a market leader like IE. In practice Opera-sniffing script is much more likely to worsen the experience of an Opera user than it is to improve it, thus the long-standing tradition of browser spoofing, disguising as another browser to alleviate the ills of browser sniffing. Why are the browser sniffing scripts so horrible? Wouldn't it be in the page designer's interest to make it work better, not worse, with any browser?

The answer lies in ignorance, few designers actually know all browsers in detail, and are not comfortable with capability detection. Even if they did use capability detection it functions suboptimally when the browser support for the capability is broken. We cannot assume browsers to be bug-free. Even the best of designers would only know the state of current browsers, and code, especially scripts, hang around for a very long time, getting reused, not getting updated.

The troubles we've seen

1. For well over a decade now JavaScript gurus in particular have advocated object detection, but browser sniffing refuses to go away.
2. The sniffs and hacks are based on incidental attributes like browser name or versions, a browser's lack of capability support, or even a browser supporting something the other browsers don't, yet.
3. Browser declaration works better on an HTML level than on styling or scripting, as the HTML controls both of the above, and you can put all your hacks in one file (they could be scattered all over the place in the HTML document though)
4. The hacks quite often are confused, usually used by someone else than the one making the hack.
5. Even when they are clean and well-made, they are hard to maintain, and may end up a mess even if they didn't start out that way.
6. The browser environment changes over time. New versions of browsers fix old bugs and create new ones, unpopular browsers become popular, popular browsers become unpopular, new platforms appear.
7. Part of what makes browser hacks hard to maintain is that they are hard to find, and in particular the implicit assumptions are hard to find.
8. Browser hacks interact with new or unknown functionality in unpredictable ways. The excellent blog Miscoded has several such examples.

Looking for less bad

If browser sniffing will go away this post is meaningless. Unfortunately there is no reason to believe that is going to happen. So we would be looking for something that:

• is as easy to use and understand as current practices
• does what it is intended to do
• doesn't do what it isn't intended to do
• can be maintained
• will perform as intended over time or at unforeseen circumstances

As the good use for browser sniffing is to compensate for browser bugs (or cases where the standards don't allow you to degrade gracefully). Access to an updated repository for browser shortcomings, linking to a list of workarounds, and a mechanism to apply those would probably be ideal.

Leaving the ideal for the moment, less than ideal but still better than bad would be a combination of browser-conditional comments and planned obsolescence.

Browser-conditional comments

Conditional comments is a fairly clean hack pioneered by Internet Explorer. Normally a browser would ignore content in a comment but if the comment is structured a certain way, the browser (i.e. IE) will handle it as processor instruction, allowing IE to run or not run markup that would be hidden/shown to other browsers. This markup could trigger an IE-specific style sheet or script for instance.

We could have alternative syntactical constructs. Something like a "workaround" link type would be cleaner, as this allows us to separate the dirty hacks from the code.

<link rel="workaround" media="(ua: opera)" href="operahacks.js">

Anything inside a "workaround" file would be a browser-specific hack, anything else is functional markup. This also avoids one maintenance problem with conditional comments. You can't at a glance say that the comments hide good code that fails in IE or if they feed ugly hacks to IE that are hidden from other browsers. Anything with a "workaround" link type is a hack by definition.

The trouble with this approach, apart from overloading Media Queries, is that this separation of hack and content isn't very convenient. Even though it makes future maintenance harder you want the hacks scattered about where they are needed.

Another approach is to do all hacks in JavaScript. Then you can be as well-structured as you want, but really hacks should be domain-specific, CSS hacks should be in CSS, JS hacks in JS, markup hacks and fallbacks in the markup and so on. You can sing to the tune of DOM is all you need and proceed to control the entire document from some overriding master script, but for one thing this action at a distance is very confusing to anyone who is to maintain the site.

Planned obsolescence

And, really, hack maintenance becomes much easier as soon as you realise it is practically impossible. Even the most conscientious web developer can't keep track of all the special cases for all browsers over time. You can "outsource" the problem and use externally maintained libraries. They generally do better, but even the ones that actively keep track of browser developments need to be upgraded on site, and most sites that use external libraries use an old version of that library.

A better approach would be to let these hacks have a sell-by date, a planned obsolescence, after which they would have to be revisited. You could date the hack ("last tested August 18 2009, valid until August 17, 2010"), but this is impractical, won't work well, and doesn't take account that some browsers change more quickly, and often more radically, than other browsers.

You could key it to version numbers ("this hack lasts until next major version of this browser"). This is better but presumes that the web developer can predict the future, and any web developer in a hurry, which is just about every web developer would just code "this version of the browser and any future version", leaving us no better than before.

I made another proposal for how to make this work, browser version tokens. It isn't too challenging to predict that after 8.0 comes 9.0, but what if the conditional comment is based on string tokens instead, like "merlin" or "peregrine" or something else that requires you to be aware of the browser version you make bug hacks for?

There are things we could do to reward well-updated pages and ignore the rest. For instance at each major version (e.g. 7.0, 7.5, 8.0, Merlin) we could add a new token and recognize that token and the previous only. If we have a long-standing bug or quirk you could add a workaround based on the 7.0 token. When 7.5 arrives the 7.0 workaround still works but unless you add the 7.5 token it will be obsolete with 8.0. A minor token would limit the the hack to that particular version. This is useful for the cases where a bug appear in one version and is fixed in the next. In CSS syntax that would be:

@workaround token-list {
   /* rules that applies if at least one token in the list is matched */
 }

Standardising less bad

So IE has conditional comments and for instance Opera elects to support them as well. Is there a need to standardise deviations from the standards?

The answer is probably yes. One reason is formal. If some comments have a magical function while most have not, it would be an advantage to be aware of that, even in an informational section on comments. In theory a web author could accidentally trigger conditional comments otherwise.

More practically if a browser like Opera start supporting conditional comments, it would make sense to do it the same way as IE does. But even if the comment syntax in IE were fully documented, and Opera followed it, what if Opera were to add some new condition, how should it be formed?

In particular for any non-dominant browser it would make a lot more sense to use version tokens than version numbers, the IE conditional comments don't support that.

If browsers allowed hacks through the same mechanism and using the same it would be simpler to keep track of them.