Re: [css3-syntax] First draft of parser section completed

On Sat, Jun 9, 2012 at 2:25 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 09/06/2012 06:01, Kang-Hao (Kenny) Lu a écrit :
> EOF in blocks
> ============
>
> In "Consume a block":
>>
>> EOF token
>>    Return nothing.
>
>
> This does not match the "Unexpected end of style sheet" rule of CSS 2.1.
> Instead, EOF should be the same as finding the ending token (close and
> return the block normally, unless an error was previously found.)

Fixed.


> !important
> ==========
>
> Where should be !important be parsed? I think it should be in or near
> "Declaration-value mode". But then what about descriptors? (see below)

Ooh, good point.  I need to parse this in declaration-value mode.

I might want a context flag here about whether !important is allowed
or not.  Hm.  I'll just parse it naively for now, and put an issue in
the document about this.


> Issue 4
> =======
>
> {} blocks can contains a variety of things:
>
> * @font-face: descriptor declarations (name ':' value)
> * style rules: property declarations (descriptors with an optional
> !important)
> * @page: at-rules mixed with property declarations
> * @media: any statement
> * @region: style rules
> * @keyframes, future modules: something else

You can transform this into a simpler categorization:

@font-face: like a style rule
@page: like a style rule, but also with at-rules
@media: like top-level
@regions: like top-level
@keyframes: like top-level

> I think that Syntax3 should not make any assumption on the content of
> at-rules and do something like this instead:
>
> The output of Syntax3’s tree construction can contain "unparsed at-rules"
> with each:
>
> * an at-keyword
> * a "head" (everything after the at-keyword and before ';' or '{')
> * an optional "body".
>
> The body is missing if the at-rule ends with ';'. It is the content of the
> {} block otherwise. The head and body (if any) are both a mixed list of
> tokens, functions and blocks. (There is no [](){} of function tokens: these
> have been turned into nested function/block objects, or have triggered a
> nesting error.)
>
> There is not guarantee on the shape of the at-rule’s content except that is
> is "well-formed" according to the 'at-rule' production of the core grammar.
> (ie. no nesting error, no cdo or cdc token, ...)
>
> Only then, each CSS module (or wherever a particular at-rule is defined)
> would have its own parser for the head and body of an at-rule.
>
> Syntax3 can have pre-defined procedures (like "parse a sequence of
> descriptors") that can be used by the at-rule parsers. These can then be
> very simple (@font-face) or more complex (@keyframes) as needed.

I don't think this is necessary.  I think we can just dispatch based
on the at-keyword token's value to either a mode that recognizes
at-rules and style rules, or one that recognizes at-rules and
declarations.

I really don't think it's even *possible* to have a situation other
than what we currently have.  There are exactly three significant
syntax features in CSS: at-rules, style rules, and declarations.  You
can't mix style rules and declarations in the same context, because
they require infinite lookahead to disambiguate.  So, you're stuck
with style rules + at-rules and declarations + at-rules.  That's the
sum of the possibilities unless we introduce a completely new syntax
construct, which would obviously require changes to Syntax anyway.

~TJ

Received on Tuesday, 12 June 2012 22:27:46 UTC