Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Browser detection reconsidered

Leonard Lin on The Folly of Depending on CSS Parsing Bugs:

I would not compensate for CSS rendering bugs by exploiting CSS parsing bugs except as a last resort. Think about it from a standardized test perspective: what strong relation does CSS rendering bugs have with CSS parsing bugs? There’s no reason (nor right!) to assume that all future browsers with the same rendering bugs will have the same parsing bugs (and vice versa). In fact, if you look at the recent past releases (Safari, Opera, IE), even within browser families you’ll see that this is absolutely not true!

He has an interesting point—user agent sniffing, while derided by many, is at least predictable in that you can deliberately target specific versions of specific browsers (as long as you’re careful not to feed a user-agent cloaked Opera something nasty by mistake). CSS hacks may target browsers based purely on their capabilities (which cannot be cloaked by a false user agent string) but require careful maintenance against future version changes—as with Safari which has fixed some CSS parsing errors that were being used to filter Safari specific styles.

I suppose it boils down to the question of which is easier to maintain—a site-wide stylesheet (or two) with hacks in vs a server side (I’ll ignore client side as it’s even uglier) browser detection routine to serve up the right stylesheet. Either way, if you don’t have a full set of browsers and platforms to test on the best you can do is cross your fingers and pray nothing breaks.

Of course, this issue is true of table layouts as well. Who knows, maybe in about 5 years time the browsers will have caught up with the current set of standards (and we’ll all be stressing over how much of CSS3 we can use without the house of cards tumbling back down again).

Posted 24th February 2003 at 12:07 pm

This is Browser detection reconsidered by Simon Willison, posted on 24th February 2003.

View blog reactions

Next: Pingback redux

Previous: Mail models

6 comments

  1. It's my understanding that Safari is still in beta right now. You should never be supporting betas once a final is released.

    sasha - 24th February 2003 13:13 - #

  2. Actually, you should examine your logfiles and determine how many people are using the beta version, and decide whether to support it, just like any other browser or platform. In my case, in that past 12 hours, 106 people have visited with Safari build 60, and 1 with Safari build 51. YMMV.

    Mark - 24th February 2003 16:02 - #

  3. A thought about server-side sniffing. While the conceptually it seems cleaner (well, as clean an alternative considering there is no agreed upon CSS browsercaps system), if you're running a static site with millions of hits (and without a proper caching or proxying system), you may want to reconsider how 'worth' it the load impact would be on making the pages (or the css file) dynamic vs a client side solution. (Of course, CSS filters *are* a client side browser sniffing solution, just a really inefficient and tenuously mapped one.) Something that people often forget when arguing about the merits and cleanliness of Style Sheets is how much CSS2 really sucks. In most layout situations it's less flexible than tables, the columning is ALL A HACK, and by the time you put enough surrounding divs to account for browser box model bugs, you have enough presentation code in your structure to choke a horse. Not to beat said dead horse too much, but it always amuses me to see people replicating table structures with a set of complex nested divs.

    leonard - 24th February 2003 17:59 - #

  4. One thing you must be careful of when using server-side sniffing is caching. If your site gets stored in a public cache then an IE user using the same cache as a Mozilla user may end up being served the Mozilla version of the page and vice versa.

    The HTTP 1.1 "Cache-control: private" header can remedy this, but only if the cache itself supports HTTP 1.1

    Tom - 25th February 2003 11:45 - #

  5. Tom, that particular caching problem is not valid. HTTP/1.1 offers the vary header, so that caches store different variants of the object based on a header, such as user-agent.

    However, this still leaves two fairly major problems: spoofed headers and cache effectiveness.

    Header spoofing is fairly common with, e.g. konqueror, since clueless authors block unknown UAs sometimes.

    The biggest problem is that the effectiveness of caches will drop dramatically. The vary header only allows for exact matches, and so even minor variations between user-agent headers will cause a separate variant to be stored in a cache. Caches will not be able to serve a cached copy of a stylesheet generated by a request from mozilla 1.3b on win2k to a client machine using mozilla 1.3b on winxp, for example. The chances of a cache having the variant you need will drop through the floor, and the persistence of cached copies will also fall, as each variant is less important, according to the cache.

    There are really only three solutions to css bugs:

    1. Ignoring the bugs. Unacceptable to most people.
    2. Server-side sniffing. Causes harm immediately.
    3. Parsing hacks. May cause harm in the future.

    Considering each new version brings risks anyway (e.g. the IE6 guillotine bug caused a lot of sites to fail out of the blue), I'd have to conclude that taking advantage of parsing bugs isn't that risky.

    If you really must go with the server-side approach, at least write your standards-compliant code in one stylesheet, and have all browser-specific workarounds dealt out in another, thus keeping the majority of styles easily cachable.

    Jim - 26th February 2003 08:00 - #

  6. daco

    makos - 11th May 2004 20:08 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2003/02/24/browserDetectionReconsidered

A django site