Re: CSS parser recovery

On Sat, 14 Dec 2002, Tantek Çelik wrote:
> 
> It causes the declaration to become illegal (per the property :
> value definition of declaration), and thus the declaration is
> ignored.

Yes, we agree with that. What I don't agree about is that you drop the
brace, rather than trying to match it. The spec seems to quite clearly
say that braces in blocks should always be matched.


>> no[r] any part of the spec that says that the definition of "block"
>> should be ignored for declaration blocks.
> 
> That's what more specific rules do, they tell you what to do more
> specifically than generic rules.

Yes. But they don't automatically mean that the generic rules that
_aren't_ overridden _don't_ apply. Specifically, since the rules for
declaration blocks don't say what to do with unexpected braces between
property identifiers and colons, you fall back on the generic rule,
which says to parse it as a nested block.


> I can quote them again if it helps:
> 
> CSS 7.1:
> 
> <blockquote>
> A declaration consists of a property, a colon (:) and a value.
> </blockquote>
> 
> Note - no allowance for a block in the property, or after the
> property before the colon.

Indeed. No allowance for a missing colon either, nor a number, nor a
quote, nor any number of other things.

Thus, that part of the stylesheet ("property {") is invalid, and you
fall back on the generic parsing rules, which say to walk the data
matching braces, etc, until you hit the end of the declaration.


> <blockquote>
> Around each of these there may be whitespace.
> </blockquote>
> 
> Explicit allowance of whitespace, but NO allowance of a block.

Agreed, a block is illegal here. So if you find one, you follow the
generic rules (parse nested block) then ignore the declaration.


> <blockquote>
> A property is an identifier, as defined earlier.
> </blockquote>
> 
> And identifiers as defined earlier CANNOT contain blocks.

Indeed, as "{" is not a valid character in an identifier. (And and
escaped "{" doesn't start a block).


> <blockquote>
> Any character may occur in the value, but parentheses (()), brackets ([]),
> braces ({}), single quotes (') and double quotes (") must come in matching
> pairs.
> </blockquote>
> 
> Aha! Explicit allowance for a block in the value, and only the value
> portion of the declaration.

It does NOT say _only_. It just happens to say that a value may be any
number of things. The spec also says to look at individual properties
to work out exactly what is allowed and what isn't. And as it turns
out, no property allows a nested block. But, as with _any_ block, per
the definition of a block, if you hit a brace, then you parse until
you hit the matching end brace.

Just because it explicitly mentions this for values does _not_ make it
any less true for any other part of the block.


>> Well given that my interpretation is _at least_ as valid as yours,
>> and arguably (IMHO) more valid, and in addition more flexible, I
>> don't see any reason to prefer your interpretation.
> 
> My interpretation interprets the specific rules more strictly, and
> is thus preferable from a stricter interpretation point of view and
> thus arguably (IMHO) more valid.

Sorry, but that's not true. Your interpretation tries to read into the
spec rules that IMHO simply aren't there.


> At this point I see more value in not breaking at least two
> implementations that have been (arguably) compliant with this
> portion of the spec for quite some time, rather than allowing for a
> theoretical only useful ability to extend CSS to allow blocks on the
> property side.

At this point I see more value in not breaking at least three
implementations (including the market leader) that have been
(arguably) compliant with this portion of the spec for quite some
time, as well as allowing for future expansion.

Thus I would prefer the spec to explicitly state that blocks should be
parsed on the property side just like they are anywhere else.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 14 December 2002 06:20:37 UTC