- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 1 Apr 2011 09:43:04 -0700
- To: Glenn Linderman <v+html@g.nevcal.com>
- Cc: www-style@w3.org
On Thu, Mar 31, 2011 at 8:20 PM, Glenn Linderman <v+html@g.nevcal.com> wrote: > Thanks for your response, Tab. I was unsure where or how to raise this > issue. If there is a better place or better technique, please let me know. Nope, this is just fine. > On 3/31/2011 4:24 PM, Tab Atkins Jr. wrote: >> Browser-specific hacks are a strong anti-pattern that we shouldn't >> propagate, or even worse, officially bless in CSS. This does mean >> that us web authors have a somewhat more difficult job, either >> designing good CSS that still works in the presence of bugs, or making >> our code ugly with hacks on occasion, but I think that's an acceptable >> cost. > > I understand about the anti-pattern... but that is clearly a purist point of > view, with little practicality. Forcing sites to use JavaScript just to > detect which buggy browser one is dealing with is a significant negative, > particularly when users turn Javascript off, and not all web hosts support > CGI scripting (or limit it to particular scripts they install). Sorry, but you're wrong here. Using browser detection feels like the easiest solution from the author's POV - after all, you know what version is buggy, so why not just deliver a hack for that specific version? - but when you're looking at the problem from a mile up, you see the nasty effects that all these reasonable local decisions have on the global environment. Boris's latest response is spot-on in this regard. The sad truth is, a large percentage, probably even a strong majority, of authors simply don't know how to use browser detection properly. It's not that difficult, but there are some subtle issues to worry about when making the detection reasonably future-proof, and these are often skipped over since it doesn't make a difference *right now*. We can see the results of this with UA-string detection, and the *horrifying* pain it causes browsers *and users* when badly-done UA detection breaks a site because some new browser, or a new version of an existing browser, comes out that is improperly sorted by the detection routine. In other words, browser detection is bad for the web. It sounds good to you, the author, right now, but it hurts users in the future, and the standard ordering of constituencies puts users above authors. Thus, making browser detection continue to be somewhat difficult and painful is a Good Thing(tm), because it means that people will hopefully use it less. >> The one area where we *do* want to do something, imo, is in making CSS >> capable of doing feature-testing. This has been proposed in the group >> before, via an @supports rule. This doesn't let you work around >> browser bugs (except insofar as you can abuse this to do browser >> selection similar to how you can abuse vendor-specific selectors), but >> it does let you work around less powerful older browsers that don't >> understand some new functionality. > > So this recognizes that full implementation of the standard in all browsers, > at best, will require some amount of implementation and migration delay, but > fails to assist in compensating for bugs and/or variant and/or faulty > interpretations of the standards in those implementations... which there > will no doubt be, based on historical trends and the state of software > development. > > Recognition of the problem without providing a convenient solution to it > does not make for a friendly standard. Indeed, it doesn't account for bugs. You can't do so without browser detection, which I've already explained is a bad thing for users and thus is bad for the web. > There is yet one more alternative, of course, and that is to feed > browser-specific CSS files based on the User Agent string... but spoofing > the User Agent is rampant in certain circles, which could be disastrous to a > well-designed site. Ironically, spoofing the UA string is rampant *precisely because* browser detection based on the UA string is usually done badly. > It would be highly friendly if CSS required the browsers to "man up" to what > version of what browser they actually are, so that as their deficiencies > come to light they can easily be detected and compensated for rather than > forcing the use of browser-specific CSS, Javascript, or ugly hacks. Boris answered this - browsers aren't going to do this, for the reasons I outlined above. Most people use this information in incorrect ways, and this hurts current users of niche browsers and future users of popular browsers. ~TJ
Received on Friday, 1 April 2011 16:43:56 UTC