Re: [css3-values] valid rationale for not allowing spaces around '+' and '-' to be dropped

(12/07/05 15:58), Tab Atkins Jr. wrote:
> 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.

I disagree, but fine. I just hope the working group states the rationale
in a more understandable way, such as

  "We (might want/are likely) to add the ability to use keywords in
calc(), in order not to make people get acquainted to omitting spaces
around '-' and hence produce invalid value like
'calc(auto-min-content)', we force authors to always put spaces around
'+' and '-'."

and potentially with some of the points below. Saying "because it means
you can't put keywords in calc in future" is, in my humble opinion, not
technically right.

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

Which part do you not understand? I think the main reason why we decided
to force spaces around '+' '-' instead having the tokenizer decides what
spaces are required is because it's not easy to learn the DIMENSION
token in CSS, and hence the proposal to change it.

>> 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 think calc() is not yet deployed enough so we can still change this.
But what I am trying to say is that if this is one of the main concerns,
it should have been part of the WG discussion. When we were discussing
two months ago[1], no body mentioned this as an issue.

[1] http://lists.w3.org/Archives/Public/www-style/2012May/thread#msg404

>> I consider 3. minor too, given that we do are changing it.
> 
> I don't understand.

http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-tokenizer

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

Maybe, I don't know.


Cheers,
Kenny

Received on Thursday, 5 July 2012 08:51:43 UTC