W3C home > Mailing lists > Public > www-style@w3.org > March 2008

Re: [css3-values] calc(), whitespace, and DIMENSION tokens

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 18 Mar 2008 23:53:26 -0700
To: www-style@w3.org
Message-ID: <20080319065326.GB5639@ridley.dbaron.org>

On Tuesday 2008-03-11 15:42 -0700, fantasai wrote:
> I think it's fine to require white space around plus and minus signs in
> calc() expressions, since that helps emphasize that they're lower precedence
> than * and /. However, if we're requiring white space around these operators
> in calc(), then we should at least allow white space around them in :nth-child().

I would prefer not to require white space around plus and minus
signs inside calc().  I think we (the specification authors and
implementors) may need to suffer a little pain to get that working
sensibly, but I think authors will want to use it both ways.  I
think some authors will want to use spaces around plus and minus
signs, and some won't; I suspect this depends significantly on what
other languages those authors have experience with.

I don't (yet) have strong preferences on how we do this.  (And I
haven't yet had a chance to read the proposals later in this thread
in detail.)  Possibilities include:

 * making :nth-child() and calc() handled as single tokens and then
   having a separate grammar for what is inside them

 * making the tokenizer stateful

 * making the parsing for what is inside :nth-child() and calc()
   give substantially different token streams the same semantics

 * restricting the units within dimensions to something more
   restrictive than identifier (forbidding "-").  (We'd need to be
   careful about vendor extension units here, although that might be
   possible with "_".)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Wednesday, 19 March 2008 06:53:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:02 GMT