Re: [css3-syntax] Parser "entry points"

On Sun, Jan 27, 2013 at 8:36 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Hi,
>
> I count four different cases where the Syntax module would be needed:
>
> 1. Parsing a whole stylesheet
> 2. Parsing a style attribute
> 3. Parsing a single declaration (part of a @support condition)
> 4. Parsing any stand-alone "unit" that does not have error recovery:
> selectors (for selector APIs), media queries (media attribute), conditions
> or property values (for CSS.supports()), etc.

Okay, I've added some entry points.  They cover your #1 and #2, and
the extra one I pointed out (parsing a single complete rule).  Mind
checking it for errors?

I also added some "entry points" for parsing a single value, a list of
values, and a comma-separated list of values, as those seem like the
kinds of things that other technologies would want to hook into if
they're exposing something that uses CSS syntax.  They dont' actually
enter the parser, but instead just work on the token stream directly,
and use the "consume a primitive" operation.

Your #3 and #4 should be addressed by a grammar.  I still intend to
define a bunch of grammar terms and their expansions, so that new
at-rules and the like can be described in CSS property grammar terms,
which is much easier to read and write than the current ways of
writing rule grammars.

So, for example, your #3 would just be written as "<ident> : <primitive>+".

For a more complex example, @supports could be written with something like this:

@supports <supports-condition> { <declaration-list> }
<supports-condition> = <supports-or> | <supports-and> | <supports-not>
| <supports-predicate>
<supports-or> = <supports-condition> [ or <supports-condition> ]+
<supports-and> = <supports-condition> [ and <supports-condition> ]+
<supports-not> = not <supports-condition>
<supports-predicate> = ( [ <supports-condition> | <declaration> | <function> ] )

I think this is somewhat easier to read, and it means we don't have to
mess around with putting S* in all the right places.

~TJ

Received on Wednesday, 30 January 2013 03:02:46 UTC