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

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 
token</i>.

    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