csswg/css3-conditional Overview.html,1.18,1.19 Overview.src.html,1.18,1.19

Update of /sources/public/csswg/css3-conditional
In directory hutz:/tmp/cvs-serv4827

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

Index: Overview.html
===================================================================
RCS file: /sources/public/csswg/css3-conditional/Overview.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- Overview.html	14 Jun 2011 01:25:10 -0000	1.18
+++ Overview.html	14 Jun 2011 02:13:48 -0000	1.19
@@ -569,9 +569,33 @@
   ;
 
 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:
 

Index: Overview.src.html
===================================================================
RCS file: /sources/public/csswg/css3-conditional/Overview.src.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- Overview.src.html	14 Jun 2011 01:25:11 -0000	1.18
+++ Overview.src.html	14 Jun 2011 02:13:48 -0000	1.19
@@ -385,8 +385,28 @@
   ;
 
 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>

Received on Tuesday, 14 June 2011 02:13:51 UTC