- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Tue, 12 Sep 2006 13:59:19 -0700
- To: "Christian Roth" <roth@visualclick.de>, "www-style Mailing List" <www-style@w3.org>
> -----Original Message----- > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Christian Roth > Sent: Tuesday, September 12, 2006 1:30 PM > To: www-style Mailing List > Subject: Re: Up-to-date CSS 3 grammar > > > L. David Baron wrote: > [snip] > > >That said, those implementations that have written their CSS parsers > >using flex or similar tools probably have such a grammar. > > I'd be interested to see such a grammar that fully implements CSS2.1 > Syntax. I didn't get it to work and we finally rolled our own recursive > descent parser. Christian, I think this is the only practical way of doing it. We have yacc/bison (not flex - which is for lexers, not parsers) grammar and we still use it, but we'll have to trash it and start over by hand. It seems that to obey the CSS rules for parsing invalid CSS content, the grammar would just have to be more complex than the hand-written parser. > > >For what it's worth, I don't know of a formal grammar that accurately > >reflects the forward-compatible parsing rules. The ones published in > >CSS1, CSS2, and css3-syntax don't. I'd like css3-syntax to eventually > >do so. Such grammar is theoretically possible, but it is likely to be too complex to be useful. It is not really so much about "forward-compatibility" (XML is arguably forward-compatible as well); it is a side-effect of outlawing syntax errors. CSS attempts to define how to interpret every possible stream of characters as a CSS stylesheet, whereas parsers (especially tool-generated ones) typically work only with a well-defined subset and reject one way or another all illegal inputs. But you just cannot reject any input in CSS, so parsing tools are just not very useful. Peter
Received on Tuesday, 12 September 2006 20:59:46 UTC