W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Thu, 07 Feb 2019 22:32:05 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-407927407-1549578724-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-syntax][css-values] Revisiting calc() and whitespace ==
(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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3626 using your GitHub account
Received on Thursday, 7 February 2019 22:32:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:43 UTC