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

Re: [CSS 2.1] General at-blocks and error recovery

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 26 Jan 2008 23:39:15 -0800
Message-ID: <479C3523.8040606@inkedblade.net>
To: Justin Rogers <justrog@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>

Justin Rogers wrote:
> 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: 
> 
> @1;
> 
> 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.

Recorded as CSS2.1 Issue 32:
   http://csswg.inkedblade.net/spec/css2.1#issue-32

I'll be waiting for Bert and dbaron's takes on this and issue 31 before
suggesting them for the telecon agenda.

~fantasai
Received on Sunday, 27 January 2008 07:39:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:00 GMT