1.1 --- a/css3-conditional/Overview.src.html Tue Oct 09 17:10:25 2012 -0700 1.2 +++ b/css3-conditional/Overview.src.html Tue Oct 09 17:30:03 2012 -0700 1.3 @@ -90,6 +90,8 @@ 1.4 implementations are not found, it may be removed to advance the other 1.5 features in this specification to Proposed Recommendation.</li> 1.6 1.7 + <li>The support for functions inside of ''@supports'' is at risk.</li> 1.8 + 1.9 <li>The '@document' rule is at risk; if interoperable 1.10 implementations are not found, it may be removed to advance the other 1.11 features in this specification to Proposed Recommendation.</li> 1.12 @@ -399,7 +401,7 @@ 1.13 ; 1.14 1.15 <dfn>supports_declaration_condition</dfn> 1.16 - : '(' S* core_declaration ')' S* 1.17 + : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')' 1.18 ;</pre> 1.19 <p>in which <code>core_declaration</code> is the production 1.20 <code>declaration</code> in the core syntax of CSS defined in <a 1.21 @@ -418,12 +420,6 @@ 1.22 that do not meet the forward-compatible syntax for declarations cause 1.23 the entire ''@supports'' rule to be ignored.</p> 1.24 1.25 -<p class="issue">Is any further allowance for forward-compatible parsing 1.26 -needed, for example, to allow additional features (such as, say, 1.27 -selector tests) to be added to the ''@supports'' rule? Or are these 1.28 -forward-compatible parsing rules the best solution for such future 1.29 -expansion anyway?</p> 1.30 - 1.31 <p>Each of these grammar terms is associated with a boolean result, as 1.32 follows:</p> 1.33 <dl> 1.34 @@ -461,7 +457,7 @@ 1.35 <dt>supports_declaration_condition</dt> 1.36 <dd> 1.37 The result is whether the CSS processor <a 1.38 - href="#support-definition">supports</a> the declaration. 1.39 + href="#support-definition">supports</a> the declaration or function. 1.40 </dd> 1.41 </dl> 1.42 1.43 @@ -598,6 +594,15 @@ 1.44 then it <strong>must not</strong> 1.45 accept the declaration or claim support for it.</p> 1.46 1.47 +<p>A CSS processor is considered to <i>support</i> a function 1.48 +(consisting of a function name and arguments) 1.49 +if it accepts that function 1.50 +(rather than discarding it as a parse error). 1.51 +If a processor does not implement, with a usable level of support, 1.52 +the value given, 1.53 +then it <strong>must not</strong> 1.54 +accept the function or claim support for it.</p> 1.55 + 1.56 <p>These rules (and the equivalence between them) allow 1.57 authors to use fallback (either in the [[CSS1]] sense of declarations 1.58 that are overridden by later declarations or with the new capabilities