W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css-variables] Slight tweak to value space of CSS variables

From: Simon Sapin <simon.sapin@exyr.org>
Date: Wed, 22 May 2013 13:38:30 +0800
Message-ID: <519C59D6.8040805@exyr.org>
To: www-style@w3.org
Le 22/05/2013 13:07, L. David Baron a écrit :
> On Tuesday 2013-02-05 20:00 -0700, L. David Baron wrote:
>> Currently the value space of CSS variables is the "value" production
>> in the CSS 2.1 grammar, as specified here:
>> http://dev.w3.org/csswg/css-variables/#defining-variables
>> and defined here:
>> http://www.w3.org/TR/CSS21/syndata.html#tokenization
>> One detail that bothers me is that this production allows the CDO
>> and CDC tokens *inside* of (), [], or {}, but does not allow them at
>> the top level of the value.
>> I think we should change this, and change the value space of
>> variables from:
>>    value
>> to
>>    [ value | CDO S* | CDC S* ]+
> In a discussion with Simon Sapin, I realized my analysis above was
> slightly wrong.  There's one other case that's not permitted but
> that I believe should be permitted -- though I believe it's probably
> a bug in the CSS 2.1 general grammar.
> In particular, this production:
>    block       : '{' S* [ any | block | ATKEYWORD S* | ';' S* ]* '}' S*;
> in http://www.w3.org/TR/CSS21/syndata.html#tokenization does not
> allow CDO and CDC to be directly inside of a {} pair (like they can
> be inside of a () or [] pair, as part of the unused production).
> I think variables should, for simplicity of parsing, allow CDO and
> CDC directly inside any {} pair.  And in general I still believe in
> my general description of what should be allowed that I gave in
> http://lists.w3.org/Archives/Public/www-style/2012May/1104.html
> (as modified by the correction to the spec that resulted from the
> message quoted above, i.e.,
> http://lists.w3.org/Archives/Public/www-style/2013Feb/0196.html ).

I’d be fine with a note that says exactly what is *not* allowed. 
Something like this, although of course the list could be tweaked:

     A custom property declaration is ignored if it contains a <i>bad 
token</i>. A <dfn>bad token</dfn> is a BAD_STRING token, BAD_URL token, 
BAD_COMMENT token[1], unmatched '}' token, unmatched ']' token, 
unmatched ')' token, or a block or function that contains a <i>bad 

    There may be additional restrictions based on the context. For 
example, a semicolon would end the declaration in a style rule but not 
in CSSStyleDeclaration.setProperty(). CSS comments are valid but removed[2].

    Aside from the restrictions above, the value of a custom property 
can be anything.

[1] Although I’m not sure that BAD_COMMENT is a thing. Syntax 3 gets rid 
of it, and implementations seems to treat it like a regular comment. 
Test case:
data:text/html,<!doctype html><style>body{background:green/*

[2] This part should probably be normative. Starting another thread.

Simon Sapin
Received on Wednesday, 22 May 2013 05:39:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:43 UTC