[css-syntax][css-values] Revisiting calc() and whitespace #3626

(migrated from mailing list)

Simon Pieters said:

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.)

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.
• 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.

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.

Open issues:

• Should calc(+ 1px) be valid?

Tab Atkins said:

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.

Simon Pieters said:

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.

Yes, I think we should make those two valid. But I think it would be silly
to allow calc(1px+1px) and calc(1px + 1px) but not calc(1px +1px). We
currently allow calc(2*2px) calc(2 * 2px) calc(2 *2px) etc.

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.)

Not really -- such vendors could just special-case their vendor-specific
units in their tokenizer. It doesn't matter that the tokens would be
different since other UAs would drop the entire declaration anyway.

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

I agree it's more complicated to define. But authors are higher in the
priority of constituencies. :-)

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.

I don't disagree, but changing the parsing rules for idents in general
seems really scary given classes and IDs.

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.

The current rules aren't consistent.

Open issues:

• Should calc(+ 1px) be valid?

No, regardless.

What about calc(+1px)?

Brad Kemper said:

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

...which are both invalid for different reasons.

Yes, I think we should make those two valid. But I think it would be silly to allow calc(1px+1px) and calc(1px + 1px) but not calc(1px +1px). We currently allow calc(2*2px) calc(2 * 2px) calc(2 *2px) etc.

I totally agree. I've used calc on a few projects now, and I always have to stop and remember to insert spaces on both sides of the plus, because I remember the discussion that leaving the space out of one side or the other caused some sort of problem. If I wasn't involved in this list, I probably wouldn't remember that, and I still don't spend a lot of time thinking about "why" when I'm writing it. It seems like a silly, unintuitive restriction to me, that only exists to make things more convenient for implementors.

If it comes to it, I'd rather we disallowed adding or subtracting signed values on the right, than to force spaces into what looks like otherwise valid math.