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.