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

On Wed, May 14, 2014 at 1:18 PM, Simon Pieters <simonp@opera.com> wrote:
> 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.

Yeah, that's possible too.  I don't have a strong opinion either way.

> 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 don't like this, because it limits what we can do in the future with
units seemingly unnecessarily.  It doesn't gain us anything in terms
of calc(), as "calc(1em-auto)" would parse into DIMENSION(1, em)
IDENT(-auto), which is a legitimate ident that we can't automatically
treat as subtraction.

I think there may be legit uses for dashes in units in the future,
particularly if we ever do user-defined units.  I don't think there's
any legit use of numbers in the dash unit, to be honest, so I'm fine
with the "no digit following a dash" rule.

>> 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?

Ah, good catch, yes.  So it's still invalid, just for a different reason.

~TJ

Received on Wednesday, 14 May 2014 12:06:41 UTC