- From: Matthew Ström via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jan 2022 18:54:18 +0000
- To: public-design-tokens-log@w3.org
If groups and tokens can share a name, my inclination is that the token/group hybrid is the right way to go. However, I think we ought to hash out if it makes sense to allow groups and tokens to share a name. I feel like we end up making naming tokens a little more flexible at the cost of a lot of complexity in parsing/reading. In our examples above, what is the value of `color-accent`? In one sense, it's a group of two tokens named `light` and `dark`. In another sense, it's a token with the value of `#dd0000`. In both reasoning about the system and using it, we'd run into a lot of challenges working with two distinct things called `color-accent`. I'd suggest that we keep things simple and lean on the requirement of unique keys within JSON to provide some guard rails. Say you define the group like this ``` { "color": { "type": "group", "value": { "accent": { "type": "group", "value": { "light": { "type": "color", "value": "#ff2222" }, { "dark": { "type": "color", "value": "#aa0000" } } } } } } ``` The `color` group can only have one value for the key `accent`. Since you've already defined it as a group, you can't re-use it for a color. You do lose some flexibility in naming tokens, but gain a lot of precision. -- GitHub Notification of comment by ilikescience Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/97#issuecomment-1012416825 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 January 2022 18:54:19 UTC