changeset
[css3-conditional] Rewrite the invalid syntax rules for @supports
Tue, 30 Oct 2012 14:38:57 +0100
- author
- Tab Atkins <jackalmage@gmail.com>
- date
- Tue, 30 Oct 2012 14:38:57 +0100
- changeset 6943
- d4c52c4a5501
- parent 6942
- bd4a4bc0d9f3
- child 6944
- dbbb123f2fdd
[css3-conditional] Rewrite the invalid syntax rules for @supports
| css3-conditional/Overview.html | file | annotate | diff | comparison | revisions | |
| css3-conditional/Overview.src.html | file | annotate | diff | comparison | revisions |
1.1 --- a/css3-conditional/Overview.html Mon Oct 29 12:46:50 2012 +0100 1.2 +++ b/css3-conditional/Overview.html Tue Oct 30 14:38:57 2012 +0100 1.3 @@ -12,17 +12,18 @@ 1.4 rel=dcterms.rights> 1.5 <meta content="CSS Conditional Rules Module Level 3" name=dcterms.title> 1.6 <meta content=text name=dcterms.type> 1.7 - <meta content=2012-10-12 name=dcterms.issued> 1.8 + <meta content=2012-10-30 name=dcterms.issued> 1.9 <meta content="http://dev.w3.org/csswg/css3-conditional/" 1.10 name=dcterms.creator> 1.11 <meta content=W3C name=dcterms.publisher> 1.12 - <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121012/" 1.13 + <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121030/" 1.14 name=dcterms.identifier> 1.15 <link href="../default.css" rel=stylesheet type="text/css"> 1.16 <link href="http://www.w3.org/StyleSheets/TR/W3C-ED.css" rel=stylesheet 1.17 type="text/css"> 1.18 - <script src="http://test.csswg.org/harness/annotate.js#CSS3-CONDITIONAL_DEV" 1.19 - type="text/javascript" defer></script> 1.20 + <script defer=defer 1.21 + src="http://test.csswg.org/harness/annotate.js#CSS3-CONDITIONAL_DEV" 1.22 + type="text/javascript"></script> 1.23 1.24 <body> 1.25 <div class=head> <!--begin-logo--> 1.26 @@ -31,14 +32,14 @@ 1.27 1.28 <h1>CSS Conditional Rules Module Level 3</h1> 1.29 1.30 - <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 12 October 1.31 + <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 30 October 1.32 2012</h2> 1.33 1.34 <dl> 1.35 <dt>This version: 1.36 1.37 - <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121012/"> 1.38 - http://www.w3.org/TR/2012/ED-css3-conditional-20121012/</a> 1.39 + <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121030/"> 1.40 + http://www.w3.org/TR/2012/ED-css3-conditional-20121030/</a> 1.41 1.42 <dt>Latest version: 1.43 1.44 @@ -562,18 +563,40 @@ 1.45 <p>and the grammar by adding 1.46 1.47 <pre><dfn id="supports_rule">supports_rule</dfn> 1.48 - : SUPPORTS_SYM S* supports_condition group_rule_body 1.49 + : SUPPORTS_SYM S* <a 1.50 + href="#supports_condition0"><i>supports_condition</i></a> group_rule_body 1.51 ; 1.52 1.53 <dfn 1.54 id="supports_condition">supports_condition</dfn> 1.55 + : NOT S* '(' any+ ')' S* | 1.56 + '(' any+ ')' S* ( ( AND | OR ) S* any+ )* 1.57 +</pre> 1.58 + 1.59 + <p> The <code>any</code> token is taken from <a 1.60 + href="http://www.w3.org/TR/CSS21/syndata.html">CSS 2.1 Syntax and Basic 1.61 + Data Types</a>. 1.62 + 1.63 + <p> The above grammar is purposely very loose for forwards-compatibility 1.64 + reasons. Any ‘<code class=css>@supports</code>’ rule that does not 1.65 + parse according to the grammar above is invalid. Style sheets <strong>must 1.66 + not</strong> use such a rule and processors <strong>must</strong> ignore 1.67 + such a rule. 1.68 + 1.69 + <p> The actual processing model of ‘<code class=css>@supports</code>’ 1.70 + is predicated on a more restricted grammar, composed of functions or 1.71 + parenthesized declarations, combined together with logical combinators, as 1.72 + defined by these grammars: 1.73 + 1.74 + <pre><dfn id="supports_condition0">supports_condition</dfn> 1.75 : supports_negation | supports_conjunction | supports_disjunction | 1.76 supports_condition_in_parens 1.77 ; 1.78 1.79 <dfn 1.80 id="supports_condition_in_parens">supports_condition_in_parens</dfn> 1.81 - : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition 1.82 + : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition | 1.83 + supports_function 1.84 ; 1.85 1.86 <dfn 1.87 @@ -593,7 +616,12 @@ 1.88 1.89 <dfn 1.90 id="supports_declaration_condition">supports_declaration_condition</dfn> 1.91 - : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')' 1.92 + : '(' S* core_declaration ')' S* 1.93 + ; 1.94 + 1.95 +<dfn 1.96 + id="supports_function">supports_function</dfn> 1.97 + : FUNCTION S* [any|unused]* ')' 1.98 ;</pre> 1.99 1.100 <p>in which <code>core_declaration</code> is the production 1.101 @@ -604,18 +632,6 @@ 1.102 <code>NOT</code> tokens are defined in the Media Queries specification <a 1.103 href="#MEDIAQ" rel=biblioentry>[MEDIAQ]<!--{{!MEDIAQ}}--></a>. 1.104 1.105 - <p>Any ‘<code class=css>@supports</code>’ rule that does not parse 1.106 - according to the grammar above is invalid. Style sheets <strong>must 1.107 - not</strong> use such a rule and processors <strong>must</strong> ignore 1.108 - such a rule. 1.109 - 1.110 - <p class=note>Note that this means that declarations that meet the 1.111 - forward-compatible syntax for declarations are permitted (and support for 1.112 - them is then tested by the ‘<code class=css>@supports</code>’ rule), 1.113 - but declarations that do not meet the forward-compatible syntax for 1.114 - declarations cause the entire ‘<code class=css>@supports</code>’ rule 1.115 - to be ignored. 1.116 - 1.117 <p>Each of these grammar terms is associated with a boolean result, as 1.118 follows: 1.119 1.120 @@ -627,7 +643,7 @@ 1.121 <dt>supports_condition_in_parens 1.122 1.123 <dd> The result is the result of the single <a 1.124 - href="#supports_condition"><code>supports_condition</code></a> or <a 1.125 + href="#supports_condition0"><code>supports_condition</code></a> or <a 1.126 href="#supports_declaration_condition"><code>supports_declaration_condition</code></a> 1.127 child term. 1.128 1.129 @@ -651,16 +667,25 @@ 1.130 1.131 <dt>supports_declaration_condition 1.132 1.133 - <dd> The result is false if this corresponds to a functional notation; 1.134 - otherwise, the result is whether the CSS processor <a 1.135 + <dd> The result is whether the CSS processor <a 1.136 href="#support-definition">supports</a> the declaration within the 1.137 - parentheses. <span class=note>Note that future levels may define 1.138 - functions that can evaluate to true.</span> 1.139 + parentheses. 1.140 + 1.141 + <dt>supports_function 1.142 + 1.143 + <dd> The result is always false. <span class=note>Note that future levels 1.144 + may define functions that can evaluate to true.</span> 1.145 + 1.146 + <dt>anything else 1.147 + 1.148 + <dd> If a parenthesized expression does not match the result of one of the 1.149 + grammar productions above, it must not be treated as invalid, but rather 1.150 + simply be false for the purpose of support conditions. 1.151 </dl> 1.152 1.153 <p>The condition of the ‘<code class=css>@supports</code>’ rule is the 1.154 result of the <a 1.155 - href="#supports_condition"><code>supports_condition</code></a> term that 1.156 + href="#supports_condition0"><code>supports_condition</code></a> term that 1.157 is a child of the <a href="#supports_rule"><code>supports_rule</code></a> 1.158 term. 1.159 1.160 @@ -1186,7 +1211,7 @@ 1.161 <p> When invoked with a single <var>conditionText</var> argument, it must 1.162 return <code>true</code> if <var>conditionText</var>, when parsed and 1.163 evaluated as a <a 1.164 - href="#supports_condition"><code>supports_condition</code></a>, would 1.165 + href="#supports_condition0"><code>supports_condition</code></a>, would 1.166 return true. Otherwise, it must return <code>false</code>. 1.167 </dl> 1.168 1.169 @@ -1535,6 +1560,8 @@ 1.170 title=support><strong>6.1.</strong></a> 1.171 1.172 <li>supports_condition, <a href="#supports_condition" 1.173 + title="supports_condition"><strong>6.</strong></a>, <a 1.174 + href="#supports_condition0" 1.175 title="supports_condition"><strong>6.</strong></a> 1.176 1.177 <li>supports_condition_in_parens, <a href="#supports_condition_in_parens" 1.178 @@ -1550,6 +1577,9 @@ 1.179 <li>supports_disjunction, <a href="#supports_disjunction" 1.180 title="supports_disjunction"><strong>6.</strong></a> 1.181 1.182 + <li>supports_function, <a href="#supports_function" 1.183 + title="supports_function"><strong>6.</strong></a> 1.184 + 1.185 <li>supports_negation, <a href="#supports_negation" 1.186 title="supports_negation"><strong>6.</strong></a> 1.187
2.1 --- a/css3-conditional/Overview.src.html Mon Oct 29 12:46:50 2012 +0100 2.2 +++ b/css3-conditional/Overview.src.html Tue Oct 30 14:38:57 2012 +0100 2.3 @@ -362,18 +362,40 @@ 2.4 @{S}{U}{P}{P}{O}{R}{T}{S} {return SUPPORTS_SYM;} 2.5 {O}{R} {return OR;} 2.6 </pre> 2.7 + 2.8 <p>and the grammar by adding</p> 2.9 + 2.10 <pre><dfn>supports_rule</dfn> 2.11 - : SUPPORTS_SYM S* supports_condition group_rule_body 2.12 + : SUPPORTS_SYM S* <i>supports_condition</i> group_rule_body 2.13 ; 2.14 2.15 <dfn>supports_condition</dfn> 2.16 + : NOT S* '(' any+ ')' S* | 2.17 + '(' any+ ')' S* ( ( AND | OR ) S* any+ )* 2.18 +</pre> 2.19 + 2.20 +<p> 2.21 + The <code>any</code> token is taken from <a href="http://www.w3.org/TR/CSS21/syndata.html">CSS 2.1 Syntax and Basic Data Types</a>. 2.22 + 2.23 +<p> 2.24 + The above grammar is purposely very loose for forwards-compatibility reasons. 2.25 + Any ''@supports'' rule that does not parse according to the grammar above is invalid. 2.26 + Style sheets <strong>must not</strong> use such a rule and processors <strong>must</strong> ignore such a rule. 2.27 + 2.28 +<p> 2.29 + The actual processing model of ''@supports'' is predicated on a more restricted grammar, 2.30 + composed of functions or parenthesized declarations, 2.31 + combined together with logical combinators, 2.32 + as defined by these grammars: 2.33 + 2.34 +<pre><dfn>supports_condition</dfn> 2.35 : supports_negation | supports_conjunction | supports_disjunction | 2.36 supports_condition_in_parens 2.37 ; 2.38 2.39 <dfn>supports_condition_in_parens</dfn> 2.40 - : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition 2.41 + : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition | 2.42 + supports_function 2.43 ; 2.44 2.45 <dfn>supports_negation</dfn> 2.46 @@ -389,8 +411,13 @@ 2.47 ; 2.48 2.49 <dfn>supports_declaration_condition</dfn> 2.50 - : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')' 2.51 + : '(' S* core_declaration ')' S* 2.52 + ; 2.53 + 2.54 +<dfn>supports_function</dfn> 2.55 + : FUNCTION S* [any|unused]* ')' 2.56 ;</pre> 2.57 + 2.58 <p>in which <code>core_declaration</code> is the production 2.59 <code>declaration</code> in the core syntax of CSS defined in <a 2.60 href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section 2.61 @@ -398,16 +425,6 @@ 2.62 and the <code>AND</code> and <code>NOT</code> tokens are defined in 2.63 the Media Queries specification [[!MEDIAQ]].</p> 2.64 2.65 -<p>Any ''@supports'' rule that does not parse according to the grammar 2.66 -above is invalid. Style sheets <strong>must not</strong> use such a 2.67 -rule and processors <strong>must</strong> ignore such a rule.</p> 2.68 - 2.69 -<p class="note">Note that this means that declarations that meet the 2.70 -forward-compatible syntax for declarations are permitted (and support 2.71 -for them is then tested by the ''@supports'' rule), but declarations 2.72 -that do not meet the forward-compatible syntax for declarations cause 2.73 -the entire ''@supports'' rule to be ignored.</p> 2.74 - 2.75 <p>Each of these grammar terms is associated with a boolean result, as 2.76 follows:</p> 2.77 <dl> 2.78 @@ -444,12 +461,21 @@ 2.79 2.80 <dt>supports_declaration_condition</dt> 2.81 <dd> 2.82 - The result is false if this corresponds to a functional notation; 2.83 - otherwise, the result is whether the CSS processor <a 2.84 - href="#support-definition">supports</a> the declaration 2.85 + The result is whether the CSS processor <a href="#support-definition">supports</a> the declaration 2.86 within the parentheses. 2.87 +</dd> 2.88 + 2.89 +<dt>supports_function</dt> 2.90 +<dd> 2.91 + The result is always false. 2.92 <span class="note">Note that future levels may define functions that can evaluate to true.</span> 2.93 </dd> 2.94 + 2.95 +<dt>anything else</dt> 2.96 +<dd> 2.97 + If a parenthesized expression does not match the result of one of the grammar productions above, 2.98 + it must not be treated as invalid, 2.99 + but rather simply be false for the purpose of support conditions. 2.100 </dl> 2.101 2.102 <p>The condition of the '@supports' rule is the result of the
