W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3-cascade] browser specific CSS

From: Glenn Linderman <v+html@g.nevcal.com>
Date: Fri, 01 Apr 2011 03:10:59 -0700
Message-ID: <4D95A4B3.2040703@g.nevcal.com>
To: Christoph Päper <christoph.paeper@crissov.de>
CC: W3C style mailing list <www-style@w3.org>
On 4/1/2011 1:28 AM, Christoph Päper wrote:
> Tab Atkins Jr.:
>> The one area where we *do* want to do something, imo, is in making CSS capable of doing feature-testing.  This has been proposed in the group before, via an @supports rule.
> I liked the ‘!required’ solution:
>
>    foo {
>      bar: plain and simple; /* fallback */
>      bar: bells and whistles !required;
>      baz: only works well with second bar !required;
>    }
>
> This hardly works across rulesets and only provides one level of fallback, but it is good enough for many use cases.

So I wasn't on the mailing list then... sorry.

I'm assuming "@supports" introduces some sort of syntax describing a 
feature or feature list, which, if the browser doesn't claim to support 
the whole list of features, disables the rule it is attached to, or all 
the rules that follow until the next }, or something?

And for the syntax above, I'll assume that !required implies that if the 
browser can't implement the feature for all the rules so marked, that it 
ignores all the rules so marked?

If my assumptions are wrong, please explain, or point me to the 
explanation.  Thanks.

If my assumptions are right, then it would seem that the above example 
is actually talking about subfeatures or extensions to preexisting 
feature syntax... because "bar:" is used twice, apparently in two forms, 
the second of which might contain syntax that is unrecognized by 
browsers that haven't implemented a particular feature?

And in any case, it seems like @supports could probably be extended with 
browser brand and version detection syntax, but !required probably 
couldn't be, usefully, because the a buggy browser still thinks it 
implements the feature, but has implemented it wrong.  So that makes me 
prefer @supports, I think.
Received on Friday, 1 April 2011 10:11:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT