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

[css-parser] Exposing the current tokens

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 2 Jun 2015 15:49:32 -0700
Message-ID: <CAAWBYDB0oQK4QAuRqyiYsFMeAOR9_u81OwQg424eeRNosbP3Jg@mail.gmail.com>
To: "public-houdini@w3.org" <public-houdini@w3.org>
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
Received on Tuesday, 2 June 2015 22:50:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 2 June 2015 22:50:22 UTC