You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-counter-styles] Clarify what to do when 'symbols' has only one symbol for 'alphabetic' and 'numeric' systems? #5698
The @counter-style rule must have a valid symbols descriptor...; otherwise, the @counter-style does not define a counter style (but is still a valid at-rule).
Some counter systems specify that the symbols descriptor must have at least two entries. If the counter style’s system is such, and the symbols descriptor has only a single entry, the descriptor is invalid and must be ignored.
What exactly does "the descriptor is invalid and must be ignored mean"?
This is a parse failure of the declaration, and the previous symbols declaration should be used. So we end up using symbols: 'A' 'B'. This is difficult to implement, though, as the parsing of one descriptor will depend on another descriptor. I'm not sure if anywhere else in CSS has such behavior.
The parsing of symbols strictly follows the syntax <symbol>+, so that we end up using symbols: 'X'. It has one symbol, and therefore the @counter-style does not define a counter style. This is Firefox's current behavior
I suggest we revise the spec and clarify that we follow the second behavior, because it's the only implemented behavior, and it's easier to implement.
My intention was "parse failure" (that's how that phrasing is consistently interpreted everywhere), but I'm okay with changing to Firefox's behavior and making the spec clearer in that regard.
where the initial-value: 1 is invalid according to the syntax: "<length>" grammar. Then the entire @property rule is invalid, it doesn't fall back to initial-value: 1px.
Oooh, that's a good question. @Property currently says it makes the rule invalid, which presumably means it doesn't show up in the OM. I don't have time to test whether that actually happens atm, but we shoudl be consistent between these two.
I suggest we revise the spec and clarify that we follow the second behavior, because it's the only implemented behavior, and it's easier to implement.
+1, we should avoid parse-time behavior of one descriptor being affected by another descriptor, any complicated "validation" of the rule as a whole should happen at "@-rule interpretation time" (or whatever we want to call that). I didn't even raise an issue for this for @property, I thought it was a given. 🤷♂️
Makes sense, I've clarified that paragraph that failing to meet the minimum symbols length just means you don't define a counter style; nothing is invalid.
Activity
tabatkins commentedon Nov 5, 2020
My intention was "parse failure" (that's how that phrasing is consistently interpreted everywhere), but I'm okay with changing to Firefox's behavior and making the spec clearer in that regard.
Loirooriol commentedon Nov 6, 2020
I guess an analogous example is https://drafts.css-houdini.org/css-properties-values-api/#initial-value-descriptor
where the
initial-value: 1is invalid according to thesyntax: "<length>"grammar. Then the entire@propertyrule is invalid, it doesn't fall back toinitial-value: 1px.tabatkins commentedon Nov 6, 2020
Yeah true, so indeed, let's make the whole @counter-style rule invalid as well.
xiaochengh commentedon Nov 7, 2020
Is there a difference between "making the whole @counter-style rule invalid" and "the @counter-style rule does not define a counter style"?
According to #1862, they make a difference in whether the rule appears in OM. If so, making the rule not define a counter style seems more reasonable.
tabatkins commentedon Nov 7, 2020
Oooh, that's a good question. @Property currently says it makes the rule invalid, which presumably means it doesn't show up in the OM. I don't have time to test whether that actually happens atm, but we shoudl be consistent between these two.
Loirooriol commentedon Nov 7, 2020
Shows up in the OM: test
andruud commentedon Nov 12, 2020
+1, we should avoid parse-time behavior of one descriptor being affected by another descriptor, any complicated "validation" of the rule as a whole should happen at "@-rule interpretation time" (or whatever we want to call that). I didn't even raise an issue for this for
@property, I thought it was a given. 🤷♂️tabatkins commentedon May 13, 2021
Makes sense, I've clarified that paragraph that failing to meet the minimum symbols length just means you don't define a counter style; nothing is invalid.