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.

I guess an analogous example is https://drafts.css-houdini.org/css-properties-values-api/#initial-value-descriptor

@property --foo {
  syntax: "<length>";
  inherits: false;
  initial-value: 1px;
  initial-value: 1;
}

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.

Yeah true, so indeed, let's make the whole @counter-style rule invalid as well.

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.

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.

Shows up in the OM: test

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.