- From: Simetrical <simetrical@gmail.com>
- Date: Mon, 11 Aug 2008 11:00:15 -0400
- 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 UTC