Re: Inconsistencies across CSS3 specs

* Nicholas Zakas wrote:
>I originally wrote a CSS 2.1 parser in JavaScript and have been going
>about trying to update to CSS3. The problem I'm having is that, whereas
>CSS 2.1's grammar was wholly contained in
>http://www.w3.org/TR/CSS2/grammar.html, there is no such canonical
>source for a CSS3 grammar. In fact, quite confusingly, the grammar is
>spread out amongst multiple specs. Thusfar, I've noticed the following
>problems:

Well, the grammar there helps you if you want to write a broken parser
or would like to get confused about CSS syntax, beyond that it does not
have much use. If you want to parse CSS syntax based on a grammar, then
you should take the core syntax rules, add a couple of productions and
alternatives that encode all the error recovery rules (that should take
about a dozen or so) and then, if you want higher level access to things
like at-rules and selectors, use a higher-level formalism to encode them
(possibly simply for transformation into a lower-level formalism, like
the specification does with its fancy `A`, `C`, `D` productions). Then
you run into problems like:

>1. Inconsistent naming of tokens across specifications. Some examples:

>  In the CSS3 Media Queries spec:
>    {N}{O}{T}         {return NOT;}
>
>  In the CSS3 Selectors spec:
>    ":"{N}{O}{T}"("  return NOT;

finding out that there are contradictions in the various specifications,
in this case one that is known but so far received no attention by the
working group, and in investigating those find there are changes pending
and some changes have been made quite some time ago that no browser has
since implemented. Add to that that typically browser vendors feel it's
best if they code their parser by hand (otherwise you don't introduce
enough security holes and conformance errors, I suppose) and then under-
stand why there has never been a single conforming implementation.

(Note that the problem above is not a matter of inconsistent naming, but
a semantic problem in that the generic syntax allows comments between
the colon and the identifier, while the Selectors syntax does not.)

>All of these inconsistencies make it incredibly difficult to implement a
>CSS3 parser from scratch. Is there any plan to rationalize these specs
>against each other? Further, any plan to move the specs into a more
>consistent format such that the module definitions, syntax, and grammar
>are all available in predictable order?

Well, I do plan to plan to make a proposal to encode all the recovery
rules currently specified in prose in the grammar, and would hope the
Working Group resolves contradictions and other problems with it soon;
that would allow you to write a generic and conforming parser based on
a grammar with relative ease, so that is something you could look for-
ward to; but I would not hold my breath on the other things.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 9 December 2010 01:42:23 UTC