Browser detection reconsidered
24th February 2003
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).