Re: Error Parsing

> p {
>   color: red;
>   /*
>   font-size: 12pt;
... 
> According to CSS21 parsing rules, it must be:

That really depends on whether you treat it as being a broken comment at
the lexical level or as a non-comment token followed by other tokens.
This is a lexical error rather than a parsing error.

In practice, one of the key design criteria for both computer and human
languages is that ambiguities should be resolved very soon after they
arise, so, to me the only reasonable way of treating this is to assume that
you are dealing with a comment and proceed on that basis until 
contradicted, thus causing the whole of the balance of the sheet to be
eaten, in this case.

> 
> However, I'm wondering if this is what the general user expects from the
> code given. Can this still be grasped (rather) intuitively without having

The general user shouldn't expect anything other than that it may not work
exactly as intended and that if they use a proper validation tool, an
error will be reported (at the end of the file, and possibly also with
a reference to the start of the open comment).  These rules are not there
for the benefit of general users; they should write correct CSS in the first
place, or use tools designed for finding errors in the version of CSS
that they use, not ones designed to be future proof.

> to delve into the CSS parsing spec? I, for one, would have expected at
> first glance the result to be the empty stylesheet based on the comment
> open character sequence "/*" (as - IMO wrongly - does the W3C CSS Validator).

I think the validator is correct if it treats this as an unterminated
comment.

Received on Saturday, 23 October 2004 07:50:02 UTC