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..

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.

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?

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.)