Re: [css-values] Summary of calc() options regarding whitespace

On Wed, 14 May 2014 09:24:43 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> [Sorry for not sending this earlier. It had slipped my mind until
> Daniel poked me about it.]
>
> At last week's conf call, I wanted to summarize the options for
> amending calc()'s handling of whitespace around the + and - operators
> before we made a decision.  I think we can realistically go with the
> following options:
>
> 1. Leave the spec as it is.  You have to remember that +- require
> spaces when used as calc operators, but it avoids all the other
> problems (as intended).
>
> 2. Make whitespace optional around +-, just like it is around */.
> Additionally, change Syntax so that the unit part of a dimension token
> is more restrictive than an ident, and disallows a dash followed by a
> digit.  Then, define calc()'s token handling carefully to make things
> like "calc(1+2)" (which parses as NUMBER(1) NUMBER(+2)) and
> "calc(1em-1px)" (which will parse as DIMENSION(1, em-) DIMENSION(1,
> px) after our Syntax changes).

Hmm. I envisioned it would parse as DIMENSION(1, em) DIMENSION(-1, px).  
That is, emit the current token when seeing the dash and reconsume the  
dash. Also, do this when seeing a dash, not only when seeing a dash  
followed by a digit.

We can still support vendor-specific units by allowing dashes in the unit  
when the first character is a dash. Or maybe even say that when seeing a  
dash followed by a number, you consume characters while it matches one of  
the vendor-specific units supported by the UA.

> I already have experience doing this
> for An+B, so I don't expect problems. This will still require authors
> to remember to put spaces around the - sign when using a function on
> the rhs (like "calc(1-attr(foo))", which is an invalid -attr()
> function) or an ident on either side, but this may be easier to
> intuitively understand.

Wouldn't "-attr" be a unit with your proposal?

> I believe those were the only two seriously discussed options on the
> last call.  I'd like to decide on one of them at this next call if
> possible.
>
> ~TJ
>


-- 
Simon Pieters
Opera Software

Received on Wednesday, 14 May 2014 11:19:09 UTC