Re: CSS parser recovery

Ian Hickson wrote to <www-style@w3.org> on 23 December 2002 in
"CSS parser recovery"
(<mid:Pine.LNX.4.21.0212140925590.21095-100000@dhalsim.dreamhost.com>):   

> We already know the syntax isn't valid, that's why we're looking at this
> in the first place.

If the data are not valid according to a specific level of or profile
of CSS, we fall back on the core grammar.  If the data are not valid
according to the core grammar, what we have is not CSS.  The user
agent is then free to take any course of action (or of inaction).

[Tantek Çelik:]

>> The spec allows for (nested) block(s) after an @rule, a selector, and in a
>> value and nowhere else.

[Ian Hickson:]

> Sure. But if you find one there _anyway_, then you have to parse it
> [as] a nested block, because a declaration block is a block, and:

> # A block starts with a left curly brace ({) and ends with the matching
> # right curly brace (}). In between there may be any characters, except
> # that parentheses (()), brackets ([]) and braces ({}) always occur in
> # matching pairs and may be nested.

You are using the prose but ignoring the grammar.  In the core grammar
given in CSS2 (<http://www.w3.org/TR/REC-CSS2/syndata.html>), a
declaration block differs from other blocks.  Its contents are a
series of zero or more semicolon-separated declarations.
Declarations, like Tantek Çelik wrote, may contain blocks only in
their values.  A would-be block just after a would-be property name
stops normal parsing.  Anything, including additional parsing, that
the user agent does after normal parsing is the error recovery chosen
by the user agent.   

-- 
Etan Wexler <mailto:ewexler@stickdog.com>

Received on Wednesday, 25 December 2002 05:35:10 UTC