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

On Tue, May 21, 2013 at 10:38 PM, Simon Sapin <simon.sapin@exyr.org> wrote:
> 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.

I prefer something like this, too.  It's less reliant on weird details
of CSS 2.1's tokenization definitions, and nothing needs to be done to
rebase it on top of Syntax.

> [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.

Syntax already removes comments - note that the Comment state does
*not* add a comment token to the stream. I do allow implementations to
remember the contents and location of comments, and to use that in
serialization, but regardless comments are required to be completely
ignored for all Syntax-related purposes.

~TJ

Received on Wednesday, 22 May 2013 06:34:51 UTC