This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The CSS2.1 spec says that comments can appear between any two tokens. In this CSS stylesheet: http://www.mit.edu/~cananian/tsE/stylesheet.css The CSS validator complains about the context "ieMacOnly" which is the following code (an unfortunately necessary workaround for an IE/Mac bug): /* \*/ ieMacOnly /**/ * html #sidebar { position: absolute; top:175px; left:0; margin-left: 0; } This should be parsed as the selector: ieMacOnly * html #sidebar but the CSS validator is choking on it. (There's also some CSS which is *actually* invalid in that stylesheet, in the "#beaver" context, which is an evil microsoft-specific style needed to get transparent PNGs to work. That has no impact on the actual bug discussed above.) The URLs cited in this bug report are temporary; email me if they have disappeared by the time you are looking at this bug.
(In reply to comment #0) > The CSS2.1 spec says that comments can appear between any two tokens. > In this CSS stylesheet: > http://www.mit.edu/~cananian/tsE/stylesheet.css > The CSS validator complains about the context "ieMacOnly" which is the > following code (an unfortunately necessary workaround for an IE/Mac bug): > /* \*/ ieMacOnly /**/ > * html #sidebar { position: absolute; top:175px; left:0; margin-left: 0; } > This should be parsed as the selector: > ieMacOnly * html #sidebar > but the CSS validator is choking on it. > (There's also some CSS which is *actually* invalid in that stylesheet, in the > "#beaver" context, which is an evil microsoft-specific style needed to get > transparent PNGs to work. That has no impact on the actual bug discussed > above.) > The URLs cited in this bug report are temporary; email me if they have > disappeared by the time you are looking at this bug. Minimal test case: I note that the validator gives an "incorrect" fail on test case (ii): a /**/ b {} which is legal CSS 2.1 (according to my reading, although the distribution of comments is unfortunately not described adequately in the "formal" grammar in the appendix). FYI, note that the validator correctly indicates success on test case (iii): a/**/ b {} It is possible that the "fault" in the validator might be to do with parsing (ii) as "ident combinator combinator ident" where combinator=SP+ (ie descendant operator), which is illegal in terms of the grammar in the appendix. This suggests that the grammar of CSS is self contradictory, that the statement "whitespace may occur between any two tokens" is unsupportable, as effectively comments may not occur in this position in selectors. If my understanding turns out to be correct this is bad language design and the validator is correctly interpreting a poor grammar. One way out would be to do something like define a comment as {w}*COMMENT in CSS2.1 (similar to COMMA) possibly? [An aside, I note that test case (iv) a/**/b {} is rejected if CSS2.1 is the selected grammar, which seems to be an error in the validator contradicting CSS2.1 in that a comment ought to be mapped into whitespace, not into null, so a comment should equal a combinator=descendant operator in this position. If my understanding is correct, this is a separate fault, and should be reposted separately. I unclude this here for some background. This affects a number of other situations and is critical for interpretation, ie. is [attr1]/**/[attr2] read as [attr1] [attr2] or as [attr1][attr2] ? - which mean completely different things!.] Cecil Ward.
(In reply to comment #1) > test case (ii): > a /**/ b {} > which is legal CSS 2.1 (according to my reading, I correct myself. I should have written, we would _like this to be_ legal CSS 2.1 in line with the principle that comments ought to map to whitespace. Cecil Ward.
(In reply to comment #1) Once again, I correct myself. I re-read the lexer specification from CSS2.1 april 2006 and I notice the rule that includes a preceding {s}+ as part of a comment specification. So the authors are ahead of me. The rule immediately above - a comment token alone - suggests that comments are not equal to whitespace. (Which means I had been very wrong earlier.) Rather whitespace+comment == whitespace. Yet there is no corresponding rule for to cater for the case comment+whitespace, rather we have comment+whitespace->whitespace whitespace. This suggests that an additional rule (or possibly two rules) would fix the problem and there are various choices. I should not have said that the distribution of comments is not well described, as with a few fixes of this kind comments would really disappear from the grammar and it would almost be well described. We would also have to watch out for the special case of css2.1 @charset (ought that to go into the lexer?) as making comments disappear completely surely permits various illegal @charset forms which contain comments (since we can't attempt to put the entire @charset and its argument into the lexer as a single token surely). If that can be fixed, then I think we have won.
All the examples below are now parsed as they should. See http://qa-dev.w3.org:8001/css-validator/