- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 13 Apr 2011 11:59:36 -0700
- To: www-style@w3.org
There's been a bit of discussion over time of feature queries, particularly in these messages: http://lists.w3.org/Archives/Public/www-style/2004Dec/0084.html http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html http://lists.w3.org/Archives/Public/www-style/2009Dec/0135.html http://lists.w3.org/Archives/Public/www-style/2009Dec/0141.html http://lists.w3.org/Archives/Public/www-style/2009Dec/0144.html (though it's reasonably likely I missed a thread). I think having a capability like this in CSS is critical for the adoption of new layout systems, and also potentially quite useful for authors to help in the adoption of other new features for which it is currently difficult to design a sensible fallback. I'm particuarly interested in building something based on the @supports proposal in the second message above. But I think it needs a few additions (some of which were mentioned in the messages following that message). In particular: * Support for negation is needed (i.e., for an "else" clause). * At the very least, support is needed for "or" between non-negated declaration blocks and either negation of the conjunction or support for "and" between negated ones. Without this, queries for prefixed properties would be nearly impossible. * It needs to fit within the CSS @-rule syntax, which doesn't allow an "else" construct with two blocks within the forward-compatible syntax. (Or, if the @else was its own at-rule, it doesn't make sense logically.) I also wonder whether the idea that listing multiple declarations is implicitly "and" is clear; I think it could be confused with or. Thus I'm inclined towards something that allows: @supports ( display: flex ) { ... } @supports ( -moz-box-shadow: 2px 2px 2px black ) or ( -webkit-box-shadow: 2px 2px 2px black ) or ( -o-box-shadow: 2px 2px 2px black ) { ... } @supports not ( display: flex ) { ... } I want to avoid allowing more than one of 'not', 'and', and 'or' at the same nesting level (i.e., parentheses are required to prevent things like "a and b or c" or "not a and b") I do, however, want to allow authors to mix 'and', 'or', and 'not' terms as needed. I think the inability to do that in media queries has been painful for authors. So in other words, I'd propose the grammar for a new rule ('supports-rule' in the grammar below) which would be allowed wherever @media rules are allowed: supports-rule: '@supports' condition '{' S* ruleset* '}' S* condition: negation | conjunction | disjunction | declaration-condition negation: 'not' condition-in-parens conjunction: condition-in-parens ( 'and' condition-in-parens )+ disjunction: condition-in-parens ( 'or' condition-in-parens )+ condition-in-parens: ( '(' condition ')' ) | declaration-condition declaration-condition: '(' declaration ')' The rules for evaluating the condition in each grammar term is: condition: evaluate the single child term negation: negate the result of evaluating the single child term conjunction: true if all of the (non-'and') child terms are true, otherwise false disjunction: true if any of the (non-'or') child terms are true, otherwise false condition-in-parens: evaluate the single (non-'(' and non-')') child term declaration-condition: true if the user agent supports the declaration, otherwise false The user-agent MUST use the rulesets in an @supports if and only if that @supports rule's condition evalutes to true. Thoughts? -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Wednesday, 13 April 2011 19:00:05 UTC