Define parsing of @supports better to address Björn's comment in http://lists.w3.org/Archives/Public/www-style/2011Apr/0439.html

Author: dbaron

css3-conditional/Overview.html

@@ -569,9 +569,33 @@ <h2 id=at-supports><span class=secno>6. </span>Feature queries: the
   ;
 
 supports_declaration_condition
-  : '(' S* declaration ')' S*
+  : '(' S* core_declaration ')' S*
   ;</pre>
 
+  <p>in which <code>core_declaration</code> is the production
+   <code>declaration</code> in the core syntax of CSS defined in <a
+   href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section 4.1.1
+   (Tokenization)</a> of <a href="#CSS21"
+   rel=biblioentry>[CSS21]<!--{{!CSS21}}--></a>.
+
+  <p>Any &lsquo;<code class=css>@supports</code>&rsquo; rule that does not
+   parse according to the grammar above is invalid. Style sheets <strong>must
+   not</strong> use such a rule and processors <strong>must</strong> ignore
+   such a rule.
+
+  <p class=note>Note that this means that declarations that meet the
+   forward-compatible syntax for declarations are permitted (and support for
+   them is then tested by the &lsquo;<code class=css>@supports</code>&rsquo;
+   rule), but declarations that do not meet the forward-compatible syntax for
+   declarations cause the entire &lsquo;<code
+   class=css>@supports</code>&rsquo; rule to be ignored.
+
+  <p class=issue>Is any further allowance for forward-compatible parsing
+   needed, for example, to allow additional features (such as, say, selector
+   tests) to be added to the &lsquo;<code class=css>@supports</code>&rsquo;
+   rule? Or are these forward-compatible parsing rules the best solution for
+   such future expansion anyway?
+
   <p>Each of these grammar terms is associated with a boolean result, as
    follows:
 

css3-conditional/Overview.src.html

@@ -385,8 +385,28 @@ <h2 id="at-supports">Feature queries: the '@supports' rule</h2>
   ;
 
 supports_declaration_condition
-  : '(' S* declaration ')' S*
+  : '(' S* core_declaration ')' S*
   ;</pre>
+<p>in which <code>core_declaration</code> is the production
+<code>declaration</code> in the core syntax of CSS defined in <a
+href="http://www.w3.org/TR/CSS21/syndata.html#tokenization">section
+4.1.1 (Tokenization)</a> of [[!CSS21]].</p>
+
+<p>Any ''@supports'' rule that does not parse according to the grammar
+above is invalid.  Style sheets <strong>must not</strong> use such a
+rule and processors <strong>must</strong> ignore such a rule.</p>
+
+<p class="note">Note that this means that declarations that meet the
+forward-compatible syntax for declarations are permitted (and support
+for them is then tested by the ''@supports'' rule), but declarations
+that do not meet the forward-compatible syntax for declarations cause
+the entire ''@supports'' rule to be ignored.</p>
+
+<p class="issue">Is any further allowance for forward-compatible parsing
+needed, for example, to allow additional features (such as, say,
+selector tests) to be added to the ''@supports'' rule?  Or are these
+forward-compatible parsing rules the best solution for such future
+expansion anyway?</p>
 
 <p>Each of these grammar terms is associated with a boolean result, as
 follows:</p>