26270 2014-07-05 10:55:39 +0000 produce tokens for "/*" and "*/", or define an unclosed comment as a parse error 2014-07-07 06:31:26 +0000 1 1 1 Unclassified CSS Syntax unspecified PC All RESOLVED FIXED http://drafts.csswg.org/css-syntax/#consume-comments P2 normal --- 1 mike jackalmage public-css-bugzilla oldest_to_newest 108734 0 mike 2014-07-05 10:55:39 +0000 The CSS Syntax spec should either produce tokens for "/*" and "*/", or define an unclosed comment as a parse error. For example, I'd like to have the validator produce a message to the user for a case like the following. sizes="(max-width: 30em) 100vw, /* comment I forgot to close (max-width: 50em) 50vw, calc(33vw - 100px)" But the problem is, using a tokenizer conforming to the CSS Syntax spec (or writing one myself), I have no way at all to expose that comment to the validator -- and so, no way to report it to the user. If a conforming tokenizer produced tokens for "/*" and "*/", I'd be able to expose the lack of a "*/" to the validator and report it to the user. Alternatively, if the "Consume comments" algorithm in the Syntax spec explicitly defined a parse error for the case of an unclosed comment, I wouldn't need the comment tokens -- I could just have the validator code catch that error reported by the tokenizer. To be clear, I'm not suggesting that any UA behavior around this should change. I'm not proposing that an unclosed comment should be fatal and cause parsing to fail. I'm just suggesting it could be a "parse error" in the particular technical sense in which that term is defined in the spec at http://drafts.csswg.org/css-syntax/#parse-error 108735 1 dbaron 2014-07-05 14:56:55 +0000 Could it be a tokenization error instead of a parse error? 108738 2 mike 2014-07-05 21:39:01 +0000 (In reply to L. David Baron (Mozilla) from comment #1) > Could it be a tokenization error instead of a parse error? Yeah ideally it should be a tokenization error rather than a parse error -- to the degree that the spec actually makes it possible to define tokenization errors separately. In other words, it should be possible to catch this case just using a conforming tokenizer, without needing a conforming parser. But as far as I can see the current spec doesn't actually define any tokenization errors as such. 108744 3 jackalmage 2014-07-07 02:48:51 +0000 > Yeah ideally it should be a tokenization error rather than a parse error -- to the degree that the spec actually makes it possible to define tokenization errors separately. I've gone ahead and flagged it as a parse error. (It happens during tokenization, but I don't feel like it's important to distinguish in the spec between a term for "errors during tokenization" and "errors during parsing".) > In other words, it should be possible to catch this case just using a conforming tokenizer, without needing a conforming parser. Comments disappear during tokenizing anyway; parsing has an allowance for keeping them around, but requires that they be ignored for the purpose of actually running the parser. > But as far as I can see the current spec doesn't actually define any tokenization errors as such. Didn't think any were needed (CSS doesn't have very much in the way of error-correction, just error-recovery and auto-closing of things at EOF), but let me know if there's anything obvious I can add that'll make it easier for you.