Conditional Comments in HTML5?

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.

Join the Conversation

  1. A couple of years ago I wrote a server-side script “User Agent CSS” that handled style sheets.I guess if browser developers changed their CSS handling to always recognise their vendor ID, even on well established non-experimental properties, then that would go part of the way. egfoo {
    color: black;
    -ms-color: blue;
    -moz-color: orange;
    -o-color: red;
    -webkit-color: gray;
    }

  2. Originally posted by Andrew Gregory:I guess if browser developers changed their CSS handling to always recognise their vendor ID, even on well established non-experimental properties, then that would go part of the wayThat is a quite neat idea, and would solve many CSS problems, not doing anything for non-CSS of course.There is a problem with this, the vendor prefixes is one of the few cases I can think of with current standards of planned obsolence. Take a CSS3 property which is currently experimental, like ‘border-radius’. Mozilla was an early implementor of this property, preceding the W3C experimental ‘border-radius’, the upshot of which is that ‘-moz-border-radius’ will behave differently from the finalised W3C ‘border-radius’. People who have used the experimental ‘-moz-border-radius’ will expect it to behave similarly in the future. So you will have one group of designers wanting to express -moz-border-radius: /* For old versions of Firefox */;
    border-radius: /* For future versions of Firefox and others*/;Later you will have another group of designers wanting to do border-radius: /* Regular border radius */;
    -moz-border-radius: /* Gecko-specific hacks */:

  3. As long as Opera sticks to the W3C specs, there’s no reason whatsoever for Opera-conditional comments or browser sniffing. Code should be written to W3C spec and then hacked to work in browsers that refuse to stay within the same decade, not the other way around (written to be IE compatible and then hacked for Opera support).The only reason I’d see need for this is Opera not fully supporting a spec in which case a second method would be used in Opera, instead. Are there any parts of a spec that are implemented by IE and that aren’t implemented by Opera?

  4. Originally posted by IceArdor:As long as Opera sticks to the W3C specs, there’s no reason whatsoever for Opera-conditional comments or browser sniffing. Browser sniffing should be kept to a minimum, capability detection is always better when applicable, but browser sniffing is not going to go away, and is implicitly supported by all browser through the HTTP Referer header and the Navigator JS object.And Opera is not bug-free, has never been bug-free, will never be bug-free, and neither will any other browser. Working around broken browser support is the “good” case for browser sniffing. The bad reasons for browser sniffing will always outnumber the good reasons, but even if they browser sniff for the wrong reasons wouldn’t it be better if they did so in a less damaging way?

  5. Part of me says that whoever uses vendor prefixes is asking for trouble anyway – they should expect potentially experimental properties to change.If web devs want a maintenance-free web site, then they shouldn’t be using hacks or sniffing in the first place.

  6. Rob Larsen writes:As someone who uses conditional comments as a standard part of my development process, I’d like to point out that current versions aren’t really the problem. So if Opera supports them going forward, that would be less useful to me than if, for example, Opera were able to go back in a time machine and added support for them in Opera 8.5 (I choose that specifically because of lack of support for opacity in that version of the browser)for a specific example, while I have the power to serve a specific IE8 sheet, I don’t have to very often because they’ve gotten so much better. On the other hand, I will serve an IE6 specific sheet for as long as I have to support it

  7. Originally posted by anonymous:So if Opera supports them going forward, that would be less useful to me than if, for example, Opera were able to go back in a time machine and added support for them in Opera 8.5 (I choose that specifically because of lack of support for opacity in that version of the browser)At the time of coding past versions will be what a web developer cares about, but as times goes by the new browser versions will become a bigger problem. Unlike capability detection browser sniffing isn’t forward compatible, so my claim is that if browser sniffing were to be formalised planned obsolescence is the least we can do for the future generations.Arguably it is formalised already through the User-Agent string and the navigator.appName and navigator.appVersion.

  8. Sander writes:Jonny, Why exactly is “working around broken browser support the “good” case for browser sniffing.”?If Web publishers (be they human or code generators) would just stick to the specs, browser bugs would be much more ‘visible’ to many more users, which would give browser vendors a lot more reason to fix those bugs. Working around browser bugs, through whatever mechanism, just hides the problem — keeps the bugs alive.

  9. It sounds like you’d be a fan of widespread adoption of Microsoft’s new X-UA-Compatible meta tag/HTTP header, since it essentially freezes a page into a specific browser version.

  10. Anonymous writes:Opera is the only modern browser that is mystifyingly pushing my header images down by 2px. It would be great to have a simple way for the page to display correctly in Opera. If every other browser is displaying it correctly, there must be some issue in Opera.

Comment

Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *