W3C home > Mailing lists > Public > www-style@w3.org > December 2002

Re: CSS parser recovery

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 14 Dec 2002 09:50:29 +0000 (GMT)
To: Tantek Çelik <tantek@cs.stanford.edu>
Cc: "www style w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.21.0212140937380.21095-100000@dhalsim.dreamhost.com>

On Sat, 14 Dec 2002, Tantek Çelik wrote:
>> We already know the syntax isn't valid,
> 
> Not true.  We know that the portion up to the property _is_valid_, that's
> why we're following the specific rules for parsing declarations, rather than
> the rules for parsing unknown @rules (and certainly not the rules for
> parsing unknown values).

I don't see why those rules would be different. (And I disagree that the
spec says that they are: the bits you quote seem to me to be saying "this
is what you should write" not "this is what you should parse".)

If you read the part of the spec you quoted and ignore the generic
definition of "block" then the CSS we are talking about,

    a { b { c } }

...is unpareasble, because after "b" the only allowed token is a colon.

Since it isn't a colon, you know the sheet isn't valid, and you fall back
on the generic syntax.


> The specific rules for parsing a declaration block override the generic
> rules for parsing a block. 

Even if they did, they don't cover this case.

But I don't think they do, I think they are merely a superset.

Otherwise, you end up with the situation where the following:

   @foo { a { b: c; } }

...is one block, but the following:

   Ofoo { a { b: c; } }

...is a block followed by an unexpected '}' token.

And I cannot see any way that that is desirable.

Also, your way makes it impossible for us to extend CSS to allow blocks on
the property side, as in:

   h1 {
    font-size { minimum, preferred, maximum }: 9px, 16px, 72px;
   }

...or whatever.


> And in a declaration block a property is an identifier which cannot
> contain a block

Well of course an identifier cannot _contain_ a block. But it can be
followed by one, that just means the stylesheet isn't a CSS1-only
stylesheet, and everything up to the end of the declaration, passing all
nested brackets, braces, parenthesis and treating quotes as delimiting
strings, should be ignored.


> and thus the open brace following the property name simply causes the
> declaration to be ignored, without opening a block.

I don't see any reasoning for that conclusion in the spec. Nowhere does it
mention ignoring a brace. It goes to great lengths to say that braces have
to nest correctly, in fact.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 14 December 2002 04:50:31 GMT

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