5586 2008-03-23 06:59:34 +0000 Comment in selector before > operator - [regression!] - in development snapshot only 2009-02-17 14:54:01 +0000 1 1 1 Unclassified CSSValidator CSS 2.1 CSS Validator PC Windows XP RESOLVED FIXED P2 normal --- 1 cecil dave.null ot www-validator-cvs oldest_to_newest 19600 0 cecil 2008-03-23 06:59:34 +0000 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. 19616 1 ylafon 2008-03-26 21:00:37 +0000 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, 23214 2 ot 2009-01-21 21:14:03 +0000 I have to reopen this one, as qa-dev.w3.org now gives: Parse Error > b 23215 3 620 ot 2009-01-21 21:15:15 +0000 Created attachment 620 test case 23480 4 ylafon 2009-02-05 17:37:18 +0000 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). 23490 5 ylafon 2009-02-05 22:11:44 +0000 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. 23491 6 ylafon 2009-02-05 22:43:20 +0000 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). 23495 7 ylafon 2009-02-06 10:28:02 +0000 Fixed on qa-dev.w3.org (change to the grammar seems in sync with the scanner definition of comment handling) 23792 8 cecil 2009-02-17 14:54:01 +0000 (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. 620 2009-01-21 21:15:15 +0000 2009-01-21 21:15:15 +0000 test case 5586.css text/css 22 ot YSAvKiovPiAgYiB7IHdpZHRoOjB9Cg==