Mercurial > drafts / changeset

     1.1 --- a/css3-conditional/Overview.html	Tue Oct 09 17:10:25 2012 -0700
     1.2 +++ b/css3-conditional/Overview.html	Tue Oct 09 17:30:03 2012 -0700
     1.3 @@ -12,11 +12,11 @@
     1.4     rel=dcterms.rights>
     1.5    <meta content="CSS Conditional Rules Module Level 3" name=dcterms.title>
     1.6    <meta content=text name=dcterms.type>
     1.7 -  <meta content=2012-10-09 name=dcterms.issued>
     1.8 +  <meta content=2012-10-10 name=dcterms.issued>
     1.9    <meta content="http://dev.w3.org/csswg/css3-conditional/"
    1.10     name=dcterms.creator>
    1.11    <meta content=W3C name=dcterms.publisher>
    1.12 -  <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121009/"
    1.13 +  <meta content="http://www.w3.org/TR/2012/ED-css3-conditional-20121010/"
    1.14     name=dcterms.identifier>
    1.15    <link href="../default.css" rel=stylesheet type="text/css">
    1.16    <link href="http://www.w3.org/StyleSheets/TR/W3C-ED.css" rel=stylesheet
    1.17 @@ -29,13 +29,14 @@
    1.18  
    1.19     <h1>CSS Conditional Rules Module Level 3</h1>
    1.20  
    1.21 -   <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 9 October 2012</h2>
    1.22 +   <h2 class="no-num no-toc" id=longstatus-date>Editor's Draft 10 October
    1.23 +    2012</h2>
    1.24  
    1.25     <dl>
    1.26      <dt>This version:
    1.27  
    1.28 -    <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121009/">
    1.29 -     http://www.w3.org/TR/2012/ED-css3-conditional-20121009/</a>
    1.30 +    <dd><a href="http://www.w3.org/TR/2012/ED-css3-conditional-20121010/">
    1.31 +     http://www.w3.org/TR/2012/ED-css3-conditional-20121010/</a>
    1.32  
    1.33      <dt>Latest version:
    1.34  
    1.35 @@ -163,6 +164,9 @@
    1.36      interoperable implementations are not found, it may be removed to advance
    1.37      the other features in this specification to Proposed Recommendation.
    1.38  
    1.39 +   <li>The support for functions inside of ‘<code
    1.40 +    class=css>@supports</code>’ is at risk.
    1.41 +
    1.42     <li>The ‘<code class=css>@document</code>’ rule is at risk; if
    1.43      interoperable implementations are not found, it may be removed to advance
    1.44      the other features in this specification to Proposed Recommendation.
    1.45 @@ -613,7 +617,7 @@
    1.46  
    1.47  <dfn
    1.48     id="supports_declaration_condition">supports_declaration_condition</dfn>
    1.49 -  : '(' S* core_declaration ')' S*
    1.50 +  : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')'
    1.51    ;</pre>
    1.52  
    1.53    <p>in which <code>core_declaration</code> is the production
    1.54 @@ -636,12 +640,6 @@
    1.55     declarations cause the entire ‘<code class=css>@supports</code>’ rule
    1.56     to be ignored.
    1.57  
    1.58 -  <p class=issue>Is any further allowance for forward-compatible parsing
    1.59 -   needed, for example, to allow additional features (such as, say, selector
    1.60 -   tests) to be added to the ‘<code class=css>@supports</code>’ rule? Or
    1.61 -   are these forward-compatible parsing rules the best solution for such
    1.62 -   future expansion anyway?
    1.63 -
    1.64    <p>Each of these grammar terms is associated with a boolean result, as
    1.65     follows:
    1.66  
    1.67 @@ -678,7 +676,7 @@
    1.68     <dt>supports_declaration_condition
    1.69  
    1.70     <dd> The result is whether the CSS processor <a
    1.71 -    href="#support-definition">supports</a> the declaration.
    1.72 +    href="#support-definition">supports</a> the declaration or function.
    1.73    </dl>
    1.74  
    1.75    <p>The condition of the ‘<code class=css>@supports</code>’ rule is the
    1.76 @@ -838,6 +836,13 @@
    1.77     it <strong>must not</strong> accept the declaration or claim support for
    1.78     it.
    1.79  
    1.80 +  <p>A CSS processor is considered to <a
    1.81 +   href="#dfn-support"><i>support</i></a> a function (consisting of a
    1.82 +   function name and arguments) if it accepts that function (rather than
    1.83 +   discarding it as a parse error). If a processor does not implement, with a
    1.84 +   usable level of support, the value given, then it <strong>must
    1.85 +   not</strong> accept the function or claim support for it.
    1.86 +
    1.87    <p>These rules (and the equivalence between them) allow authors to use
    1.88     fallback (either in the <a href="#CSS1"
    1.89     rel=biblioentry>[CSS1]<!--{{CSS1}}--></a> sense of declarations that are

     2.1 --- a/css3-conditional/Overview.src.html	Tue Oct 09 17:10:25 2012 -0700
     2.2 +++ b/css3-conditional/Overview.src.html	Tue Oct 09 17:30:03 2012 -0700
     2.3 @@ -90,6 +90,8 @@
     2.4    implementations are not found, it may be removed to advance the other
     2.5    features in this specification to Proposed Recommendation.</li>
     2.6  
     2.7 +  <li>The support for functions inside of ''@supports'' is at risk.</li>
     2.8 +
     2.9    <li>The '@document' rule is at risk; if interoperable
    2.10    implementations are not found, it may be removed to advance the other
    2.11    features in this specification to Proposed Recommendation.</li>
    2.12 @@ -399,7 +401,7 @@
    2.13    ;
    2.14  
    2.15  <dfn>supports_declaration_condition</dfn>
    2.16 -  : '(' S* core_declaration ')' S*
    2.17 +  : '(' S* core_declaration ')' S* | FUNCTION S* [any|unused]* ')'
    2.18    ;</pre>
    2.19  <p>in which <code>core_declaration</code> is the production
    2.20  <code>declaration</code> in the core syntax of CSS defined in <a
    2.21 @@ -418,12 +420,6 @@
    2.22  that do not meet the forward-compatible syntax for declarations cause
    2.23  the entire ''@supports'' rule to be ignored.</p>
    2.24  
    2.25 -<p class="issue">Is any further allowance for forward-compatible parsing
    2.26 -needed, for example, to allow additional features (such as, say,
    2.27 -selector tests) to be added to the ''@supports'' rule?  Or are these
    2.28 -forward-compatible parsing rules the best solution for such future
    2.29 -expansion anyway?</p>
    2.30 -
    2.31  <p>Each of these grammar terms is associated with a boolean result, as
    2.32  follows:</p>
    2.33  <dl>
    2.34 @@ -461,7 +457,7 @@
    2.35  <dt>supports_declaration_condition</dt>
    2.36  <dd>
    2.37    The result is whether the CSS processor <a
    2.38 -  href="#support-definition">supports</a> the declaration.
    2.39 +  href="#support-definition">supports</a> the declaration or function.
    2.40  </dd>
    2.41  </dl>
    2.42  
    2.43 @@ -598,6 +594,15 @@
    2.44  then it <strong>must not</strong>
    2.45  accept the declaration or claim support for it.</p>
    2.46  
    2.47 +<p>A CSS processor is considered to <i>support</i> a function 
    2.48 +(consisting of a function name and arguments)
    2.49 +if it accepts that function
    2.50 +(rather than discarding it as a parse error).
    2.51 +If a processor does not implement, with a usable level of support,
    2.52 +the value given,
    2.53 +then it <strong>must not</strong>
    2.54 +accept the function or claim support for it.</p>
    2.55 +
    2.56  <p>These rules (and the equivalence between them) allow
    2.57  authors to use fallback (either in the [[CSS1]] sense of declarations
    2.58  that are overridden by later declarations or with the new capabilities