Re: [css-parser] Exposing the current tokens

On Wed, Jun 3, 2015 at 10:49 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

>
> Alternately, we could expose parsing solely "by request".  Give
> strings by default, but you can specify a grammar ahead of time and we
> can attempt to parse it according to that.  This gives us a slightly
> higher-level API that we have stronger control over; we could still
> change the underlying CSS parser without necessarily affecting the
> exposed grammar.  (This is similar to what Ian talked about two weeks
> ago in "An incremental approach Typed & Custom Properties".)
>
> This also gives authors something slightly more convenient - they can
> ask for a <color> and actually get something useful, rather than
> having to handle "a hash-token, or a keyword, or a function" and have
> to verify and convert them all into a common type of object.
>

This looks like a good idea. But what syntax would we provide to define the
grammar?

The first candidate would be the definition syntax we currently use in
specs. But I'm concerned about the ambiguity of that.

We have met that problem for animation and list-style shorthands, where
some subtypes are able to accept the same value for a same position. We
would have to face it here again.

- Xidorn