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

On Thu, May 10, 2012 at 11:27 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> == Disadvantages ==
> 1. We might no longer be able to introduce keywords in calc().

I am somewhat concerned about this, but I'm not entirely certain how
we'd want to do keywords anyway.

That said, I'd prefer not to limit ourselves too much in this sort of thing.


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

I'm much more concerned about these two.  I'd like to avoid as much as
possible having to do "go back and reparse all of these tokens.  In
particular, calc() can be more complex than :nth(), since it allows
nested functions and whatnot.

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

Possible, sure.  Just a bit ugly.

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

That's a generic tokenizer flag.  It doesn't change dynamically during
tokenizing/parsing.

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

I'm not sure what all browsers do, but at the very least it makes it
harder to spec. ^_^  I suspect that browsers probably generally use
integrated tokenizer/parsers, but simpler implementations that aren't
as perf-sensitive might use separate ones, as I think they're easier.

~TJ

Received on Thursday, 10 May 2012 15:52:05 UTC