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

Re: @media and browsers conditional statments

From: Anton Prowse <prowse@moonhenge.net>
Date: Tue, 12 Aug 2008 21:32:51 +0200
Message-ID: <48A1E563.7000407@moonhenge.net>
To: CSS 3 W3C Group <www-style@w3.org>

Brad Kemper wrote:
> The specs are full of places where it says that its up to the UA to decide.

> And as long as CSS continues to progress, there will always be 
> differences to work out. We will never be at some utopian place where 
> all browsers (or even all but IE) render everything in the exact same 
> way and support all the same CSS.

Indeed, and this is the very reason why user-agent sniffing (in any 
form) is a dangerous thing.  The availability of user-agent sniffing 
puts the onus on the developer rather than the browser implementor to 
fix problems, which has potentially dire consequences.

If developers get into the habit of correcting perceived or actual 
misbehaviour -- or attempting to unify intentional differences -- of 
different user agents, there would be considerably less pressure on 
browser implementors to converge their different approaches to a given 
stylistic problem, because they would always have the excuse that there 
exists an easy work-around.  Yes, all major UA developers have a stated 
commitment to standards, but as they iterate towards common behaviour, 
two different implementors might each have valid reasons to support 
their own preferred behaviour and syntax for stylistic issues that are 
currently experimental or not yet standardized or intentionally not 
standardized.  (A recent example of conflicting opinions is CSS 
constants/variables.)  Currently, developers avoid tackling 
not-yet-standardized issues and instead wait for the implementors to 
agree;  making it easier for developers to tackle these issues before 
convergence is reached reduces the pressure on implementors to reach 
convergence.

Worse, making it easy for developers to apply quick fixes encourages 
them not to analyse the problem that they are experiencing.  More often 
than not, cross-browser discrepancies arise not because of "broken" 
browsers but because the developer is doing something nonsensical 
(although not necessarily invalid) in their CSS only to find that one 
browser is more forgiving about than another.  (I have seen this time 
and time again with developers of all abilities -- and I readily include 
myself here.)  With the ability to target different UAs, developers will 
be less inclined to sanity-check their CSS.

The fact that some sort of user agent sniffing can currently be 
performed on the basis of parser exploits is not a reason to sanction 
it; indeed, the lack of official sanction means that non-experts are 
discouraged from using hacks and instead are encouraged to accept 
cross-browser differences or avoid styles which lead to differences 
which are unacceptable.  This is a Good Thing:

Firstly, because it avoids a false impression that the web is a page 
description language.  There is no reason why user agents should render 
everything identically, especially those important 
usability/accessibility features such as form elements.  (For example, 
there are genuine usability advantages to using the operating system's 
default style for form elements elements [although I would be the first 
to lament the ugliness of some of these styles].)

Secondly, because developers would come under significant pressure (from 
their boss or client) to spend a great deal of time trying to achieve 
the elusive-by-design cross-browser pixel perfection at the cost of 
superficially invisible but more important tasks that good developers 
undertake such as obtaining a meaningful document structure and markup. 
  There are only so many hours in a project....

Nobody disputes the obvious power that user agent sniffing could bring, 
particularly as regards fixing genuine erroneous behaviour; but with it 
comes danger.

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Tuesday, 12 August 2008 19:33:04 GMT

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