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

Re: More controlled degrading, @supported at-rule

From: Benjamin D. Smedberg <bsmedberg@covad.net>
Date: Fri, 17 Sep 2004 14:33:27 -0400
Message-ID: <414B2DF7.6090604@covad.net>
To: David Woolley <david@djwhome.demon.co.uk>
CC: www-style@w3.org

David Woolley wrote:
>>remarkably well. However, when you start combining multiple properties 
>>to do complex layout, or use some of the advanced features of CSS3 such 
>>as opacity and columns, it may be that CSS does not degrade nearly so 
>>gracefully. I would like to propose an simple extension to CSS that 
> Variations on this are proposed about every six months; you need to 
> look at the archive.

Sure, but there was never a spec or a decision, as far as I can tell. I 
saw one reference to a @supports at-rule, in passing, and several other 
random mentions of multi-property compatibility testing. The best 
argument against such a spec has been "it's not needed", but I think 
that I have demonstrated the opposite, if designers are going to make 
backwards-compatible use of CSS3 opacity and multi-column layout options.

> As others have pointed out, your variation relies on browsers accurately
> describing their capabilities, but marketing departments will always 
> interpret compliance very liberally and will normally give an extremely
> low priority to fixing a mis-reporting of capabilities, where there
> was a genuine mistake.

I am quite aware that this relies on UAs to describe themself reasonably 
accurately. The DOM specs do the same thing with DOMImplementation. What 
incentive would marketing folk have to influence the results of this 
rule? It doesn't *provide* support for any feature, so it doesn't 
actually help them, as far as I can tell.

There was also discussion about how this might interact with overriding 
user stylesheets. I think we should ignore any overriding styles. The 
results of the at-rule should not depend on the context in which they 
are parsed, otherwise the rule can no longer be implemented solely in 
the parser, but must be implemented with some sort of dynamic style 
resolution, and you have gone from a small-and-simple spec to something 
large and error-prone.

Received on Friday, 17 September 2004 18:33:32 UTC

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