Some people are really hard core about object detection and others depend totally on browser detection. Personally, I think both sides are right. To me, it’s the same argument as what language to write your code in. You use what you need to get the job done, period. I’m not claiming one is better than the other, I’m just stating that they are both useful when used properly.
The first thing people say about User Agent sniffing is, “I can change the User Agent of my browser and things break.“. Well my answer is, “And I care why?“. I think that if you go through the trouble of changing the User Agent string on your browser, then you should not be surprised that things break. In fact, you should be expecting it. That would be like me changing the information on my license plates and then telling the officer: “You should have checked the VIN instead of the license plate, I didn’t like what it said so I changed it“. It’s a stupid argument, get over it already!
As for the object detection crew, you also need to do things right. If you are going to detect object’s make sure that you are doing it correctly. Here’s looking at you: document.all.
While developing the YUI Rich Text Editor I learned that browser sniffing is, in deed, quite needed. Now, YUI does browser sniffing a little different. We try to detect the different rendering engines, so there is no firefox, mozilla, safari or chrome. It’s gecko, webkit, ie, etc.. The main reason that sniffing is needed in the Editor is because of the execCommand method. All of the A-Grade browsers support the method. The method is there to detect, but they all don’t do the same thing when executed. So how am I to tell what I am supposed to do? I have to rely on sniffing in order to make the browsers behave the way I want them to.
Let’s look at a another example. The method getBoundingClientRect was introduced in FireFox 3 and Opera 9.5 to match what was formerly an Interet Explorer only option. Now using object detection you would have done this:
Now what about the few cases where Internet Explorer reports position off by 2 pixels? How are you going to deal with that? Browser sniffing, like this?
Not to forget you object detecting guys, I have seen others do things like this (snagged from Mr. Zakas, who i quote “I [Nicholas] have to say right off the bat that hate this solution“):
In my opinion, isn’t this the same thing as browser sniffing? Aren’t you checking something that you know is unique about a particular browser and leveraging it? Doesn’t that also qualify as browser sniffing? If you are looking for some flaw in a browser to determine a course of action, wouldn’t it be easier to just read the User Agent and work from there? You can process that info one time and use it everywhere.
Now to be perfectly clear, I am not saying one is better than the other. I am simply stating that there are uses for both, just like there are uses for both PHP and Python, VIM and Emacs, Gnome and KDE, Harley and Honda, Mac and Linux (Windows doesn’t count to me). You use what you need to get the job done. As with everything else make sure you make the right choice for the right job 
[...] some take on object detection vs user agent sniffing which I am not going to discussing in this [...]
Hey Dav,
First off, glad your site is back up. Wanted to reply but couldn’t…drove me nuts.
To answer your question of if my solution is the same as browser sniffing, the answer is no. I, of all people, know the arguments both for and against each type of sniffing. My concern with getBoundingClientRect was twofold: 1) IE might fix its implementation in a future version, which would then require me to update the script when I know what that version is, 2) one of the other browsers might change their implementation to match IE’s. My ridiculously hacky, dirty solution that you cite protects against both of those circumstances.
My main concern with writing code is how long it can continue to work as expected without any updates. A solution that is tied to a specific browser implementation is inherently fragile; a solution that uses the implementations as a guide to determine the best course of action without assumptions is better. That’s how I ended up with this solution (though, in typical Nicholas fashion, my original description was a bit too terse to really make that clear).
Btw, what’s a guy gotta do to get a blogroll? Would an autographed book do the trick?
Hey –
I added you to the Blogroll
My take on this is why should I add “cruft” code to check something that I know only affects one browser? As for IE fixing the issue, that is great, but the YUI browser sniffing includes a major version, so I can check against that and update it when needed.
I guess I should have mentioned the IE 6 select box bleeding issue as another problem that can’t be solved with feature/object detection. Is there any way to test that a select will bleed through an element? Nope. There are other GUI based issues that people don’t run into until they are dealing with widgets/gui apps. Which is where browser sniffing is more of a factor than in utilities..
Pro users who tweak their user-agent strings seem should certainly assume a “proceed at your own risk” mindset. Normally, I’m like you… I try to find the middle ground and use whatever tools are in my toolbox where appropriate.
How about your take on users who have had their browser’s user-agent string modified unknowingly? For instance, on the Windows operating system it is quite easy for software to modify the user-agent string (via the registry) and insert anything from innocent vendor identifiers to common render engine strings. Here’s a user-agent string straight from a recent web server log:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Sky Broadband; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1))There are all sorts of improbable combinations like this in the wild… do you assume this is IE7 or IE6? Without doing object detection, I’m not sure you’d get a definitive answer. (I’d like to trust that what’s happening is a series of strings being appended. Thus the MSIE 6.0;… bit is cruft injected by a 3rd party. Relying on that type assumption doesn’t seem like a great idea.)
I would assume it’s IE7 since that is the first one in the string
Yes there are all kinds of them in the wild, but there is a limit to what you can and can’t support in situations where there is no way to use feature/object detection. So there is only one thing left to do, sniff.