W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3] [css21] browser specific CSS

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 01 Apr 2011 21:39:52 +0200
Message-ID: <4D962A08.9060601@moonhenge.net>
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 

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.

Anton Prowse
Received on Friday, 1 April 2011 19:40:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC