W3C home > Mailing lists > Public > www-style@w3.org > November 2007

Re: Proposal of @ua

From: Brad Kemper <brkemper@comcast.net>
Date: Thu, 22 Nov 2007 00:27:57 -0800
Message-Id: <43A4B013-4A43-486C-8C98-946BB4039AC1@comcast.net>
Cc: "WWW Style" <www-style@w3.org>
To: "Rijk van Geijtenbeek" <rijk@opera.com>

On Nov 21, 2007, at 2:10 PM, Rijk van Geijtenbeek wrote:

> It is important to note that the @ua rule would only help for new  
> browser releases, it doesn't help one bit in coping with the  
> differences between the current (and past) crop of browsers.

I agree with that statement, mostly (although if the newer version  
has the @ua rule and the older version doesn't, then the rule can  
serve separate CSS to the newer version, overriding the properties  
previously set for the old).

But really, its the new browser releases that concern me the most,  
since I still have a few hacks to deal with the existing browsers.

The thing is, each new browser update seems to become more  
standardized with the others in terms of the selectors (and @ rules)  
they support, and it is therefore harder to write CSS filters to deal  
with the significant rendering capabilities that continue to exist.

So we are left with the same need we had before, but with fewer  
options for dealing with that need. And there always will be  
differences, because CSS-compliance is a moving target, and also  
because software always ships with some bugs, and also because there  
are designers trying creative things and mixing together CSS  
properties in unexpected ways.

Bert Bos mentions the varying implementation schedules in his  
interview on xhtml.com, which implies that it will be a long wait  
before all major browsers are supporting the standards in largely the  
same way:

 > And when they do implement them, such as rounded corners in  
Firefox and Safari, multiple backgrounds in Safari, columns in  
Firefox, media queries in Opera, vertical text in IE, etc., it is  
often because a need that one vendor has and the others not, so we  
end up with just one implementation [...] the browsers have  
sufficiently different "markets" that they are likely to implement  
modules in a different order. E.g., some look primarily at what is  
needed for mobile phones, others focus on Web-based applications  
(such as widgets). And they have many modules to choose from… [...]  
Over the next four or five years most of the modules will become  
implemented, I think, and the rest we will drop definitively. I can't  
tell you which ones, though…

Great. 4 or 5 years before the current modules are implemented, and  
meanwhile new ones are being considered and implemented according to  
varying priorities. And some of them, like generated content or  
alternate box models, just can't be used that much until they have  
widespread support, unless designers are willing to accept  
significant degradations in their design for large portions of their  
audience/user base, or unless authors are able to provide different  
CSS for those browsers that don't support the same capabilities. 
Received on Thursday, 22 November 2007 08:28:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:31 UTC