Tue, 13 Nov 2012 14:58:23 -0800
Define the error handling without having two levels of grammar (and also don't have two different definitions for supports_condition).
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 Tue Nov 13 14:21:28 2012 -0800 1.2 +++ b/css3-conditional/Overview.html Tue Nov 13 14:58:23 2012 -0800 1.3 @@ -564,35 +564,11 @@ 1.4 1.5 <pre><dfn id="supports_rule">supports_rule</dfn> 1.6 : SUPPORTS_SYM S* <a 1.7 - href="#supports_condition0"><i>supports_condition</i></a> group_rule_body 1.8 + href="#supports_condition"><i>supports_condition</i></a> group_rule_body 1.9 ; 1.10 1.11 <dfn 1.12 id="supports_condition">supports_condition</dfn> 1.13 - : NOT S* general_enclosed | 1.14 - general_enclosed ( ( AND | OR ) S* general_enclosed )* 1.15 - 1.16 -<dfn 1.17 - id="general_enclosed">general_enclosed</dfn> 1.18 - : ( FUNCTION | '(' ) any+ ')' S* 1.19 -</pre> 1.20 - 1.21 - <p> The <code>any</code> token is taken from <a 1.22 - href="http://www.w3.org/TR/CSS21/syndata.html">CSS 2.1 Syntax and Basic 1.23 - Data Types</a>. 1.24 - 1.25 - <p> The above grammar is purposely very loose for forwards-compatibility 1.26 - reasons. Any ‘<code class=css>@supports</code>’ rule that does not 1.27 - parse according to the grammar above is invalid. Style sheets <strong>must 1.28 - not</strong> use such a rule and processors <strong>must</strong> ignore 1.29 - such a rule. 1.30 - 1.31 - <p> The actual processing model of ‘<code class=css>@supports</code>’ 1.32 - is predicated on a more restricted grammar, composed of functions or 1.33 - parenthesized declarations, combined together with logical combinators, as 1.34 - defined by the following productions: 1.35 - 1.36 - <pre><dfn id="supports_condition0">supports_condition</dfn> 1.37 : supports_negation | supports_conjunction | supports_disjunction | 1.38 supports_condition_in_parens 1.39 ; 1.40 @@ -600,7 +576,7 @@ 1.41 <dfn 1.42 id="supports_condition_in_parens">supports_condition_in_parens</dfn> 1.43 : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition | 1.44 - supports_function 1.45 + general_enclosed 1.46 ; 1.47 1.48 <dfn 1.49 @@ -620,22 +596,31 @@ 1.50 1.51 <dfn 1.52 id="supports_declaration_condition">supports_declaration_condition</dfn> 1.53 - : '(' S* core_declaration ')' S* 1.54 + : '(' S* declaration ')' S* 1.55 ; 1.56 1.57 <dfn 1.58 - id="supports_function">supports_function</dfn> 1.59 - : FUNCTION S* [any|unused]* ')' 1.60 - ;</pre> 1.61 + id="general_enclosed">general_enclosed</dfn> 1.62 + : ( FUNCTION | '(' ) (any|unused)* ')' S* 1.63 +</pre> 1.64 1.65 - <p>in which <code>core_declaration</code> is the production 1.66 - <code>declaration</code> in the core syntax of CSS defined in <a 1.67 - href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section 4.1.1 1.68 - (Tokenization)</a> of <a href="#CSS21" 1.69 + <p>in which <code>declaration</code>, <code>any</code>, and 1.70 + <code>unused</code> are the productions in the core syntax of CSS defined 1.71 + in <a href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section 1.72 + 4.1.1 (Tokenization)</a> of <a href="#CSS21" 1.73 rel=biblioentry>[CSS21]<!--{{!CSS21}}--></a>, and the <code>AND</code> and 1.74 <code>NOT</code> tokens are defined in the Media Queries specification <a 1.75 href="#MEDIAQ" rel=biblioentry>[MEDIAQ]<!--{{!MEDIAQ}}--></a>. 1.76 1.77 + <p> The above grammar is purposely very loose for forwards-compatibility 1.78 + reasons, since the <a 1.79 + href="#general_enclosed"><code>general_enclosed</code></a> production 1.80 + allows for substantial future extensibility. Any ‘<code 1.81 + class=css>@supports</code>’ rule that does not parse according to the 1.82 + grammar above is invalid. Style sheets <strong>must not</strong> use such 1.83 + a rule and processors <strong>must</strong> ignore such a rule (including 1.84 + all of its contents). 1.85 + 1.86 <p>Each of these grammar terms is associated with a boolean result, as 1.87 follows: 1.88 1.89 @@ -647,7 +632,7 @@ 1.90 <dt>supports_condition_in_parens 1.91 1.92 <dd> The result is the result of the single <a 1.93 - href="#supports_condition0"><code>supports_condition</code></a> or <a 1.94 + href="#supports_condition"><code>supports_condition</code></a> or <a 1.95 href="#supports_declaration_condition"><code>supports_declaration_condition</code></a> 1.96 child term. 1.97 1.98 @@ -675,21 +660,20 @@ 1.99 href="#support-definition">supports</a> the declaration within the 1.100 parentheses. 1.101 1.102 - <dt>supports_function 1.103 + <dt>general_enclosed 1.104 1.105 - <dd> The result is always false. <span class=note>Note that future levels 1.106 - may define functions that can evaluate to true.</span> 1.107 - 1.108 - <dt>anything else 1.109 - 1.110 - <dd> If a parenthesized expression does not match the result of one of the 1.111 - grammar productions above, it must not be treated as invalid, but rather 1.112 - simply be false for the purpose of support conditions. 1.113 + <dd> The result is always false. Additionally, style sheets <strong>must 1.114 + not</strong> write ‘<code class=css>@supports</code>’ rules that 1.115 + match this grammar production. (In other words, this production exists 1.116 + only for future extensibility, and is not part of the description of a 1.117 + valid style sheet in this level of the specification.) <span 1.118 + class=note>Note that future levels may define functions or other 1.119 + parenthesized expressions that can evaluate to true.</span> 1.120 </dl> 1.121 1.122 <p>The condition of the ‘<code class=css>@supports</code>’ rule is the 1.123 result of the <a 1.124 - href="#supports_condition0"><code>supports_condition</code></a> term that 1.125 + href="#supports_condition"><code>supports_condition</code></a> term that 1.126 is a child of the <a href="#supports_rule"><code>supports_rule</code></a> 1.127 term. 1.128 1.129 @@ -1215,7 +1199,7 @@ 1.130 <p> When invoked with a single <var>conditionText</var> argument, it must 1.131 return <code>true</code> if <var>conditionText</var>, when parsed and 1.132 evaluated as a <a 1.133 - href="#supports_condition0"><code>supports_condition</code></a>, would 1.134 + href="#supports_condition"><code>supports_condition</code></a>, would 1.135 return true. Otherwise, it must return <code>false</code>. 1.136 </dl> 1.137 1.138 @@ -1567,8 +1551,6 @@ 1.139 title=support><strong>6.1.</strong></a> 1.140 1.141 <li>supports_condition, <a href="#supports_condition" 1.142 - title="supports_condition"><strong>6.</strong></a>, <a 1.143 - href="#supports_condition0" 1.144 title="supports_condition"><strong>6.</strong></a> 1.145 1.146 <li>supports_condition_in_parens, <a href="#supports_condition_in_parens" 1.147 @@ -1584,9 +1566,6 @@ 1.148 <li>supports_disjunction, <a href="#supports_disjunction" 1.149 title="supports_disjunction"><strong>6.</strong></a> 1.150 1.151 - <li>supports_function, <a href="#supports_function" 1.152 - title="supports_function"><strong>6.</strong></a> 1.153 - 1.154 <li>supports_negation, <a href="#supports_negation" 1.155 title="supports_negation"><strong>6.</strong></a> 1.156
2.1 --- a/css3-conditional/Overview.src.html Tue Nov 13 14:21:28 2012 -0800 2.2 +++ b/css3-conditional/Overview.src.html Tue Nov 13 14:58:23 2012 -0800 2.3 @@ -370,35 +370,13 @@ 2.4 ; 2.5 2.6 <dfn>supports_condition</dfn> 2.7 - : NOT S* general_enclosed | 2.8 - general_enclosed ( ( AND | OR ) S* general_enclosed )* 2.9 - 2.10 -<dfn>general_enclosed</dfn> 2.11 - : ( FUNCTION | '(' ) any+ ')' S* 2.12 -</pre> 2.13 - 2.14 -<p> 2.15 - 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.16 - 2.17 -<p> 2.18 - The above grammar is purposely very loose for forwards-compatibility reasons. 2.19 - Any ''@supports'' rule that does not parse according to the grammar above is invalid. 2.20 - Style sheets <strong>must not</strong> use such a rule and processors <strong>must</strong> ignore such a rule. 2.21 - 2.22 -<p> 2.23 - The actual processing model of ''@supports'' is predicated on a more restricted grammar, 2.24 - composed of functions or parenthesized declarations, 2.25 - combined together with logical combinators, 2.26 - as defined by the following productions: 2.27 - 2.28 -<pre><dfn>supports_condition</dfn> 2.29 : supports_negation | supports_conjunction | supports_disjunction | 2.30 supports_condition_in_parens 2.31 ; 2.32 2.33 <dfn>supports_condition_in_parens</dfn> 2.34 : ( '(' S* supports_condition ')' S* ) | supports_declaration_condition | 2.35 - supports_function 2.36 + general_enclosed 2.37 ; 2.38 2.39 <dfn>supports_negation</dfn> 2.40 @@ -414,20 +392,29 @@ 2.41 ; 2.42 2.43 <dfn>supports_declaration_condition</dfn> 2.44 - : '(' S* core_declaration ')' S* 2.45 + : '(' S* declaration ')' S* 2.46 ; 2.47 2.48 -<dfn>supports_function</dfn> 2.49 - : FUNCTION S* [any|unused]* ')' 2.50 - ;</pre> 2.51 +<dfn>general_enclosed</dfn> 2.52 + : ( FUNCTION | '(' ) (any|unused)* ')' S* 2.53 +</pre> 2.54 2.55 -<p>in which <code>core_declaration</code> is the production 2.56 -<code>declaration</code> in the core syntax of CSS defined in <a 2.57 +<p>in which <code>declaration</code>, <code>any</code>, and 2.58 +<code>unused</code> are the productions in the core syntax of CSS 2.59 +defined in <a 2.60 href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section 2.61 4.1.1 (Tokenization)</a> of [[!CSS21]], 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> 2.66 + The above grammar is purposely very loose for forwards-compatibility reasons, 2.67 + since the <code>general_enclosed</code> production 2.68 + allows for substantial future extensibility. 2.69 + Any ''@supports'' rule that does not parse according to the grammar above is invalid. 2.70 + Style sheets <strong>must not</strong> use such a rule and 2.71 + processors <strong>must</strong> ignore such a rule (including all of its contents). 2.72 + 2.73 <p>Each of these grammar terms is associated with a boolean result, as 2.74 follows:</p> 2.75 <dl> 2.76 @@ -468,19 +455,19 @@ 2.77 within the parentheses. 2.78 </dd> 2.79 2.80 -<dt>supports_function</dt> 2.81 +<dt>general_enclosed</dt> 2.82 <dd> 2.83 The result is always false. 2.84 - <span class="note">Note that future levels may define functions that can evaluate to true.</span> 2.85 + Additionally, style sheets <strong>must not</strong> 2.86 + write ''@supports'' rules 2.87 + that match this grammar production. 2.88 + (In other words, this production exists only for future extensibility, 2.89 + and is not part of the description of a valid style sheet 2.90 + in this level of the specification.) 2.91 + <span class="note">Note that future levels may define functions 2.92 + or other parenthesized expressions 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 2.103 <code>supports_condition</code> term that is a child of the 2.104 <code>supports_rule</code> term.</p>