- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Wed, 20 Feb 2013 07:03:38 +0100
- To: www-style@w3.org
Hi, Based on recent threads, here is what I believe are the new issues on css3-syntax that have not yet been addressed. These are only summaries. Please see the discussions in the linked threads. Beware: my opinion affects the writing style of each entry. I believe that none of these should block a new Working Draft. They can always be resolved afterwards. None of the editorial stuff requires conf call time, nor does 7. (which is up to SVG WG, not us. Does that mean it’s time to talk to them?) Of the rest, I believe that 2. 6. and 11. are the least obvious. http://lists.w3.org/Archives/Public/www-style/2013Feb/0278.html 1. Perhaps for team-legal rather than this WG? When a spec contains detailed algorithm in English, implementing it may look like "translating" it to a computer language, similar to translating the spec to another human language. Clarify that implementing is not a "derivative work" forbidden by the W3C Document License? http://lists.w3.org/Archives/Public/www-style/2013Feb/0402.html 2. Possible security issue: Taking the stylesheet’s character encoding from the referring document should be same-origin only. 3. Editorial: get rid of §3.2.1. "Preprocessing the input stream" by doing the same work in the tokenizer? 4. Editorial: The tokenizer would be nicer (and could be less redundant) with a style closer to that of the parser: a bunch of "functions" that call each-other rather than a state machine. (Not quite "recursive decent" though, there is no recursion.) 5. Editorial: use more look-ahead to avoid "reconsuming"? 6. *-match tokens: maybe add now tokens for !#%+./?@ (each follow by = equal sign) in addition to the current ~|^$* so that future additions to Selectors don’t need to add new tokens. Maybe have a single "match" token with a character value (like delim) rather than many tokens. 7. *If* SVG2 wants some of its attributes values to have CSS syntax *but* not allow CSS comments, add a "no comment" flag to the tokenizer. Tab and I would rather just allow comments, though, if that’s not a web-compat issue. 8a. Should EOF in quoted strings or urls not be an error at all, to be consistent with the rest of the "unexpected EOF" rules? 8b. (Special case of the above) §4.2 of CSS 2.1 has an example where EOF in a string as acceptable, in contradiction with its own Core Grammar in §4.4.1 where it’s a bad-string token. 9. There is concern with bad-string and bad-url being "preserved". (Should always be errors caught as early as possible?) But I don’t see how to do this while enabling Media Queries’s fine-grained error handling. 10. Editorial: §4.4.12 has some redundant checks, since this mode is only ever entered in specific cases. 11. Apparently SVG requires scientific notation not only for numbers (which we now have in CSS) but also for percentages and dimensions. 12. Some concern about changes in bad-url tokenization. Did non-WebKit implementers discuss it? (No opinion from me.) 13. Proposal: make at-rule syntax completely generic: get rid of the "recognized at-rule", "declaration-filled" and "rule-filled" concepts. Parse ';' or a generic {} block for at rules. Definitions of specific at-rules can call back into Syntax with one entry point or another to parse the contents of a {} block. 14. Editorial: Non-normative prose describing error recovery would be nice. (Like the diagrams describe valid syntax.) 15. Quirks mode and transform function whitespace do not belong in the generic Syntax module, but in the grammar of the relevant attributes/properties. 16. Maybe an+b belongs in Selectors rather than Syntax? http://lists.w3.org/Archives/Public/www-style/2013Feb/0451.html 17. Hash tokens need a new "is a valid ident" for ID selectors. The edit is not trivial: if 4. or 5. are to happen, might be better to do this afterwards or at the same time. -- Simon Sapin
Received on Wednesday, 20 February 2013 06:04:04 UTC