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.★
I agree with your synopsis that browser detection is evil, but what do you do with your example in safari?
if you get “knee deep” in code then determine that in safari it can’t handle the method, how do you bail out nicely?
I prefer to do browser detection, including versioning, and apply tweaks as possible for each browser, AND thus be able to If / Else wrap my other method calls to avoid known bugs.
e.g.
if(isSafari && isSafari3){
//workaround bug X
} else {
//process normally
}
This allows me to handle new versions of Safari, presuming that things are fixed. If they don’t get fixed, I just tweak my JS to handle it.
I got into this habit after reading Web Bug Track, which nicely highlights the most painful JS bugs in each browser.
e.g.
http://webbugtrack.blogspot.com/2007/08/bug-152-getelementbyid-returns.html
Which, like your example works around IE and OPERA bugs with getElementById.
Thanks, stanley
@Stanley: Good question, in the case of Safari, and the example that I based my post on, I just overrode the behaviour outright. So no matter the browser, I based myself on my own generated index value instead of cellIndex. Otherwise, you’re right, a simple if/else workaround for a target browser is sometimes the best we can do.