When Browser Detection Isn’t a Bad Thing
One of the pillars of the Web Standards movement–reinforced in Zeldman‘s seminal Designing With Web Standards
Old School: Browser Detection
Traditionally, browser detection was used for code forking in order to support two or more highly incompatible browsers. So if Netscape 3 was detected, one block of JavaScript was executed, and if Internet Explorer 3 was detected then an entirely different block of JavaScript was executed. The trouble with this model was, and still is, that it’s expensive to maintain. To say nothing of it being error prone. It also doesn’t do a great job of anticipating future versions of browsers.
An example of this was on the Microsoft Games site. Visiting it with the new beta of Internet Explorer 7 would cause the site to hide its content and display a message asking that the visitor please upgrade to Internet Explorer 6 or newer.
New School: Feature Detection
The alternative to browser detection is feature detection. Feature detection means checking to see if a feature exists prior to implementing it. So for example, if a developer wanted to use getElementById, he’d first check for it like so:
if (document.getElementById) {
var foo = document.getElementById("foo");
}The New Browser Detection
This works great, unless a browser says it can do something and actually can’t. In other words, if browser X implemented getElementById but it was buggy, it would still pass the test but fail in the code. This is where browser detection comes back into play, but not like in the bad old days. No, this time around browser detection would be used to target and fix–or deny–a feature in a browser known to have issues with it.
An example of this sort of thing would be Safari 2.x’s trouble with cellIndex. Normally, checking a table cell’s cellIndex property would return a number representing its position within a row. Not so with Safari 2.x, in its case cellIndex always returns 0. So testing for cellIndex doesn’t help since it is there, it just doesn’t work.
There are also edge cases that simply can’t be tested for. For example, background images inside an animated iframe in Internet Explorer 6 will flicker throughout the animation sequence. There is no way to do feature detection in this case, however the issue is known. So, the solution may well be to simply test for the browser and if Internet Explorer 6 is detected, to simply deny it the animation and just snap to the last frame.
Summary
So, the new browser detection if you will, is all about damage control in cases where features can’t be detected yet problems are known to exist. I those cases, specific versions of specific browsers are targeted and dealt with appropriately. The mechanism for this may be in the form of conditional comments or JavaScript code written for the purpose.