[css-counter-styles] The entire rule being invalid vs. not defining a counter style when name/descriptors are wrong

[xiaochengh]

#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?

[andruud]

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]

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.