W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-syntax][css3-page] The mixed declaration/at-rule syntax is not LL(k)

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Sun, 03 Feb 2013 16:48:43 -0700
Message-ID: <510EF75B.6080509@kozea.fr>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
Le 03/02/2013 14:41, Tab Atkins Jr. a écrit :
> Technically, the parser is a deterministic pushdown automata, so it
> is, by definition, possible to represent with a context-free grammar.
> Can you elaborate on what problems you've been having with the
> declaration branches?

My knowledge of parsing theory is weak, but "not all context-free 
languages are LL(k) languages."

Source: https://en.wikipedia.org/wiki/LL%28k%29

I’m talking about the "page" production of the grammar in css3-page:

The interesting part is:

     '{' S*
     [ [ declaration? ';' S* ] | page_margin_box ]*
     [ declaration ]?

So for example after you’ve consumed '{' based on the next token you can 
know if what you have next is an at-rule or a declaration. But for 
declarations at this point, you need unbounded look-ahead to decide 
whether to go into the second line’s branch (a declaration ending with 
';') or the third line’s branch (declaration ending with '}')

The trick is, it doesn’t matter because what you do with a declaration 
is the same in either case. But I don’t know how to express that in a 

Then again: should we care? I’d like to have feedback from other 

> The correct way to handle declarations in a grammar is, as far as I
> can tell, to represent them as a declaration-list production like:
> declaration-list = <declaration> [ ; <declaration> ] ;?
> ...where each declaration has no explicit ending token.

Yeah I understand that pattern, but it gets more tricky when you mix 
declarations and at-rules. A semicolon is required for a declaration 
followed by an at-rule, but not for an at-rule followed by a declaration.

Simon Sapin
Received on Sunday, 3 February 2013 23:49:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:08 UTC