W3C home > Mailing lists > Public > www-style@w3.org > January 2008

[CSS 2.1] General at-blocks and error recovery

From: Justin Rogers <justrog@microsoft.com>
Date: Sat, 26 Jan 2008 20:20:56 -0800
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D49A94E5E0C@NA-EXMSG-C104.redmond.corp.microsoft.com>
An at-block is defined as an @ symbol followed by a valid identifier. When you see an at-rule you don't know, you eat until you see a semi-colon or your process the next block whichever comes first. That is definitely clear. It would then mean for a parser/tokenizer implementation something like the following:

@import == (known symbol TOK_ATIMPORT)
@foo == (unknown but valid TOK_ATWELLFORMED)
@ == (hum, something is wrong, no valid character TOK_UNKNOWN perhaps)
@1 == (another bad one, this is kind of like @{name}, could be TOK_UNKNOWN followed by some series of additional tokens which are semantically invalid during the error recovery).

The rules for recovering in a style sheet when you have an unknown token are to eat the next block. This means if you had the following CSS:

DIV { color: green; }

Then you would expect the DIV rule to get thrown out. However, if you treat @1 like an actual at rule, then you could technically start your reparse at the semi-colon. Browsers again disagree with FireFox/Opera eating the entire declaration while Safari is perfectly happy going into at rule error recovery instead. Here is a full sample:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

DIV { color: green; }


I'm guessing now that I'm a fan of the FireFox/Opera method here. The @ character by itself without a valid identifier following it should be an unknown token of some sort and you should go into general error recovery and eat the following block. Would be nice to get clarification here since Safari deviates from this pattern.

Nicely enough if the oddly formulated at-rule(s) follow themselves with a block {} then everything is forgiven. However, the token stack can get blown away easily depending on the browser such that the following rule will continue to show text in black on FireFox but Opera will now get confused and render the text in green.

@1 [ { } ]
DIV { color: green; }

Note: This analysis was put together hastily and I may have made some minor mistakes in my testing. I use the Safari for Windows 3.0.4 currently for any testing and not the latest builds. Opera version is 9.50 beta. FireFox is v3 beta 2.

Justin Rogers [MSFT]
Received on Sunday, 27 January 2008 04:21:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC