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

Le 30/01/2013 04:01, Tab Atkins Jr. a écrit :
> Okay, I've added some entry points. […]

"Parse a stylesheet" is obviously fine.


In "Parse a rule", is "return a parse error" different from when the 
parser says "this is a parse error"? In others words:

     @media screen; /* Invalid, @media is rule-filled */
     foo { bar: baz }

The stylesheet object returned by the parser only contains one 
(non-ignored) rule. Should "parse a rule" be considered successful?


It’s tempting to have "Parse a list of declarations" reuse the 
"top-level" concept rather than adding a specific flag, but I’m not sure 
how to do that without having declaration objects directly in a (dummy) 
stylesheet object. this is editorial/minor.


"Parse a value". Is a value the same thing as a primitive? Do you want 
to avoid "primitive" because it is too obscure? Is it to match 
css3-values terminology? (How are "primitive" and "value" related to 
"component value"?) I find "value" a bit generic, an overloading 
"property value". (A property value contains … a list of values?)

More importantly, is "Parse a value" successful if the input is not 
exhausted after "consume a primitive"? I think it should ignore trailing 
whitespace, but fail if there are more non-whitespace tokens.


"Parse a list of values" is fine, but see "Parse a value" for naming.


I don’t know if "Parse a comma-separated list of values" is really 
useful, especially if "consume a primitive" never fails. (If bad-string 
and bad-url become preserved tokens.) It is easy to emulate with "Parse 
a list of values". But if we keep it:

Here you use "push" for a list, while the rest of the spec uses "push" 
for input streams and stacks, and "append" for lists. "Parse a 
comma-separated list of values" should use "append" for consistency.

Finally, temp needs to be appended to val in the last step before 
returning val.


> 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>+".

Looks good.

What are the precise rules for whitespace in such grammars? Is *any* 
whitespace ignored, unless otherwise specified?

-- 
Simon Sapin

Received on Wednesday, 30 January 2013 08:02:32 UTC