w3c
diff --git a/‎css3-conditional/Overview.html‎
Lines changed: 18 additions & 13 deletions b/‎css3-conditional/Overview.html‎
Lines changed: 18 additions & 13 deletions
diff --git a/‎css3-conditional/Overview.src.html‎
Lines changed: 13 additions & 8 deletions
< 93CD /div> b/‎css3-conditional/Overview.src.html‎
Lines changed: 13 additions & 8 deletions
< 93CD /div>
@@ -12,11 +12,11 @@
    rel=dcterms.rights>
   <meta content="CSS Conditional Rules Module Level 3" name=dcterms.title>
   <meta content=text name=dcterms.type>
-  <meta content=2012-10-09 name=dcterms.issued>
+  <meta content=2012-10-10 name=dcterms.issued>
   <meta content="http://dev.w3.org/csswg/css3-conditional/"
    name=dcterms.creator>
   <meta content=W3C name=dcterms.publisher>
-  <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121009/"
+  <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121010/"
    name=dcterms.identifier>
   <link href="../default.css" rel=stylesheet type="text/css">
   <link href="http://www.w3.org/StyleSheets/TR/W3C-ED.css" rel=stylesheet
@@ -29,13 +29,14 @@
 
    <h1>CSS Conditional Rules Module Level 3</h1>
 
-   <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 9 October 2012</h2>
+   <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 10 October
+    2012</h2>
 
    <dl>
     <dt>This version:
 
-    <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121009/">
-     http://www.w3.org/TR/2012/ED-css3-conditional-20121009/</a>
+    <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121010/">
+     http://www.w3.org/TR/2012/ED-css3-conditional-20121010/</a>
 
     <dt>Latest version:
 
@@ -163,6 +164,9 @@ <h2 class="no-num no-toc" id=status>Status of this document</h2>
     interoperable implementations are not found, it may be removed to advance
     the other features in this specification to Proposed Recommendation.
 
+   <li>The support for functions inside of ‘<code
+    class=css>@supports</code>’ is at risk.
+
    <li>The ‘<code class=css>@document</code>’ rule is at risk; if
     interoperable implementations are not found, it may be removed to advance
     the other features in this specification to Proposed Recommendation.
@@ -613,7 +617,7 @@ <h2 id=at-supports><span class=secno>6. </span>Feature queries: the
 
 <dfn
    id="supports_declaration_condition">supports_declaration_condition</dfn>
-  : '(' S* core_declaration ')' S*
+  : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')'
   ;</pre>
 
   <p>in which <code>core_declaration</code> is the production
@@ -636,12 +640,6 @@ <h2 id=at-supports><span class=secno>6. </span>Feature queries: the
    declarations cause the entire ‘<code class=css>@supports</code>’ 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 ‘<code class=css>@supports</code>’ 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:
 
@@ -678,7 +676,7 @@ <h2 id=at-supports><span class=secno>6. </span>Feature queries: the
    <dt>supports_declaration_condition
 
    <dd> The result is whether the CSS processor <a
-    href="#support-definition">supports</a> the declaration.
+    href="#support-definition">supports</a> the declaration or function.
   </dl>
 
   <p>The condition of the ‘<code class=css>@supports</code>’ rule is the
@@ -838,6 +836,13 @@ <h3 id=support-definition><span class=secno>6.1. </span>Definition of
    it <strong>must not</strong> accept the declaration or claim support for
    it.
 
+  <p>A CSS processor is considered to <a
+   href="#dfn-support"><i>support</i></a> a function (consisting of a
+   function name and arguments) if it accepts that function (rather than
+   discarding it as a parse error). If a processor does not implement, with a
+   usable level of support, the value given, then it <strong>must
+   not</strong> accept the function or claim support for it.
+
   <p>These rules (and the equivalence between them) allow authors to use
    fallback (either in the <a href="#CSS1"
    rel=biblioentry>[CSS1]<!--{{CSS1}}--></a> sense of declarations that are
 
@@ -90,6 +90,8 @@ <h2 class="no-num no-toc" id="status">Status of this document</h2>
   implementations are not found, it may be removed to advance the other
   features in this specification to Proposed Recommendation.</li>
 
+  <li>The support for functions inside of ''@supports'' is at risk.</li>
+
   <li>The '@document' rule is at risk; if interoperable
   implementations are not found, it may be removed to advance the other
   features in this specification to Proposed Recommendation.</li>
@@ -399,7 +401,7 @@ <h2 id="at-supports">Feature queries: the '@supports' rule</h2>
   ;
 
 <dfn>supports_declaration_condition</dfn>
-  : '(' S* core_declaration ')' S*
+  : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')'
   ;</pre>
 <p>in which <code>core_declaration</code> is the production
 <code>declaration</code> in the core syntax of CSS defined in <a
@@ -418,12 +420,6 @@ <h2 id="at-supports">Feature queries: the '@supports' rule</h2>
 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>
 <dl>
@@ -461,7 +457,7 @@ <h2 id="at-supports">Feature queries: the '@supports' rule</h2>
 <dt>supports_declaration_condition</dt>
 <dd>
   The result is whether the CSS processor <a
-  href="#support-definition">supports</a> the declaration.
+  href="#support-definition">supports</a> the declaration or function.
 </dd>
 </dl>
 
@@ -598,6 +594,15 @@ <h3 id="support-definition">Definition of support</h3>
 then it <strong>must not</strong>
 accept the declaration or claim support for it.</p>
 
+<p>A CSS processor is considered to <i>support</i> a function 
+(consisting of a function name and arguments)
+if it accepts that function
+(rather than discarding it as a parse error).
+If a processor does not implement, with a usable level of support,
+the value given,
+then it <strong>must not</strong>
+accept the function or claim support for it.</p>
+
 <p>These rules (and the equivalence between them) allow
 authors to use fallback (either in the [[CSS1]] sense of declarations
 that are overridden by later declarations or with the new capabilities