W3C home > Mailing lists > Public > www-style@w3.org > August 2008

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

From: Simetrical <simetrical@gmail.com>
Date: Mon, 11 Aug 2008 11:00:15 -0400
Message-ID: <7c2a12e20808110800g3b00c451h8d5d0fafcbcaed8a@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Brad Kemper" <brkemper.comcast@gmail.com>, "Keryx Web" <webmaster@keryx.se>, "CSS 3 W3C Group" <www-style@w3.org>

On Mon, Aug 11, 2008 at 10:25 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> The fact that he knew *how* to work around Opera's behavior showed that he
> knew enough to feature-detect.  It would have been just as easy to do a
> quick detection of the problem and change behavior if necessary.

I wouldn't say it would have been *quite* as easy.  With a little
thought and a few minutes' poking, yes, you could do it: "if the rows
are in the wrong order, swap them".  That's going to be a little
longer and more involved than the two-line hack that actually was
used.  But yes, only slightly more troublesome.  In *this* case.

The problem is that doesn't apply at all to CSS.  You have no way of
testing things robustly.  You can't say "if the float renders below
the current line box, move it up by a number of pixels equal to its
height" to work around floats rendering on the wrong line under some
conditions in IE <= 7/Fx <= 3.  (This is fixed in Fx3.1 -- yay! -- and
I hope in IE8.)  You can inspect the document tree to a limited
extent, but even that you can't do much with.  And practically all CSS
deficiencies are in rendering, not in the document tree.

This case was one where the author did the wrong thing with UA
sniffing.  But it has little to no bearing on the current discussion,
except for the observation that authors should be strongly encouraged
to use "UA version <= x" instead of assuming future versions will have
the same bugs.  Maybe.  Actually that's a nice idea in theory, but it
has the very pragmatic disadvantage that any given bug is unlikely to
be fixed in the very next version of the browser.  If the author in
the original post had followed this tactic, the software would have
broken for several versions of Opera users in a row, not just one.
Bugs are only *fixed* once, usually, but they can (and do) *recur*
many times.  So having a reasonably open-ended upper limit is probably
the best thing as far as user experience goes, when capability testing
is impossible (which it was not in this case!), although it has its
problems too.

> The question you have to address is just *why* implementors are unhappy with
> UA detection in javascript.  Hint: it's not something unique to javascript.
> Browser sniffing is inherently flawed, and punishes implementors for fixing
> bugs in their browsers.

The point is not to allow browser sniffing, because that's already
possible (via JS or selector hacks, say).  The point is to make it
cleaner, more reliable, and more explicit than the current hacks
allow.  Would the Web be better off if JavaScript didn't have
User-Agent checking?  No: people would just rely on non-standard lists
of hacks to expose browser-specific functionality.  if(
userAgent.indexOf( 'Opera' ) != -1 ) would become some
incomprehensible line of code copy-pasted from a website that checked
if document or window had some specific member variable.  That's the
state of affairs in CSS right now, and it benefits no one.
Received on Monday, 11 August 2008 15:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:11 GMT