Re: [css-parser] Exposing the current tokens

On Sun, Jun 7, 2015 at 9:21 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
> 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.

Yeah, we'd have to either define a subset that can't define ambiguous
grammars, or create rigorous evaluation rules that make the evaluation
unambiguous even if a naive reading would allow multiple valid parses.

The former is probably fine for a first pass, as you can do quite a
lot, but it's still pretty limiting.  I'll probably end up doing the
latter eventually.  Luckily, the latter will subsume the former; if we
limit you to only unambiguous grammars first, then later add rules for
resolving ambiguous grammars, the existing stuff won't change meaning.

~TJ

Received on Monday, 8 June 2015 17:55:43 UTC