- From: <bugzilla@jessica.w3.org>
- Date: Mon, 07 Jul 2014 02:48:51 +0000
- To: public-css-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26270 --- Comment #3 from Tab Atkins Jr. <jackalmage@gmail.com> --- > 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 7 July 2014 02:48:53 UTC