Repository navigation
[css-counter-styles] The entire rule being invalid vs. not defining a counter style when name/descriptors are wrong #5717
Description
#1682 (comment) resolved that:
RESOLVED: treat invalid counter styles the way we treat invalid font faces
The spec change log says:
@counter-style rules that are invalid due to missing descriptors just fail to create a counter style; they’re otherwise still valid rules.
I understand these resolutions as: if a @counter-style rule has wrong descriptors, it should still be parsed into a valid rule and appear in the OM; it only fails to create a counter style and hence do not affect any counter.
However, the current spec text makes the entire @counter-style rule invalid in some cases:
If the system is cyclic, the symbols descriptor must contain at least one counter symbol, or else the @counter-style rule is invalid.
If the system is fixed, the symbols descriptor must contain at least one counter symbol, or else the @counter-style rule is invalid.
If the system is symbolic, the symbols descriptor must contain at least one counter symbol, or else the @counter-style rule is invalid.
If the system is alphabetic, the symbols descriptor must contain at least two counter symbols, or else the @counter-style rule is invalid.
If the system is numeric, the symbols descriptor must contain at least two counter symbols, or else the @counter-style rule is invalid.
If the system is additive, the additive-symbols descriptor must contain at least one additive tuple, or else the @counter-style rule is invalid.
If a @counter-style uses the extends system, it must not contain a symbols or additive-symbols descriptor, or else the @counter-style rule is invalid.
Should they be revised into not defining a counter style?
Activity
andruud commentedon Nov 12, 2020
I'd interpret "invalid" in "or else the @counter-style rule is invalid" to mean "does not define a counter style", but I suppose it could be interpreted both ways. In general it would be nice to have a clearer distinction between "invalid at parse-time" and "invalid at @-rule interpretation-time". There are other @-rule-defining specs that have the same problem as well.
tabatkins commentedon May 13, 2021
Saying that a construct is "invalid" always means at parse-time by default. That said, we resolved that this should instead just prevent the rule from defining a counter style, so I've removed the language saying it's invalid, and adding some more detail to the 'system' section about what the requirements are and what they mean.