Re: [css3-values] valid rationale for not allowing spaces around '+' and '-' to be dropped (was: [CSSWG] Minutes and Resolutions 2012-07-04)

On Wed, Jul 4, 2012 at 6:05 PM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
>(would people seriously think "auto-min-content" would work?)

Yes, quite certainly.  If you're writing it, and thinking "auto minus
min-content", your brain can easily split that correctly and not see
any problem.


>>   <fantasai> proposal: no change, white space is required
>>   fantasai: saying no change to calc, whitespace is required around + and -
>>   hober: why not require it around / and * for consistency
>>   fantasai: they don't need it
>>   smfr: hard for authors to remember where to put whitespace
>>   fantasai: just put white space everywhere
>>   fantasai: */ bind tigheter than + and - , so the current requirements
>>             make sense
>>   dbaron: gecko implements what the spec says
>>   RESOLVED: accept the rejection of this issue
>>   plinss: do we want to require whitespace around / and *?
>>   dbaron/fantasai/florian: do not want
>>   RESOLVED: leave the rest alone
>
> Given that there's a consistency issue here and in my mail[1] I cited
> two pages where the community expresses negative opinion to this, I
> think it's particularly important to make sure we have sound and valid
> rationale even we reject this.
>
> Some rationale why we can't allow space around '+'/'-' to be dropped:
>
> 1. If we are to introduce keywords in calc() in the future, the spaces
> around '-' can't be dropped when one of the two sides is a IDENT so it
> is inconsistent.
> 2. Browsers already implement this and changing it doesn't worth it.
> 3. We don't want to change the core grammar (for IDENT).
>
>
> I consider 1. to be quite minor a point. We don't know when we'll
> introduce keywords in calc() and even we do so, not being able to drop
> the spaces in certain situations is only a natural consequence of how
> CSS tokenization works. It's just not easy to remember that a unit can
> have a '-' in it!

I don't understand what you mean.

> 2. is also quite minor. This really isn't hard to implement.

Matching existing implementations is always a strong consideration.
We should avoid falling into bugwards compat unless absolutely
necessary, but should reject changes from existing usage without
strong rationale.

> I consider 3. minor too, given that we do are changing it.

I don't understand.

> (Note that there would be
> a lot more calc(x% - yem) than, say, calc(100vw - 2em), I think.)

I doubt this.  Both seem quite ]useful and likely to be common.

~TJ

Received on Thursday, 5 July 2012 07:59:15 UTC