Re: [css-values] Revisiting calc() and whitespace

On Wed, Apr 30, 2014 at 9:42 AM, Simon Pieters <simonp@opera.com> wrote:
> I'd like to reopen the issue of whitespace around + and - in calc(). I think
> the current situation is hostile for authors and we can do better. In my
> opinion, we should make things that look OK be OK and things that don't,
> aren't.
>
> Currently the following are valid:
>
> calc(1px + +1px)
> calc(1px + 1px)
>
> but this are not:
>
> calc(1px + + 1px);
> calc(1px +1px);
>
> (I wouldn't be able to explain it to a Web author keeping a straight face
> and avoid #WTFCSS tweets why it's like this.)

The + and - operations need whitespace around them.  Values can have
unary + or - prepended to them.

Why would somebody do either of those invalid ones, anyway?  They both
look wrong; it's pretty easy to argue that writing either of them is
an error.  You should be arguing for the sensible ones that are
currently invalid:

calc(1px-1px)
calc(1px+1px)

...which are both invalid for different reasons.

> I propose that we make the following changes:
>
> * In css-syntax, while tokenizing a dimension, we exclude "-" from being a
> valid character in the unit.

This would prevent vendor-prefixed units, which exist today.  (I agree
that we probably won't ever introduce units with dashes in them
normally, for writeability concerns.)

> * In css-syntax, we store whether "+" or "-" was used in the token. (This is
> technically already stored in the "representation".)
> * We remove all whitespace restrictions in calc() (currently calc(1px+ 1px)
> is not allowed but it parses OK).
> * We define that the "+" or "-" delim in calc() must be omitted if the next
> value is a <number-token>/<percentage-token>/<dimension-token> with "+"/"-"
> set.
>
> This would make it valid to use exactly one +/- with any whitespace around,
> as far as I can tell.

This makes parsing much more complicated to define, as it results in
something like the pain we got into with An+B.  Rather than a simple
rule of "<value> <op> <value>", we have to handle cases like "<value>
<value>" and "<value> <op> <op> <value>".  Would we have to handle a
disconnected +- sign when dealing with other operations, too?

> Previously stated concerns against:
> * This wouldn't help with keywords if we are going to add keywords in the
> future (e.g. calc(auto-1em)).
>   - Rebuttal: I don't see why that has to cripple calc() with dimensions.
> Saying that keywords can contain dashes and so have to be followed by a
> space seems sane to me.

This kind of inconsistency troubles me.  I don't like authors having
to remember special-case rules based on divisions that are fairly
arbitrary to them.  The distinction between a keyword and a dimension
isn't large - a dim just looks like a keyword with a number in front
of it.  Why should the rules be different?  Why should authors face
confusing and hard-to-find errors when they apply the same rules that
work between dimensions to a keyword/dimension pair?  "auto-1em"
doesn't look wrong to my eyes; it would be very easy to skip over it
when looking for what was wrong in my code, because my brain has
enough contextual information to parse it easily.

CSS is big, and growing.  I've been moving more strongly toward the
"keep things consistent, even if they're suboptimal in some cases"
camp for a while now.

> Open issues:
> * Should calc(+ 1px) be valid?

No, regardless.

~TJ

Received on Wednesday, 30 April 2014 17:07:08 UTC