Please visit my new campsite listing site

In defence of jQuery browser detection

I read somewhere the other week that jQuery is deprecating its jQuery.browser method, which means that in the future (though not yet, as the method still works but will not continue to be developed/supported, and will eventually be dropped) you will not be able to directly ask jQuery which browser it is being run in.

The rationale behind doing this is on the face of it sound: The reason you want to check what the browser is is that you want to check if a feature of javascript is available in that browser… so why not just ask if that feature is available, then the question of which browser it is becomes irrelevant. This will enable your script to continue to function (most probably) even in the unlikely event that eg Microsoft bring out a patch for ie6 that makes it fully support javascript.

But there is a flaw in this reasoning. It assumes that the only reason you would want to serve some different script to a browser is because of flaws in the browser’s javascript implementation, but in fact there are other reasons for doing this too, principally the browser’s failure to render CSS correctly.

While the new method does include tests for boxModel (ie6 and 7′s incorrect rendering of the CSS box model being the principle reason behind serving different CSS to different browsers) and one or two other CSS bugs, this simply isn’t up to the task. The box model is broken in ie6 and ie7, but broken in different ways, so normally to fix a layout bug I will want to serve different CSS to both.

Using various combinations of, eg

! &&

you can still detect ie6 and ie7… but is this really an improvement on jQuery.browser?

jQuery.browser.msie && jQuery.browser.version.substr(0,1)=="6"

With jQuery.browser it is wholly transparent what you’re trying to detect, and if the code within the conditional’s braces contains a hefty amount of CSS rules your average developer should be able to work out the reason for the browser detection is to fix CSS bugs.

One other reason for explicitly detecting a browser (which I need at the moment as I’m developing a jQuery plugin) is that different browsers render form elements differently (the most obvious black sheep is safari’s making most elements look blue and glossy, but there are subtle differences in other browsers too). If I, say, want to fake a <select> element  by using a <ul>, and want it to look convincing in all browsers I need to supply each browser with differentiated CSS. jQuery.browser would be the obvious way to do this. No matter how many CSS bugs get fixed in browsers, how to render form elements by default isn’t specified by CSS/html, so there will always be this reason to want to detect browsers.

jQuery.browser is a very useful feature and it’ll be a shame when it goes.

No related posts.

Tags: , , , , , , ,

5 Responses to “In defence of jQuery browser detection”

  1. Excellent points. Just stumbled across your article. I too, have the need for browser detection in most of the apps I work on professionally. While the supports feature is nice, I agree with you; it doesn’t cover all the bases.

  2. Paul Irish says:

    A few things..

    While it does say deprecated, I’m pretty confident jQuery.browser won’t be going away. You needn’t worry about that, IMHO.

    I also admit that, currently, it’s not totally realistic to drop browser sniffs completely. Eric Martin of Simplemodal gave the good example of IE6′s nasty technique of showing select dropdowns through all layers. I don’t think that’s testable.

    However many things are testable so that leads us to these three points…

    1) Everyone should agree that feature detection is a better and more robust approach and should extend the object to test for their needs

    2) however sometimes it’s not possible to use for what you’re working around

    3) and sometimes the test would be too expensive to run from a performance standpoint (though I haven’t seen one yet)

    • wheresrhys says:

      If you’re right, and jQuery.browser is not going away, that’s certainly a good thing, but it does beg the question of why they bothered deprecating it. Probably to prevent people who should be using .support from using it inappropriately… but I say let them. As jQuery largely hides browser specific javascript tweaks away inside its methods it already is very effective at weaning people away from the habit of checking the browser at every turn. So for jQuery users – who aren’t forced to learn about what js bugs apply in which browsers – it’s certainly easier and more intuitive to check for feature support rather than the browser in most cases.

  3. RistoT says:

    Even if it goes away, YOU can still use it via a jquery plugin

  4. Yuvalik says:

    I have been saying exactly that. Although feature detection sounds good, you can never expect it to work 100% for all possible things you are looking for.
    How to determine is a browser supports transparent PNG? or @font-face?
    It would be nice if it could be done with feature detection, but the truth is, even if it is possible, it creates oodles of code and is just not efficient.
    Targeting a browser is -for the time being- much more realistic.
    I guess it is one of those hyped ideas that everybody follows without thinking.

Leave a Reply

Security Code: