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

Re: [css-parser] Exposing the current tokens

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Mon, 8 Jun 2015 16:21:33 +1200
Message-ID: <CAMdq6988ODub-pmpvV7gxTFf5bPAEJt0VMOK+iqBrucDhVKKsw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "public-houdini@w3.org" <public-houdini@w3.org>
On Wed, Jun 3, 2015 at 10:49 AM, Tab Atkins Jr. <jackalmage@gmail.com>

> 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

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
Received on Monday, 8 June 2015 04:22:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 8 June 2015 04:22:41 UTC