W3C home > Mailing lists > Public > www-style@w3.org > May 2009

[CSS 2.1] Parsing unexpected atkeywords

From: Bert Bos <bert@w3.org>
Date: Wed, 20 May 2009 15:48:46 +0200
To: W3C style mailing list <www-style@w3.org>
Message-Id: <200905201548.46925.bert@w3.org>
This is an attempt at solving issue 71[1]. Or rather, at finding out if 
there still is anything to solve...

* Analysis

A "declaration block" in CSS is a part of a rule set and consists of a 
set of declarations plus the curly braces ({}) that surround the set. 
According to the grammar, it is impossible that an ATKEYWORD occurs in 
a declaration before the colon (:).

The @page rule, although not appearing as such in the grammar, is 
defined in section 13.2[2] as also containing a declaration block.

Until CSS 2.1, there were no rules for how to deal with ungrammatical 
input, but now we have a number of error recovery rules to try to 
salvage the more or less recognizable parts of illegal input.

One of those rules applies in this case, viz., the rule 
called "malformed declarations" in section 4.2[3]. It says, simplified, 
to skip to the next semicolon (;) or the end of the block (}) and 
restart parsing from there.

E.g., the second line in this example

    @page {
      size @import "foo";
      margin: 1cm
    }

has an ATKEYWORD ("@import") where a colon should have been and thus 
everything from the start of that declaration ("size") up to and 
including the next semicolon is ignored. Parsing starts again 
at "margin". (Like all error recovery, this is a wild guess; we cannot 
know what the actual error is that the author made.)

Issue 71 talks about two cases: the ATKEYWORD appears at the start of a 
declaration (i.e., where a property was expected), or it appears after 
the property.

The example above shows the latter case. It is clear that the "malformed 
declarations" rule applies to that case. The rule says "unexpected 
tokens while parsing a declaration" and the when the parser 
reaches "@import" it has clearly started parsing a declaration.

The former case would be something like this:

    div { @here {is something strange} color: red }

The question is if the same rule applies. Is the parser parsing a 
declaration when it sees the "@here"? If yes, the rule says that 
everything up to and including "red" is ignored.

I would say yes. At least I think that is the intention of the rule. The 
rule contains an example ("For example, a malformed declaration may be 
missing a property [...]"), which indicates that the parser is already 
parsing a declaration, even if it hasn't yet seen a property.

* Conclusion

So my conclusion is that issue 71 is already covered by the "malformed 
declarations" rule in section 4.2. No changes are necessary in 
principle.

But the existence of the issue seems to indicate that the rule is not 
clear, so maybe an example can be added. The following could be added 
as the eighth and ninth examples:

    p { color: green; @foo color: red} /* unexpected token @foo */
    p { color: red; @foo; color: green} /* unexpected token @foo */

* Implementation status

A quick check indicates that Konqueror, Opera and Firefox correctly 
apply the "malformed declarations" rule. I haven't tested any other 
software. But given that the current formulation has been unchanged 
since 2003, I expect few problems.


[1] http://wiki.csswg.org/spec/css2.1#issue-71
[2] http://www.w3.org/TR/2009/CR-CSS2-20090423/page.html#page-box
[3] 
http://www.w3.org/TR/2009/CR-CSS2-20090423/syndata.html#parsing-errors



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 20 May 2009 13:49:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT