This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See bug 4870, test case _#2_ (which was noted as being ok back then), In the live development build http://qa-dev.w3.org:8001/css-validator/#validate_by_input this test case INCORRECTLY causes a parse error to be reported as of 2008-03-23, yet the public css validator behaves correctly. So there is a (potential) regression. CSS fragment: a /**/> b { width:0} I believe that this is valid CSS2.1. (At least, according to the new interpretation in the CSS2.1 errata http://www.w3.org/Style/css2-updates/CR-CSS21-20070719-errata.html ) Best, Cecil Ward.
The latest patch should resolve that issue, and consider in general SP followed by a comment as a SP (per CSS21 spec). http://qa-dev.w3.org:8001/css-validator/ updated. Thanks,
I have to reopen this one, as qa-dev.w3.org now gives: Parse Error > b
Created attachment 620 [details] test case
Hum... I see why. COMMENT has been declared as a special token to be able to detect its presence in @charset and report it. In the case of the combinators, it generates a match because of this: ( ( <PLUS> { connector = '+' ; } | <GREATER> { connector = '>' ; } | <TILDE> { connector = '~' ; } ) ( <S> )* | ( <S> )+ { connector = ' ' ; } ) Doing a/**/ > b will work, as the special token is there before a <S> is parsed, however in the a /**/ > b case, the special token forces the match (<S>+) and exist form the combinator matching part. More in this soon (I hope).
One possible fix would be to replace < #_S : ( [ " ", "\t" , "\n" , "\r", "\f" ]+ ) > by < #_S : ( [ " ", "\t" , "\n" , "\r", "\f" ] ) ( <COMMENT> | [ " ", "\t" , "\n" , "\r", "\f" ] )* > @charset check will still work, comment is still detected when no space is before it, and it fixes this issue. However, we should do more regression check to ensure that this workaround will work.
Also in the tests, we should add a /**/ /**/> b { color: green } which should be reported as valid. (and incorrectly reported invalid by both the production and dev version of the validator).
Fixed on qa-dev.w3.org (change to the grammar seems in sync with the scanner definition of comment handling)
(In reply to comment #7) > Fixed on qa-dev.w3.org (change to the grammar seems in sync with the scanner > definition of comment handling) Agreed. Not only does it seem that this one issue is now fixed, but the grammar change mentioned earlier, which takes a brute-force approach to making comments go away when adjacent to whitespace, is a good thing everywhere surely. It seems that the fix has been done without causing damage to the strict requirements of @charset, which is now appears to be parsed, as it needs to be, very much as a special case, more like an atomic unit, an approach which will make @charset safe from changes elsewhere in the grammar.