Re: Bug detection (was: Re: @media and browsers conditional statments)

On Aug 7, 2008, at 1:14 AM, Keryx Web wrote:
> We have recently seen UA detection fail yet again: http://dev.opera.com/articles/view/a-browser-sniffing-warning-the-trouble/

 From the article:

> The TinyMCE/Opera 9.5 compatibility problem is a textbook example of  
> why browser sniffing should be avoided at all costs.


To the contrary, the problem they describe is a textbook example of  
why browser sniffing is still useful. With just a couple of lines the  
author was able to add support for Opera, despite their small market- 
share, without having to spend a lot of time trying to track down why  
Opera behaved like that, or write complicated code trying to detect  
the root cause once they figured it out.

> While it may seem like a quick and simple shortcut to work around a  
> bug in the short term, browser sniffing creates a maintenance  
> nightmare further down the road.


What maintenance nightmare? Do people even consider what they are  
implying before they write things like this? The browser sniffing  
author in this case showed that they afford to pay a little attention  
Opera, by adding the workaround to an Opera-only bug. So it is no  
surprise that they were able to go back in and add another 36  
characters to let the newer bug-fixed version of Opera work in the  
same manner as all other UAs are expected to work. How is that a  
maintenance nightmare? The author learns that Opera fixed the bug in a  
way that broke his code, and he quickly issues an easy fix.

Anyone else using his code either cares or does not care that the old  
code breaks on the new Opera; if they do care then they go download  
the newest version, or do their own troubleshooting. If a newer  
version of Opera broke my code, and I wanted to troubleshoot, the  
first thing I would do would be search my code for the string "opera",  
and find the places where I am working around bugs by browser sniffing  
for it.

The bug detection routine that the article proposes is much more  
complex, assumes the author would have the time and inclination to  
investigate the problem to the degree needed to write something like  
that, and also assumes that all UAs that might need this routine would  
flawlessly support other modern JavaScript methods like  
document.implementation.createDocument. Its impractical to test for  
possible flaws in every built-in method you might use, but a little  
browser sniffing for known problems in known rendering engines can  
provide work-arounds that help more than they hurt. Especially if the  
alternative is to just not spend any time at all on a problem that is  
only known to affect less than one percent of the site's audience  
(since those of us who write code for a living often have to justify  
the time we spend on something).

Don't get me wrong; I'm all for object detection or other simple  
support/bug detection methods instead of browser sniffing. But if I  
come across some obscure bug that only affects IE6, for instance, (and  
I do, a lot), I'm not waste a lot of time trying to figure out just  
what exact bit of twisty program logic lead to it and try to write  
something to detect for that root cause. I'm just going to write a  
work-around as quick as I can for IE6, and move on, assuming (almost  
always correctly) that there is no other browser on Earth (other than  
IE7 sometimes) that will be impacted. If someone wrote some obscure  
browser somewhere that shares IE6 bugs, then God help them, because  
they've hitched their horse to the wrong wagon, and their users are  
already accustomed to a pretty sucky experience.

OK, sorry; that was partially a rant against IE6. Except I'm not  
really sorry enough to remove it.

> Whenever you feel tempted to solve a problem with the inelegant  
> browser sniffing hack, take a moment to ask yourself if there is a  
> simple way to detect the bug instead.


In the case of CSS, the answer is always "no". The only method  
currently available is by using parsing hacks (or IE's comment hacks,  
if you want to detect IE specifically). And those are going away  
mostly in newer and newer versions of modern (i.e., non-IE) User  
Agents. Proposals for feature detection have much worse problems than  
UA detection (the browser will say it supports something, even if it  
is buggy). We do have media queries, which would be a natural place to  
query for a particular rendering engine, UA, and/or version number.  
But implementors refuse to implement it.

I've enjoyed reading the logical arguments for UA detection here  
recently, but logic has been tried before on this topic,  
unsuccessfully. In the end, the answer back from implementors has been  
"we are not 100% happy with the results of UA detection in JavaScript,  
and so we're afraid to try anything even remotely resembling it in any  
way in CSS." Or more succinctly, "We don't wanna, we ain't gonna, and  
you can't make us."