W3C home > Mailing lists > Public > public-houdini@w3.org > June 2015

Re: [css-parser] Exposing the current tokens

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 8 Jun 2015 10:54:55 -0700
Message-ID: <CAAWBYDDKeY7RvM1kin4njWg_HrqoW14yVoutmbFoiRr6QaWtKw@mail.gmail.com>
To: Xidorn Quan <quanxunzhen@gmail.com>
Cc: "public-houdini@w3.org" <public-houdini@w3.org>
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.

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

This archive was generated by hypermail 2.3.1 : Monday, 8 June 2015 17:55:44 UTC