There have been many, many, articles and discussions that eschew browser detection, yet it continues.

Despite all of this information, browser detection can be seen in most of the popular JavaScript libraries including Prototype, YUI, Dojo, jQuery, and is present in applications such as the newly refactored GMail:

For a better Gmail experience, use a fully supported browser.

Browser detection is bad for many reasons:

1. Browsers change.
2. The User Agent string does not represent the browser reliably.
3. Even if it did, the browser doesn't represent feature support (See #1).

Browser detection is unrelated to the problem it is trying to solve.

Browser detection makes code hard to maintain. It accomplishes this by requiring that the next version of [insert_browser_name] will also have to be tested and special-cased in the code.

Alternative: Feature Detection

For example, does the browser support opacity? This can easily be determined:

if("opacity"in el.style) { }

Support of opacity has nothing to do with whether that browser actually is an IE version, nor is the reverse true: IE does not imply support (or lack of support) for opacity.

Detection for feature support does not suffer from maintenance problems when Internet Explorer decides to support opacity. Capability detection takes feature detection one step further.

Once the code has been properly designed and tested, it should not be a problem to maintain.

I have learned this the hard way and have tried to remove browser detection from my drag code, though evidence of my mistake is still present. I had to refactor my drag code in specific cases where it checked for browsers identifying with an Opera User Agent string (removed checks to ua.opera). My code still contains one conditional branch that needs to be refactored, As is, the script works in all of the modern browsers (this is subject to change).

With browser detection, the internal quality of the code suffers, even if the code works. This is because it introduces a dynamic aspect that must be maintained as the browsers change. Implementation Matters.

ToBoolean

Be careful when testing for values of properties. Some values may evaluate to false in a boolean context.

// Error-prone, scrollTop may be 0, which would evaluate to false
if (document.body.scrollTop) {
    // statements that work with scrollTop property
}

The new GMail

New code should definitely not rely on browser detection

GMail, which was recently redesigned, still uses browser detection and also punishes users with the performance hit of a misused HTTP redirect (HTTP/1.x 302 Moved Temporarily), or, if GMail finds your browser's User Agent header unsuitable, it two HTTP redirects.

In fact, when developing for mobile phones, I have found Chris Penderick's UserAgent switcher useful. Unfortunately, this confuses GMail, messing up the rendering and even encoding of messages.

GMail seems to be predominantly developed with a windows-centric mentality. This is evidenced by the lack of support for Command + S to save in Mac, and the Safari and Opera bugs witnessed in earlier versions of GMail.

Google Groups

Google Groups also relies on faulty browser detection to block certain features.

Google Groups Browser Error, in a Draggable, Floating DHTML Pane

This feature is not supported in your browser. Download a copy of Firefox or Internet Explorer to upload your picture.

I find it ironic that my browser can be assumed to support the draggable, floating pane, and not suitable for uploading a picture. The floating pane is draggable from anywhere inside it, so it is impossible for a user who gets the error to select the error message text.

Acknowledgements

Google deserves proper recognition for providing a clear example of why browser detection is a bad practice.

Contrasting Example

For proof that an effective Ajax application can be developed without browser detection, have a look at Google Reader.

Browser Detection is mostly a bad idea.

In the meantime, I'm looking for a decent mail application that runs in the browser. Both Yahoo mail and GMail fall short of my expectations.

In Opera 9.2 getComputedStyle(el, '').getPropertyValue returns the margin value for top/left values when the top/left values aren't set. In Safari the returned values are 'auto' in this case.

Example

testcase showing bug in Opera and Safari

Workaround

The way to avoid the problem is to explicitly add top and left values to the stylesheet:

#Test {
  top: 0;
  left: 0;
}

Then getComputedStyle will return correct values for top/left (0px) in Opera 9 and Safari.

pixelXXX

A convenient alternative would be a currentStyle.pixelLeft. Only Opera and IE support currentStyle and only Opera supports currentStyle.pixelLeft. (IE supports style.pixelLeft; this only reads from the style attribute)

Mozilla does not support pixelXXX properties at all, though Opera, IE, and Safari 3 all do.

Firefox is #1. Trumps MSIE.

	Browsers	Grabber	Hits	Percent
	Firefox	No	79857	34.6 %
	MS Internet Explorer	No	74977	32.5 %
	Unknown	?	63328	27.4 %
	Safari	No	4006	1.7 %
	Opera	No	3607	1.5 %
	Mozilla	No	3108	1.3 %
	NetNewsWire	No	517	0.2 %
	Konqueror	No	422	0.1 %
	Camino	No	252	0.1 %
	Netscape	No	91	0 %
	Others		123	0 %

Opera's settings allow surfers to easily spoof the User-Agent header. Opera is probably slightly underrepresented.