- From: Benjamin D. Smedberg <bsmedberg@covad.net>
- Date: Fri, 17 Sep 2004 14:33:27 -0400
- 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. --BDS
Received on Friday, 17 September 2004 18:33:32 UTC