- From: Jerome Farnum via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Sep 2022 11:11:20 +0000
- To: public-design-tokens-log@w3.org
As a maintainer of a design system I could definitely see value in understanding reference relationships between tokens, so I could understand the knock-on effects of deprecating, removing, or modifying a token. In so much as a tool was built for the express purpose of managing collections of design tokens and/or themes; that would be an ideal place to surface that data. I think it’s more useful to understand which tokens are depended on by whichever token I was isolating (e.g. if I’m looking at an option token, which alias tokens are referencing it, and perhaps which component tokens are referencing said alias tokens.) As was said previously, the `$value` field already fully explains which tokens the isolated token references (I suppose a case could be made to reveal second-order references similar to how I mentioned above for the component references of alias tokens). In any case, token tooling can dynamically calculate these references at interpretation time and reveal them as needed to the user - I’m not sure I see an advantage to including it in a specification that is at least nominally intended to be written by hand. This request seems to clearly meet the non-essential metadata guidance for entries in the `$extensions` field. -- GitHub Notification of comment by jeromefarnum Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/141#issuecomment-1252198990 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 September 2022 11:11:22 UTC