community-group
community-group copied to clipboard
Adopt kebab case for token names
Adopt kebab case for token names.
Referring to this paragraph:
Token names are case-sensitive, so the following example with 2 tokens in the same group whose names only differ in case is valid:
Why not making all token names always kebab case? This will provide more consistency to the specification and help tool manufactires be more accurate when performing a translation or transformation for distributing token data to other languages and platforms.
Kebab Case is also a nice, clean, human-readable way to combine the words.
I also brought this up but with a different proposal to resolve : https://github.com/design-tokens/community-group/issues/119
The unrestricted names are problematic and make it impossible to consistently and correctly generate code based on token names.
Because the spec doesn't seem likely to change we (css tools, working on PostCSS plugins) decided not to adopt code generation in our translation tool. Stylesheet authors need to consume tokens manually in this style :
.foo {
color: design-token('color.background.primary');
padding-top: design-token('size.spacing.small');
}
I do understand the idea behind the unrestricted names and I like the sentiment, but it does place significant burden on tools, developers and designers.
Hmm, I'm not sure I see what the benefit would be. Kebab case is invalid syntax in just about every environment except CSS, so to export names for JavaScript, iOS, Android, WinUI (and I imagine other stuff I'm not familiar with like Flutter and Qt), those names would have to be converted into something else. There's no possible naming standard that would be natural and valid in every different environment tokens would be used in, so I don't see how this would improve consistency other than maybe slightly simplifying the renaming code for a conversion tool. Can you explain a little more about how you feel this would help?
Hmm, I'm not sure I see what the benefit would be. Kebab case is invalid syntax in just about every environment except CSS, so to export names for JavaScript, iOS, Android, WinUI (and I imagine other stuff I'm not familiar with like Flutter and Qt), those names would have to be converted into something else. There's no possible naming standard that would be natural and valid in every different environment tokens would be used in, so I don't see how this would improve consistency other than maybe slightly simplifying the renaming code for a conversion tool. Can you explain a little more about how you feel this would help?
The kebab
naming convention is not intended to distribute the tokens "as they are", but rather to help tool makers have a consistent naming convention to rely on
, which will help when debugging and will make tools more accurate when converting to specific platforms or languages.
Yes, kebab isn't supported in many languages, but it is supported in JSON. And, this is how we create powerful token taxonomies, so why not use it in the first place?
As long as the token name field is left as "free form", we will hinder the User Experience of the tools being made since they may output repeated tokens (which may overwrite other tokens, etc.).
Any additional thoughts regarding this?
Thank you for this suggestion. The spec editors have reviewed this issue and decided not to add this functionality to the specification. Our rationale for this decision is to allow token authors the freedom to use whatever structure they wish to name their tokens.
Can I become part of the spec editors?