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

Le 31/01/2013 22:51, Tab Atkins Jr. a écrit :
> 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"? […]
>
> 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. […]

I think it would still be useful if browsers report such parse errors on 
their (developer tools) console. (But I’m not talking about making 
reporting a requirement.)


>> "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. ^_^

Aw. I kind of liked "primitive" :)


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

Yes, I was thinking of selectors of "unless otherwise specified".
@page selectors too, and maybe some other cases.

-- 
Simon Sapin

Received on Thursday, 31 January 2013 23:55:15 UTC