- From: Glenn Linderman <v+html@g.nevcal.com>
- Date: Fri, 01 Apr 2011 03:10:59 -0700
- To: Christoph Päper <christoph.paeper@crissov.de>
- CC: W3C style mailing list <www-style@w3.org>
- Message-ID: <4D95A4B3.2040703@g.nevcal.com>
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 UTC