Re: Bug detection (providing techically incorrect input for incorrect implementation to get "correct" result)

Brad Kemper wrote:
> 
> 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.

I agree that often one cannot figure out the problem of a single browser
to this detail and some bug workaround is required for selected
browsers. However, I definitely do not agree that the bug workaround
should be enabled for a browser in general. Instead the workaround
should be enabled for selected versions only. That is, one should not write

	if (isOpera) { ... }

but instead

	if (ua.brand == "Opera"
		&& ua.version >= 9 && ua.version <= 9.50) { ... }

Note the difference: I'm targetting the versions I've detected the bug
in. I'll not *guess* that this browser will contain the same bug in the
*future*, too. I'll not guess which version had the problem the first
time. I assume that if I've seen the problem in 9.0 and 9.50 the the
problem exists in every version in between. (Might not be always true.)
This way the vendor does not get a hit for *fixing* the bug in the
future and only users of this vendor's future *broken* releases will
suffer. That is, until I have time to test that future release, the
users of that version will suffer even though I've enabled workaround
for the very same bug for older releases.

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

The maintenance nightmare that is the UA released by the same vendor,
that works to the spec, *will not work correctly with the content you
provide*. I think it's a maintenance nightmare if a perfectly working UA
cannot show the content correctly because of a bug workaround inserted
in the content. However, the fact that incorrectly working UA (released
in the future) shows the content incorrectly is not a maintenance
nightmare. It's only about supporting that incorrectly working piece of
crap if that's really desired. That's something one could call
maintenance as regular.

In short: maintenance nightmare is something that is done today that
prevents doing stuff correctly in the future without extra work to undo
the work that has been done today.

The maintenance nightmare content is the stuff that *prevents* users
from using the latest, *correctly* working releases of the UAs. Only
because the content is *intentionally* authored to work *incorrectly* on
said UAs!

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

I agree. It is not realistic to start normal scripting with conformance
test suite and then trying to detect any random bug in the UA and then
trying to workaround that previously unknown bug in the possibly
previously unknown UA. How do you do that? Will you write tests to make
sure that the workaround will not hit some *other* bug in the said UA?

The bug detection routine is good for enabling the workaround
automatically for browsers with exactly the same bug. Assuming, of
course, that the bug detection is perfect and that the original bug is
*correctly* diagnosed in usually closed source UA. Often you cannot
assume that last part.

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

To prevent the problem we already have e.g. with user agent strings.

For example, MSIE says that it is "Mozilla/4.0" and provides the actual
version in the comment part. Other browsers say "Mozilla/4.0" at the
start of the user agent string, then repeat magic letters "MSIE" in the
comment part and then follow with "just kidding, not really"....

If the implementors could enforce that sniffing could be used for
workarounds only and a *correctly* working UA can display *everything*
correctly if it doesn't execute any workarounds, I guess they would
happily implement it. However, content authors have repeatedly
demonstrated that the actual content will be surrounded with those
safeguards and the only way to get the content is to claim to be THE ONE
"supported" browser for that content.

After saing that, I do support allowing browser engine sniffing in CSS
but I'm afraid that the syntax must be made so hideously hard to use
that a casual web author would not ever use it. Perhaps require that the
CSS embedded in the workaround part must be inserted inside a string
base64 encoded or something. And even then, some authors would probably
try to use that mechanism for "copy protecting their style".

-- 
Mikko