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

Re: small errors in the CSS2.1 grammar

From: Bert Bos <Bert.Bos@sophia.inria.fr>
Date: Sun, 19 Jan 2003 15:16:25 +0100 (CET)
cc: www-style@w3.org
Message-ID: <Pine.LNX.4.05.10301191348250.29578-100000@lanalana.inria.fr>

On Thu, 16 Jan 2003, Etan Wexler wrote:

> Bert Bos wrote to <www-style@w3.org> on 16 January 2003 in
> "Re: small errors in the CSS2.1 grammar"
> (<mid:15909.41277.742778.916100@lanalana.inria.fr>):
> 
> > Lars Knoll writes:
> [...]
> >> In khtml, I've gone back to the CSS1 grammar for the definition of comments.
> 
> > They are supposed to be equivalent, so that should be OK.
> 
> The CSS1 comment syntax specification has three parts and requires the
> maintenance of state. I am unfamiliar with flex, so I do not know if
> the variants truly are equivalent.
> 
> Is the following valid a valid level 1 style sheet?
> 
> /* This comment has no closing delimiter.

You are rignt, they are not equivalent if "/*" is used without a matching
"*"/.

In the CSS1 grammar, a comment can be ended by the end of file, and thus
your unclosed comment gobbles up everything until the end of the file. But
in CSS2, a "/*" must have a "*/", otherwise it is seen as two tokens "/"
and "*". Thus your example would be subject to the forward compatible
parsing rules and might still pick up some well-formed rules further down.

Now, the above interpretation follows from the way the grammar is written
and it is not clear that the grammar in CSS1 matches what the English text
says. There is no hint that "/*" might be matched by an end of file
instead of "*/". It would also seem a rather unelegant and pointless
syntax. I'd say therefore that the grammar in CSS1 is improvable.

As one of the authors, that is also how I remember it: an unclosed comment
is an error, therefore your examples file is not CSS and the spec doesn't
apply. We don't care what a UA does with it and the grammar wasn't written
with error handling in mind.


Btw., the CSS WG is currently having some discussions about the
desirability of adding error-handling rules to CSS. Two different browsers
would then give the same result, even if the style sheet is syntactically
incorrect. (Note that this is different from the forward-compatible
parsing rules, which only deal with syntactically correct files that
happen to contain semantic features from a different CSS profile.)
Depending on what the error-correcting rules are, you could then, e.g.,
send certain HTML files with embedded style sheets as text/css files and
the browser would find (most of) the style sheets.

On the other hand, is there any real benefit in allowing syntax errors and
do we really want to limit what kind of parser a UA uses?



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Sunday, 19 January 2003 09:16:27 GMT

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