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

Le 28/01/2013 07:38, Tab Atkins Jr. a écrit :
> On Sun, Jan 27, 2013 at 8:36 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
>> A style attribute is like a declaration block where a top-level } token does
>> not terminate the block but is treated like a ] token (that is: make the
>> current declaration invalid and make the parser skip until the next ; token
>> or EOF.) Start in declaration-block mode, and these sections need to be
>> adjusted:
>>
>> * 3.5.7. Declaration-block mode
>> * 3.5.9. Declaration-value mode
>> * 3.5.11. Declaration-end mode
>
> Hrm, okay.  My plan was to just start the parser at a particular
> state, and end it when the rule got popped or the current declaration
> was appended or unset, but I guess I do have to explicitly change the
> parser for a few states.
>
> I wonder if impls would be okay with changing behavior to end the rule
> after } and ignore anything that comes after?  That would simplify the
> parser slightly. ^_^

Oh well. No interop, again.

data:text/html,<p style="color:red;};color:green">test

Green in Firefox and IE, red in Chrome and Opera.

http://www.w3.org/TR/css-style-attr/ has an informative note:
> Note that because there is no open brace delimiting the declaration
> list in the CSS style attribute syntax, a close brace (}) in the
> style attribute's value does not terminate the style data: it is
> merely an invalid token.

But if you only look at normative text, I think this is undefined 
because the above style attr does not match the CSS 2.1 core grammar at all.


>> Similarly, for a single declaration, a ; token does not end the declaration.
>
> What do you mean by "does not end the declaration"?  It looks like
> top-level ; tokens aren't allowed in @supports conditions, and I don't
> see how they'd be allowed anywhere else that wants to take a single
> decl in the future.  I'd prefer to just say that it's a syntax error
> if the decl is appended or unset before the token stream is fully
> consumed.

Ok, that would work too. But it’s still different from "append the 
declaration to the current rule and switch …" etc, so the state machine 
still has to be adapted.


>> Finally, anything that does not have error recovery is the same with respect
>> to the Syntax module. It needs a new mode that repeatedly "consumes a
>> primitive" until EOF, and maybe fails at the first non-preserved token.
>> Parsing these primitives further is up to other modules.
>
> Can you explain what you mean by this in more detail?

Let’s take selectors for example. In the output of Tree Construction for 
a whole stylesheets, selectors are represented as lists of primitives. 
Hopefully, the syntax in selectors4 will be defined in terms of such 
primitives rather than have its own tokenizer.

So, to parse a stand-alone selector from querySelectorAll() you would 
need to use the css3-syntax tokenizer, then something like this:

> This section describes how to consume a list of primitives.
>
> Create a list that is initially empty.
>
> Repeatedly consume the next input token and process it as follows:
>
> EOF token
>     Return the list.
> anything else
>     Consume a primitive and append the returned value to the list.

… and then pass the result to the selector parser.


If "consume a primitive" is changed to return a failure on non-preserved 
tokens (see [1] and [2]) then that needs to be handled in "consume a 
list of primitives" somehow.

[1] http://lists.w3.org/Archives/Public/www-style/2012Nov/0401.html
[2] http://lists.w3.org/Archives/Public/www-style/2013Jan/0263.html

Error handling in selectors is easy: the whole selector list is invalid. 
I’m not sure about media queries…

data:text/html,<style>@media ], all{body{background:green

(Green in Firefox, Opera and IE, not in Chrome.)

-- 
Simon Sapin

Received on Monday, 28 January 2013 12:20:39 UTC