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

Re: Proposal of @ua

From: Brad Kemper <brkemper@comcast.net>
Date: Sun, 25 Nov 2007 21:00:22 -0800
Message-Id: <39DEDF45-D30D-45E6-8DB7-C4A3F9E2F0ED@comcast.net>
Cc: WWW Style <www-style@w3.org>
To: jesse@dutchmoney.com

No, that won't get you very far, because even a UA that claims to  
support a property may support it differently from the others, or may  
not support all the same possible values. For instance, IE doesn't  
support "inherit" as a value of any property, and has different  
visual results on some properties based on whether the element "has  
layout".

For more about that, and for a sample of the frustration authors feel  
when they try to work around it, check out these pages:

http://www.sitepoint.com/blogs/2007/11/22/in-all-fairness--internet- 
explorer-still-stinks/

http://www.webdevout.net/browser-support-css#support-css2propsbasic
(be sure to mouse over the yellow rectangles)

In some cases you might even have to know if the browser supported  
some (possibly proprietary) feature of HTML, such as Webkit's  
"placeholder" or "type=search" atributes on INPUTs.

In a nutshell, if you want a consistent presentation across at least  
the most dominant browsers, you either have to restrict yourself to  
very basic styling, or use hacks, or  do sniffing and parsing of  
complex, misleading User Agent strings (or wait 5 years and hope it  
gets better). And the implementors refuse to even consider a better  
way because they feel compelled to lie whenever and wherever their  
software might be asked about what rendering engine it is using.

Except for Internet Explorer, which to its credit, does branch in a  
straightforward and honest way when pages use conditional comments to  
access the proper CSS based on not only the software but on the  
version of the software. And for some reason, the other browsers do  
not feel compelled to try to dig into these conditional comments to  
try to pry loose some CSS rules they might otherwise be missing.

This is probably because the same dogma which insists that they  
should never ever ever give a short honest answer to a UA query (or  
ever ever consider having another place where a similar type of  
question is asked in a different context) also states that they  
should not look inside comments for content that can affect the  
rending of the page.


On Nov 22, 2007, at 5:30 PM, jesse von doom wrote:

> Forgive me if this has been mentioned before, but I haven't seen it  
> in my 4-5 months on this list...
>
> But it seems like you don't really care about detecting the user  
> agent *or* rendering engine. You're looking for support for  
> specific CSS functionality. Given that, wouldn't something more  
> like this be in order:
>
> @supports multiple-background-image {}
>
> I know that a browser could lie in its response, but that's true  
> also of  the @ua idea. I'm not fully convinced either method is  
> necessary, but this would be requesting information about the  
> implementation of the specs, not about the implementor of the  
> specs. The burden of knowing support levels in new releases of  
> every browser is taken off the author; and there's no reason for a  
> browser-maker to give a false answer, since any author using an  
> @supports type query would (in theory) be writing gracefully  
> degrading layouts.
>
> It seems to me that @ua would solve a problem but introduce  
> another, whereas querying for capabilities would only solve a  
> problem, and support smaller browser-makers too.
>
> j
>
>
>
>
>> Yeah, it seems pretty clear I shouldn't hold my breath hoping much  
>> of the software will come around to addressing the biggest, most  
>> obvious need of Web page authors. I guess I will just have to  
>> choose between continued use of hacks, or avoiding all CSS that is  
>> not supported by the big 3 or 4. That or use sliced up images and  
>> tables when I want to achieve an effect that would cause ugliness  
>> in one of the major browsers that didn't support a more elegant  
>> means to the end.
Received on Monday, 26 November 2007 05:00:51 GMT

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