[css3-syntax] Separation of concerns: "declaration/rule-filled", "can be made important"

Hi,

I think that CSS tokenization and tree construction should not depend on 
complex knowledge of other CSS modules. This is basic separation of of 
concerns, and our current charter also suggests that CSS syntax should 
be independent from the rest of CSS:

http://www.w3.org/2010/09/CSSWG/charter

I find two points in tree construction as it currently stands where this 
is not quite the case:

1. How to decide whether a given at-rule is "declaration-filled", 
"rule-filled" or neither.
2. How to decide whether a given declaration "can be made important".


Is it guaranteed that an at-rule’s name (its at-keyword) is and will 
even be enough to decide 1.? In other words, 1. does not depend on the 
at-rule’s context/parent or its prelude.

If this is the case, tree construction could take a list of at-rule 
names that information[1] as part of its "input", in addition to a list 
of tokens and a quirks mode flag. The introduction of §3.5. Tree 
Construction should be updated in that direction.

[1] A mapping of at-rule names to declaration-filled/rule-filled/neither


As to declarations that can be made important, I see two options:

a. Specify that style rules contain property declarations (that can be 
made important). For at-rules, refine the "declaration-filled" concept 
into "property-filled" or "descriptor-filled". This implies that 
at-rules can not contain both property declarations and descriptor 
declaration, and that this can be decided based on the name (at-keyword) 
only, as above.

b. Get rid entirely of the "can be made important" concept. Leave it to 
higher-level parsers to reject a declaration (just like `width: red` is 
rejected as invalid) if it has the important flag but can not be made 
important.

I’m not aware of a anything in CSS that uses the style rule syntax (not 
at-rule) and contains descriptors (that can not be made important), but 
note that a. prevents using such syntax in the future.

-- 
Simon Sapin

Received on Saturday, 26 January 2013 18:04:05 UTC