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

Re: Proposal of @ua

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 29 Nov 2007 10:57:58 -0800
Message-ID: <474F0BB6.9000105@terrainformatica.com>
To: Andrey Mikhalev <amikhal@abisoft.spb.ru>
CC: www-style@w3.org

Andrey Mikhalev wrote:
> On Thu, 29 Nov 2007, Andrew Fedoniouk wrote:
>
>> Andrey Mikhalev wrote:
>>> On Wed, 28 Nov 2007, Andrew Fedoniouk wrote:
>>>
>>>>
>>>> 1) As CSS makes custom keywords perfectly legal then you can do:
>>>>  @media screen and supports(-moz-radius) { }
>>>> to filter out Mozilla only rules.
>>>
>>> wrong. just infamous embedded engine supports single mozilla's 
>>> extension, nothing more
>> Beg my pardon but what exactly is wrong there?
>> And what is that "infamous embedded engine"?
> i mean vendor of some layout engine may support non-standrd properties
> of another, isn't it? (e.g. to simplify porting/migrating web apps).
> so, in general, you cannot select 'Mozilla only' rules using single
> css property check.
Yes, someone can implement, say, -moz-radius in some other engine. 
That is why I think that engine specific rules (a.k.a. @ua) are 
conceptually wrong.

If your design requires exactly -moz-radius style then you will use
@media screen and supports(-moz-radius) { }
@media print and supports(-moz-radius) { }
and that will match all engines that support it. Despite any esoteric 
reasons why
engine A would want to implement engine B specific attributes.

>>>> 2) @ua(name, version) is not practically useful as e.g. Mozilla is 
>>>> publishing new updates pretty frequently.
>>>> I do not think that you would want to make your CSS look like 
>>>> version tracker or so.
>>> imo a lot more useful than former in complex production site 
>>> maintenance scenario (way to isolate fixes)
>>
>> What exactly is more useful?
>>
>> These:
>> @ua(mozilla, 1800) {  }
>> @ua(firefox, 2009) {  }
>> @ua(gecko, XXXX) {  }
>>
>> ? I doubt that you would want to see this in your CSS.
>>
>> This:
>>
>> @media screen and supports(flow,grid)
>> {
>>  #sidebar { left:1#; top:1#; bottom:3# }
>>  ...
>> }
>> @else
>> {
>>  #body { display: table; }
>>  ...
>> }
>>
>> is more reliable as it will not require future changes when some UA 
>> will start or stop to support some feature.
> yes, at the moment of page creation.
> i was talking about web site workarounds for particular browser 
> version bugs during maintenance phase. btw, '@else' kills css design.
Why you think @else "kills CSS design" and, say,

@media supports(flow,grid) { ... }
@media not supports(flow,grid) { ... }

is not?

-- 
Andrew Fedoniouk.
http://terrainformatica.com
Received on Thursday, 29 November 2007 18:58:23 GMT

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