Re: [css3-values] inaccurate statements about syntax/grammar

(12/04/04 21:47), Simon Sapin wrote:
> Le 04/04/2012 12:15, Kang-Hao (Kenny) Lu a écrit :
>> 2.3. Component value multipliers
>>
>>    # Component values are specified in terms of tokens, as described in
>>    # Chapter 4 of [CSS21]. As the grammar allows spaces between tokens
>>    # in the components of the value production, spaces may appear
>>    # between tokens in property values.
>>
>> The latter sentence is false at least in the following cases I know of:
>>
>> 1. Spaces are not allowed in-between the sign and the number. Namely
>> "'-'(DELIM) S NUMBER/PERCENTAGE/DIMENSION" are invalid token sequences
>> besides special situation like in a calc().
> 
> I think this is a flaw of the grammar. The sign should really be in the
> same token as the number it is for. More precisely, I suggest changing
> the num macro (used in the NUMBER, DIMENSION and PERCENTAGE tokens) from
> 
>    [0-9]+|[0-9]*\.[0-9]+
> 
> to
> 
>    [+-]?([0-9]+|[0-9]*\.[0-9]+)
> 
> I know that changing the core grammar is generally avoided, but this
> particular change solves several related issues.

Just as data input, in the following test case:

data:text/html,<style>div { width: 1em; height: 1em; height: +/**/2em;
background: blue; } </style><div></div>

IE9 and Firefox11 show a 1em x 2em ('+2' is a single token) blue
rectangle while Opera12alpha and Chromium18 show a 1em x 1em ('+2' are
two tokens).

What are the other issues by the way?

>> 2. "'#'(DELIM) IDENT" in element(#id) and its possible generalization to
>> arbitrary selectors.
> 
> #foo parses as a single HASH token in both CSS 2.1 and Selectors 3, so I
> think there is no issue here. # foo would parse as DELIM S IDENT, it is
> not a valid ID selector or argument for element()

Ah, I missed that. Thank you for pointing that out.

>> 3. I would assume<id>  used in nav-* to be in a similar situation to 2.
>> although it isn't quite clear.
> 
> (This is for in css3-ui, right?) 

Yes.

> css3-ui defines:
> "The <id> value consists of a ‘#’ character followed by an identifier"
> 
> I think this should be changed to refer to ID selectors, like element()
> does. This would effectively means that <id> is a HASH token. This is
> not quite the same: the name in a HASH can start with a digit, while an
> identifier can not.

Agreed.

>> (Feel free to add more if you know anymore. Even if these exceptions are
>> too messy to put in the spec, it's probably not a bad idea if a complete
>> list is archived on www-style.)
> 
> With a change to how numbers are parsed, I think that none of these
> three really have issues with white space. But I am also very interested
> to know: is there any other exception? Do we reserve the possibility to
> add such exceptions in the future? Or can a parser unconditionally
> remove white space tokens in property values? (That is, before any
> property-specific parsing.)

I think Tab intends to make element() accept arbitrary selector[1],
where spaces do matter. But now that element() is deferred to CSS4
Images, it probably takes a while before that matters.



[1] http://lists.w3.org/Archives/Public/www-style/2012Feb/0265


Cheers,
Kenny

Received on Wednesday, 4 April 2012 14:27:58 UTC