- From: Anton Prowse <prowse@moonhenge.net>
- Date: Fri, 01 Apr 2011 21:39:52 +0200
- To: www-style@w3.org
- CC: Glenn Linderman <v+html@g.nevcal.com>
Hi Glenn, Most authors also tend to assume that when their page looks wrong in Browser X it's because Browser X is wrong. Often, however, Browser X isn't wrong; instead Browser X is exercising free choice given to it via the CSS spec, either granted explicitly or more usually through making the rendering undefined when certain conditions are satisfied. (Search for the string "define" in CSS21 to catch the instances of "is not defined", "does not define", "undefined" etc to see just how many there are!) Making browser sniffing easy is just begging for less knowledgeable authors to "fix up" Browser X instead of reviewing their understanding of the language (eg via tutorials, books) and switching to different CSS which does render the same cross-browser. This is a problem, because unbeknown to the author, Browser Q also (legitimately) renders the page in the same way as Browser X... but the author didn't test in Browser Q so they didn't notice. Users of Browser Q now see broken pages. Alternatively, perhaps Browser X is correct and in fact it's Browsers W, Y and Z that are wrong. This doesn't happen so often any more, but back in the era of Firefox 2, for example, IE6 got some common aspect of stacking contexts correct when other major browsers all got it wrong. Most authors assumed it was IE6 up to its usual tricks, and hacked to "fix" that browser. They were pretty mystified when the other browsers updated their rendering in later versions, resulting in page breakage in all modern non-IE browsers! Again, if the author had researched the problem instead of opting for a quick fix for Browser X, they would have realized that their chosen technique isn't yet reliable and would have changed to a different one. Hence browser sniffing makes it really easy for authors to unintentionally give certain users a bad experience. It also makes CSS much more difficult to maintain because the CSS is forked; the consequence of some later change elsewhere in the stylesheet has to evaluated in multiple ways, once for each fork. Even at the best of times authors seem to find it rather hard to understand from a global perspective the many many interactions going on inside their CSS. I'm not hopeful that expecting them to hold /multiple/ global perspectives, one of each fork, is realistic. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Friday, 1 April 2011 19:40:26 UTC