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 CSS validator passes the following with no error, Test case 1. @charset"utf-8"; (spec requires a space before open quotes) Test case 2. @charset "utf-8"; (spec requires exactly 1 space before opening double quotes) Test case 3. @charset "utf-8"; (newline instead of space) Test case 4. @charset/**/"utf-8"; Test case 5. @charset "utf-8" ; (illegal space before semicolon) Test case 6. @charset "utf-8" ; (illegal newline before semicolon) Test case 7: /**/@charset "utf-8"; Regards, Cecil Ward.
I assume with "the spec" you mean the CSS 2.1 Working Draft? CSS 2.1 changed the rules for this and the CSS Validator predates those draft rules...
(In reply to comment #1) > I assume with "the spec" you mean the CSS 2.1 Working Draft? CSS 2.1 changed > the rules for this and the CSS Validator predates those draft rules... Good point. Indeed, I was looking at CSS 2.1. But my point stands, because even if you explicitly set the validator to use CSS 2.1, it passes all the above. (I just rechecked.) So it basically can not validate against the 2.1 grammar. As for CSS2.0 (if you like0, I would need to look at the test cases again with CSS2.0 eyes. But presumably having something that is valid only against CSS2.0 but is not actually going to work in (any? some?) browsers isn't useful. Maybe the validator should issue a warning about certain highly questionable forms of css if the user explicitly selects CSS2.0. A further point. If the user has not specified a version of CSS, and the various grammars are in conflict, in the sense that what the user has entered is legal in one version of CSS but illegal in another, then maybe the best thing to do would be to warn the user rather than just saying "valid!" which is meaningless and sort-of dangerous. Suggestion: In the case where the user does not pick as CSS version one possible improvement would be to parse the user's CSS fragment multiple times against the various grammars and if there are both passes and fails, tell the user the details. Warnings about lack of backwards- or forwards capability would be a valuable added benefit of using the validator.
Having taken another look, from a CSS2.0 standpoint CSS 2 section 4.4 states "@charset rule [...] must appear at the very start of the document, not preceded by any characters". So by this paragraph, the validator should report an error in the case where some whitespace and/or a comment, say, precedes the @charset. This is a fault. Because of the restrictive specification of @charset, the CSS validator is not at liberty to pre-strip all comments or strip whitespace in an initial phase before doing futher syntactical analysis. Looking at the output displayed in the case of an error suggests that it may pre-strip comments. As for the CSS2 documents, the restriction expressed in that English sentence is not reflected in the example formal grammar in the CSS2 appendix D, which is too lax.
(removing spam)
As far as I can see all of the above test cases 1-7 are now fixed. We can close this. However, in for example, test case 1 now correctly reports failure, apart from if CSS1 is selected, when it seems to fall over (error message looks strange). Some of the other test cases produce the same weird error if CSS1 is selected. I haven't gone through them all (yet).
Created attachment 528 [details] test case 1
Created attachment 529 [details] test case 2
Created attachment 530 [details] test case 3
Created attachment 531 [details] test case 4
Created attachment 532 [details] test case 5
Created attachment 533 [details] test case 6
Created attachment 534 [details] test case 7
Thanks Cecil for the test cases. I added them into the test suite to make sure we don't have any regression in the future.