[css3-values] calc() and whitespaces around '+' and '-' (again)

There are multiple complaints about the fact that spaces are around '+'
'-' from Web devlopers[1][2] and so I would like to see if we can still
save this.

My concrete proposal is as follows:

1. In 8.1.1. Syntax, add

  | When parsing contents inside 'calc()', unless it is also inside a
  | functional notation that's not 'calc()', tokenize the stream as if
  | {nmchar} changes from
  |
  |    [_a-z0-9-]|{nonascii}|{escape}
  |
  | to
  |
  |    [_a-z0-9]|{nonascii}|{escape} (HYPHEN-MINUS removed)
  |
  | and the ident macro changes from
  |
  |     [-]?{nmstart}{nmchar}*
  |
  | to
  |
  |     {nmstart}{nmchar}*

2. (Assuming that sign becomes part of the number) Change

  # sum     : product [ S+ [ "+" | "-" ] S+ product ]*;

to

  | sum     : product [ S* [ "+" | "-" ]? S* product ]*;

and add a statement

  | the '+' and '-' sign is only ignorable when product starts with a
  | sign


I was reading previous discussion about this 3 years ago, and while the
discussion seemed to favor allowing optional spaces around '+' and '-',
it was resolved with this working group resolution:

(08/11/11 3:04), fantasai wrote[3]:
> Parsing calc()
> --------------
>
>   * RESOLVED: Spaces are required around arithmetic operators in
>               calc().
>               Spaces are not required around parentheses (due to the
>               parentheses: they may be required outside parentheses
>               due to adjacent arithmetic operators).
>     RATIONALE: The contents of calc() cannot be tokenized without
>                spaces around the minus sign, so to be consistent and
>                avoid confusion we resolved to require spaces around
>                all arithmetic operators.

but I can't find the minutes of this particular meeting.

The rationale assumed that the tokenizer can't be changed (so that we
can never have calc(3em-2em)) and I would like to know why (since we
just ask for two changes to the core grammar very recently). Let me
summarize the advantages and disadvantages of this proposal:

== Advantages ==
1. It's less confusing and more consistent with :nth-child(), '*' or '/'
and so on.
2. Parsing :nth-child() fully according to the spec might need this
tokenization mode too[4].

For 2., the rest of the cases that browser don't handle currently are
just edge cases so we might as well just change the spec.

== Disadvantages ==
1. We might no longer be able to introduce keywords in calc().
2. Every time the browser is parsing an identifier, it needs to check
the flag to see if the mode of tokenization needs to be switched.
3. You cannot do tokenization and parsing as two passes as parsing
calc() changes the sate of the tokenizer.

For 1., I think we can still introduce something like 'use()' later if
there are really use cases. For example, 'use(fit-content)' or
'use(xx-large)'.

For 2., I'd like to note that the there a flag that's required to handle
SVG mode too.

For 3., it isn't a concern for Gecko as far as I can tell, but I don't
about other browsers.


What do you think?


[1]
http://meyerweb.com/eric/thoughts/2012/04/10/whitespace-in-css-calculations/

[2] http://webdesignersarasota.com/whitespace-in-css-calculations/
[3] http://lists.w3.org/Archives/Public/www-style/2008Nov/0147
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=750388#c4


Cheers,
Kenny

Received on Thursday, 10 May 2012 09:27:59 UTC