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

On Wed, 30 Apr 2014 19:06:21 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

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

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

-- 
Simon Pieters
Opera Software

Received on Friday, 2 May 2014 07:01:04 UTC