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

On Wed, Jan 30, 2013 at 12:02 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> 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 meant to be something different, yes.  When the spec says "this
is a parse error", it's just a hook for a place for validators to
flag.  It's not meant to have any actual effect on processors.  This
is supposed to have an effect - the calling spec should check if it
got a parse error back, and trigger its own error-handling behavior
somehow.

I've changed it to "syntax error" to hopefully avoid future confusion.

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

I couldn't figure out how to avoid the flag without doing something
that caused even more damage to the parser.  Oh well.

> "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?)

Yes, it's supposed to be the same as "component value".  I've changed
it thusly, and also changed all references to "primitive" to
"component value" as well.  Thanks for pointing out that it's the same
concept. ^_^

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

Hm, you're probably right.  Done.  I added some more error-handling
while I was at it.


> 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:

Now that it can fail, I've added more error-handling here.

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

Thanks, fixed.

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

Done.


>> 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?

Yes, all whitespace is ignored.  All that property grammars care about
is the significant tokens.

(This will eventually change when we start putting selectors into
property values, so I can't just discard all whitespace in the
parser.)

~TJ

Received on Thursday, 31 January 2013 21:52:38 UTC