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

On Tue, Jun 12, 2012 at 3:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.

I just put together some edits to address this.

Now, at-rules that take a block are classified as "rule-filled" or
"declaration-filled".  When you hit a { in at-rule mode, you dispatch
to either rule mode or declaration mode based on this.  Rule mode is
similar to top-level mode, but appropriately changed (for example,
<!-- now starts a style rule rather than being ignored).  Declaration
mode has been altered to accept at-rules as well as declarations.
(This also makes it easier in the future to accept at-rules inside of
style rules, which we want for a few things like Mixins and such.)

~TJ

Received on Thursday, 14 June 2012 00:45:29 UTC