Mercurial > drafts / changeset

     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>