But how do you detect the 2 pixel vertical positioning error?

Um... by testing?

Seriously, there are dozens of browsers out there, but there are maybe four rendering engines that matter, all of which can be installed on a single computer if you've got a crappy testing budget. And 2-pixel positioning errors are much more a CSS problem than a JavaScript problem, so I don't see how JavaScript UA sniffing helps there. Unless you're using JS to compensate for CSS bugs, which is bound to bite you in the long run.

But whatever. I doubt you could even get in where I worked.

You assume that I'd want to ;)

Regardless, I've talked to a few people who've worked for "the world's largest retailer" (hey wait, I thought that was Wal-Mart?) and generally the prognosis is Not Good.

In the javascript? I don't see how I can tell from there that the thing has been drawn in the wrong place. But maybe you don't do applications and just do pages.

You go to your test machine, you fire up Browser X, and you look at a few examples of the effect in it. How does an "applications" versus "pages" distinction make a difference to that? Your application is, in all likelihood, going to be using some sort of templating, so the various types of pages will all look similar except for changes in content.

That's how I test JavaScript stuff at work, and it's not all that hard really.

CSS people have been compensating for bugs for years without doing UA sniffing ;)

But this is largely a red herring; my point is simply that UA sniffing to determine what features you'll let the user see is, and ought to remain, dead. If it's the most efficient way to solve a CSS bug, then that's another story, but the question here is things like whether you send your CSS to the browser at all, not whether you send the fix for a 2-pixel rendering bug.

WebTV needs to go on the garbage heap ;)

There's a new incarnation of that idea being pushed at work, we had to basically set up completely segregated versions of our sites on subdomains with their own templating and whatnot to deal with it and send the users over there, because there's no way to detect it (thanks to the way it works, to a server it's indistinguishable from normal IE 6).

Not really; the TV stuff, because of the interface it uses, had a different set of requirements for visual presentation. Which, fortunately, is really easy to do; one of my co-workers [link|http://www.postneo.com/2006/07/26/acknowledging-the-mobile-web-with-django|wrote up how we handle this sort of thing] for our mobile sites.

Edit: I should probably also take this moment to pimp Matt's talk from PyCon on [link|http://postneo.com/talks/pycon2006/|mobile development with Python].

Unfortunately, it's not actually WebTV, it's a WebTV-alike. I'll go poke at logs sometime this week, but I seem to recall that one of its major annoyances was not advertising itself in its UA string, and instead trying to be as much like IE6 as possible.

If we didn't test it, it doesn't get the cutting edge treatment, it gets the old safe one. The test isn't looking for mozilla in the string, it is looking at the whole string and finding the unique bit that only that browser sends. Spoofers have no right to complain and none of them ever have to my knowledge.

Except that's still somewhat backwards. There are lots of browsers out there that aren't Firefox, but will render pages identically because they're using Gecko. You don't need to test against all of them to know they work. Similarly, there are lots of browsers out there embedding WebKit/KHTML which will render identically to Safari, but you don't need to test against all of them to know they work.

Yahoo has an interesting methodology for this which I think is about the least offensive use of browser sniffing I've seen; they study each release of a major browser (IE, Firefox, Safari, Opera) and assign it a "grade" depending on its support for advanced stuff. Then their scripts, instead of being marked "this is only for Internet Explorer 6" or "this is only for Safari 2", can be marked "this is only for Grade A browsers" or "this is only for Grade C".

The important thing, though, is that they have a class called "Grade X". Browsers which have been thoroughly tested and proven to support advanced features are Grade A, and browsers which have been tested and proven not to support advanced features are Grade C. Everything else is Grade X, and Grade X browsers are assumed to have the same or more advanced capabilities than Grade A -- generally, they assume that an unknown UA string represents a new version or a major browser, or a new browser embedding a major rendering engine. Thus, instead of a whitelist of "known good" browsers, they have a blacklist of "known bad" and assume that anything else can handle advanced features. This is much more likely to be correct than the techniques used at, say, Google where I've got some pretty advanced browsers that they won't serve GMail to.

And of course, their JS libraries use object detection all over the place, so that system seems to come into play only rarely.

Except that strategy has the known drawback of producing lower revenues and higher trouble ticket counts. So I guess it depends on your goals.

Depends on how careful you are producing your "known bad" list, and heavily depends on the user. If, for example, Amazon ever "degraded" the page they send me because I'm using a new-ish Gecko or WebKit browser that isn't in the approved UA list, you can bet that'd be a lost sale for Amazon.

The existence of good, open-source rendering engines has basically turned this whole thing on its head; years ago it was better to assume that a new browser was deficient. But today, on average, it's better to assume that a new browser is embedding someone else's engine and is thus as capable as the well-known browsers.

(all of this, of course, ignores larger issues like progressive enhancement and graceful degradation, which are just as important and make UA sniffing even more irrelevant)