[css-values-4] should specification discourage future uses of <custom-ident> more?

[dbaron]

From various past discussions such as #7431 (comment) or #8746 I wonder if the css-values-4 specification should somewhat discourage new uses of <custom-ident> (in favor of <dashed-ident>). The specification text currently only refers to being positionally unambiguous, but I think there is advice from at least some members of the WG that new uses of <custom-ident> are somewhat more strongly discouraged. It would be useful to get at least rough consensus on that and put it into the specification.

[tabatkins]

I agree. Even names that have a fixed position in one property have a way of migrating into other properties, which then also have to fix their position. And even when fixed, it can still produce confusing-looking property values, while a dashed ident is always clearly a user-defined name.

There are still reasons to use custom-ident sometimes, but I think it should be discouraged for general use.

[dbaron]

I think it's worth writing down what you think those reasons are, and seeing if the group agrees. :-)

[tabatkins]

Basically just if you're mixing with an existing set of CSS-defined names, have a strong reason to occupy the same namespace, and have a reasonable expectation that you either won't expand the set of CSS-defined names or that author-defined names are unlikely to clash with new CSS-defined ones. If any of these are false, you should probably be using <dashed-ident> imo.

For example, @counter-style names are <custom-ident> so it's not immediately apparent from the name whether the counter style is language-defined or author-defined; we felt this was important both because it allowed us to retroactively define a bunch of built-in counter-styles using @counter-style, and to avoid overtly privileging some languages with a more blessed name just because we happened to predefine them. And we defined the name resolution rules such that author-defined styles would override almost any predefined ones (with the few that aren't overrideable explicitly disallowed for use), so adding more predefineds is unlikely to cause issues.