[css3-syntax] Digest of remaining issues from recent discussions

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