W3C home > Mailing lists > Public > www-style@w3.org > March 2004

Re: Proposal: useragent at-rule

From: Alan Plum <alan@cologneweb.com>
Date: Mon, 29 Mar 2004 18:06:18 -0500 (EST)
Message-ID: <4068AB12.5040703@cologneweb.com>
To: www-style@w3.org




Dave Shea wrote:
(snip)
> I believe this is the crux of it. In a year or three I will no longer 
> need to support IE5. I'll be perfectly content at that point to serve 
> unstyled markup to it, the same as many of us do now with NN4.x:
> 
>       <style type="text/css">
>         @import "filename.css";
>       </style>
> 
> Except that the mechanism to hide CSS from IE5 isn't quite so tidy as 
> the @import rule that worked in NN4.x. I'd have to go to ridiculous 
> lengths with the Box Model Hack to get it to work.

Actually that isn't exactly tidy either. I prefer avoiding the @import 
statement as some browsers tend not to load ALL imported stylesheets 
every time they load a page (I had five non-embedded stylesheets 
specified via link elements and in some cases Firebird 0.7 would ignore 
one or more of them - might be an issue with other browsers too).
Anyway.

 > And that's just IE5. What about Opera 5, Safari 0.85, Netscape 6, etc.
 > etc.? And what about browsers that we (the development community) don't
 > discover hacks for?
 >
 > Discouraging version-specific control is what has created a need for CSS
 > hacks in the first place; the reality is that developers deal with
 > flawed browsers.

Of course this at-rule was not introduced in order to allow locking 
particular browsers out, but just because it was needed.
However that's the whole problem. All hacks utilize flaws in browsers in 
order to lock them out from either the entire stylesheet or just 
portions of it. There is no "legal" mechanism that allows that, mostly 
because the whole action is considered counter-productive.

> Simply: we need a way to gracefully degrade our style for flawed and 
> older browsers, so as not to hinder usability/accessibility for our end 
> users.
> 
> I don't see anything in the official spec that provides an opportunity 
> to do this. I think that's a shame.

I don't think there's any way an organisation that focusses on standards 
will come up with a way of serving browser dependant stylesheets.
The entire mess we are facing in the real world (tm) is caused by 
manufacturerers shipping products with flawed implementations of these 
standards and claiming they support them.

The theory of browser independant webdesign, graceful degradation and 
absolute accessibility is nice, but sadly the real world is far from a 
stage at which all of these can be adopted entirely.
Browsers will claim they support things they don't and people will keep 
on designing for the most popular browser.
This might fade a bit if Mozilla, Opera and the other browsers get a 
larger market share, but with the Internet Explorer and all its flaws 
dominating the market, the introduction of revolutionary new selectors 
and stylings is a bit unrealistic.

What would be better would not be a language dependant and thus 
client-side check for compliance, but a way to check it on the server side.
It has been and will always be the job of the web designer to check if 
the design works with that-and-that browser, but apart from designing 
with the tight restrictions browser independant layouts require, the 
only way to solve the problem is going server-side and delivering 
content (and stylesheets) the browser can understand.

The user agent string is apparently no longer a safe way to identify a 
browser and thus assume its standards support, so someone might have to 
work out a better way, maybe via RDF, but that'll require a standard of 
its own anyway.

The checks required for double-checking whether a browser actually 
understands the style rules you're feeding it require a whole scripting 
language, not just a static stylesheet. Unless we want to use javascript 
or add tons of scripting syntax to CSS, server side should be the way to go.

-ap
Received on Wednesday, 31 March 2004 09:11:33 GMT

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