W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Wed, 04 Apr 2012 16:45:12 +0200
Message-ID: <4F7C5E78.1070903@kozea.fr>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
CC: WWW Style <www-style@w3.org>
Le 04/04/2012 16:27, Kang-Hao (Kenny) Lu a écrit :
> (12/04/04 21:47), Simon Sapin wrote:
>> 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?

They are the other number-related issues you listed:

* calc() requires a space after a plus minus. With the change, a + or - 
without space is part of the number token. So calc(2em+2px) is invalid 
(there is no operator) but calc(2em+-2px) is unambiguous (a plus 
operator with a negative number) so maybe the whitespace requirement 
could be relaxed?

On further thought, calc() is probably clearer with mandatory spaces 
around the operator. The minus sign could become part of the unit 
(identifier) before it if there is no white space to separate them.

* "To make it clear that <percentage> allows an optional sign ..." If 
the sign becomes part of the number, we can just say that <percentage> 
is a number followed by '%'.

* "immediately followed" does not always have the same meaning.


Possibly related: would a new INTEGER token in the core grammar help for 
the <integer> value type? (The NUMBER token would be only for numbers 
that contain a dot.) For example, to tell 'orphan: 2.0' apart from 
'orphan: 2' more easily. That is at least how I implemented it.

-- 
Simon Sapin
Received on Wednesday, 4 April 2012 14:45:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT