- From: Milber Ferreira via GitHub <sysbot+gh@w3.org>
- Date: Sat, 02 Jul 2022 10:26:05 +0000
- To: public-design-tokens-log@w3.org
@c1rrus Essentially yes, it does that + one more thing: 1. It forces "option" and "alias" tokens to be explicitly grouped within the token system as clusters. 2. It prevents "option" tokens from being exported to code. 3. It allows for specific cluster rules, like for example: "options" should always have a raw/pure value, while "aliases" should always refer to an existing "option" or "alias." A benefit of point one is that by preventing translation tools from rendering "options", we can allow users to think of meaningful names for all "alias" tokens, and completely forget about naming taxonomies for "options" because these can be auto-generated by the tool as "option" names should be completely agnostic. Moreover, token inheritance would be a lot more reliable since users can trust that no one option can ever repeat. It will be easier for tools to handle repeated "options". This way, designers will be able to experience the value of DRY (Don’t Repeat Yourself) as we developers do in programming. What you propose could also work, of course, but clustering these two groups would also help increase the understanding of how tokens interact with each other. To sum up, I believe that the nature of "options" vs "aliases" is very different, and as design tokens evolve, these will become even more noticeable. Therefore, clustering will allow for rules to be applied to each group more intuitively. -- GitHub Notification of comment by reblim Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/145#issuecomment-1172875375 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 2 July 2022 10:26:08 UTC