The Dangers of Browser Detect

Picking up on the Rafael Lima’s new script to provide browser-detecting CSS selectors, PPK cautions on the dangers of browser detection.
Rafael Lima’s script adds classes to HTML elements based on the results of an old-style (ie. purely navigator.userAgent-based) browser detect. The purpose is to allow web developers to add CSS rules for one browser by using these classes … 37 Signals and Ajaxian enthousiastically covered it; in fact, the script was written as a result of the 37 Signals blog entry. Unfortunately neither 37 Signals nor Ajaxian seem to have considered the problems.
He says there are two problems here. Firstly, browser detection doesn’t always work.
This is the first, and clearest, danger. Browser vendors have been avoiding browser detects since 1994 by changing their navigator.userAgent value to what the browser detects script expect. Does the script expect “MSIE”? Then the user agent string contains “MSIE”, even though the browser is not in fact Internet Explorer.
Browser detection is something of a cat-and-mouse game, with manufacturers always finding new ways to convince scripts they’re IE or someone else and scripters finding cunning ways to reveal their true identity. The other problem is browser versions - what if Opera 10 works different from Opera 9, do you want a separate opera10 selector?
Using a browser detect means that you have to constanly maintain the site that contains it: professionalism requires you to keep an eye on new browsers, check all your sites in them, and update the special rules for or against this or that browser that you’ve added. This quickly leads to a maintenance hell—one of your own making.
The proposed solution is to detect old versions of IE6, and try to come up with a universal solution for the modern browsers, and PPK acknowledges that’s not trivial, as CSS certainly won’t always work the same way. Arguments against browser detection are fair, but sometimes it’s the right approach from a pragmatic perspective. Especially when using third-party libraries, if you find something’s simply not working on a certain browser, what do you do? If you have real-world deadlines, you often don’t have time to dive into the code and work out why it fails to work on Opera 9 and Firefox 1.0, but works fine everywhere else. Instead, you may have to take the pragmatic approach and use slightly different CSS or code, at least as a temporary measure. Having said that, you don’t want to do that too often … as PPK points out, a proliferation of browser-specific handling is definitely going to cause maintenance hassles.

The Dangers of Browser Detect

Picking up on the Rafael Lima's new script to provide browser-detecting CSS selectors, PPK cautions on the dangers of browser detection.

Rafael Lima's script adds classes to HTML elements based on the results of an old-style (ie. purely navigator.userAgent-based) browser detect. The purpose is to allow web developers to add CSS rules for one browser by using these classes ... 37 Signals and Ajaxian enthousiastically covered it; in fact, the script was written as a result of the 37 Signals blog entry. Unfortunately neither 37 Signals nor Ajaxian seem to have considered the problems.

He says there are two problems here. Firstly, browser detection doesn't always work.

This is the first, and clearest, danger. Browser vendors have been avoiding browser detects since 1994 by changing their navigator.userAgent value to what the browser detects script expect. Does the script expect "MSIE"? Then the user agent string contains "MSIE", even though the browser is not in fact Internet Explorer.

Browser detection is something of a cat-and-mouse game, with manufacturers always finding new ways to convince scripts they're IE or someone else and scripters finding cunning ways to reveal their true identity.

The other problem is browser versions - what if Opera 10 works different from Opera 9, do you want a separate opera10 selector?

Using a browser detect means that you have to constanly maintain the site that contains it: professionalism requires you to keep an eye on new browsers, check all your sites in them, and update the special rules for or against this or that browser that you've added. This quickly leads to a maintenance hell—one of your own making.

The proposed solution is to detect old versions of IE6, and try to come up with a universal solution for the modern browsers, and PPK acknowledges that's not trivial, as CSS certainly won't always work the same way.

Arguments against browser detection are fair, but sometimes it's the right approach from a pragmatic perspective. Especially when using third-party libraries, if you find something's simply not working on a certain browser, what do you do? If you have real-world deadlines, you often don't have time to dive into the code and work out why it fails to work on Opera 9 and Firefox 1.0, but works fine everywhere else. Instead, you may have to take the pragmatic approach and use slightly different CSS or code, at least as a temporary measure. Having said that, you don't want to do that too often ... as PPK points out, a proliferation of browser-specific handling is definitely going to cause maintenance hassles.


August 4th, 2006

Tagged View

Tags Similar

Posts Fresh +

Categories View