- From: Milber Ferreira via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Jul 2022 08:55:58 +0000
- To: public-design-tokens-log@w3.org
@TravisSpomer Exactly these kinds of issues you talk about are those that will be fixed by adding the "options" and "aliases" clusters with specific rules for each. As mentioned before, if "options" can strictly only have raw values, this will help us to avoid repeated values polluting the system. On the other hand, "aliases" should only refer to existing "options" and other "aliases", but never a raw value. Then it will always be clear what cluster type the token at hand is. Clustering tokens will also give us more control to decide whether, for a project, you would like to export "options" or not. Regarding your example about the shadow tokens, I believe you may be confusing them with composite tokens. A shadow token is formed out of various tokens, which could be both "options" and "aliases", depending on how the system is put together. -- GitHub Notification of comment by reblim Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/145#issuecomment-1178733088 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 8 July 2022 08:56:00 UTC