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

RE: [CSS 2.1] Request for links to additional error recovery parser tests

From: Justin Rogers <justrog@microsoft.com>
Date: Wed, 2 Jan 2008 13:52:34 -0800
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D49A5F027B8@NA-EXMSG-C104.redmond.corp.microsoft.com>

If we added some text into error recovery that the following tokens ([{}]) are scope tokens (or come up with some name for them, maybe block tokens). Any open scope token begins a new scope by pushing the token onto a scope stack. When a new end scope token is reviewed it is compared against the top of the stack and if present ends the nested scoped. If not present the end token is processed by no scope changes are made. If the end token is somehow allowed by the parser then it may be read otherwise it is treated as an invalid token and error recovery specific to the current context is used.

At the tokenization level there is nothing special about scope tokens. They just show up as tokens. At the parser level they can either be treated as a token or they can start/end a scope depending on their context. In most cases when a parser ends the scope there will be some scope closure logic (close any open declaration for example), however, in the style case being discussed there isn't an open { on the stack and the } will simply be a token to be processed as part of the declaration and so would fail. We'll go into basic error recovery and find the ;.

I think based on the current spec state parsers get written that look for [!;}EOF] when parsing declarations and so they can allow two possibly bad behaviors. (Note this is empirical understanding based on test results of various implementations.) The first is that they will treat the } as and end of declaration for the style attribute block effectively treating it like it was a semi-colon. The second is that they may close a scope (that was never opened) and stop parsing the attribute altogether. Style attributes could be specified as --> S* declaration [ ';' S* declaration ]* <-- which has no syntax for the } character, or they should be treated as an open ruleset which can't be closed (meaning seeing a } wouldn't close the ruleset because it can't be closed). I'm not generally sure how these syntax measures would be described by the spec so I've simply given two options.

Justin [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Wednesday, January 02, 2008 11:11 AM
To: www-style@w3.org
Subject: Re: [CSS 2.1] Request for links to additional error recovery parser tests

Justin Rogers wrote:
> I've done some basic homework and pulled up a few of the public suites
> for error recovery but nothing shows up as really complex. I'm
> specifically trying to find test cases for matching pairs of
> braces/blocks/parens.
> style="color: red }; background-color: green;"
> Opera/Safari treat the } as the end of the style block. Perhaps by
> implying a { at the beginning, but they don't parse after the } at all.
> FireFox will throw out the color: red and apply the background-color:
> green as if it realizes color as an invalid property.
> IE 7 and less will apply both properties.

Recorded as CSS2.1 issue 25:

I think the } should be treated as an invalid token.

Received on Wednesday, 2 January 2008 21:52:50 UTC

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