Re: [css-parser] Exposing the current tokens

On Tue, Jun 2, 2015 at 6:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> So, css-parser is a prerequisite to doing most of the "extend existing
> CSS constructs" things: custom at-rules, custom functions, custom
> properties, they all need to be able to receive CSS and reason about
> it.  Forcing everyone to parse strings is dumb; we'll just get
> inconsistent and buggy behavior out of apps.
>
> But standardizing parsing means exposing things like our token
> structure.  We've previously resisted doing this, so we could change
> our tokens, and we've actually done that (changed our tokens).  Are we
> okay with more or less freezing our token structure now?
>
> 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.
>
> Thoughts?
>
> ~TJ
>

It seems to me that often tokens aren't the level you want, you want a
kind of an AST which might contain some further unparsed things
(values, for example) but it would already be clear at that point
which 'kind' of thing you needed to turn into something further
pleasant.  I sent it to editors and tweeted about it, but I never
mentioned it here, so I posted up some research (more is always better
if someone wants to submit any) of how other libraries are dealing
with parsing CSS into something useful to them - it seems to vary.  It
feels like you could achieve both with more of the latter approach,
no?

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Wednesday, 3 June 2015 01:25:30 UTC