- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Jun 2023 07:57:12 +0000
- To: public-design-tokens-log@w3.org
Thanks so much for sharing the resolver proposal, @SorsOps. It's super interesting. I also had a brief play with the online tool you shared and it looks pretty sweet. As you say, this moves the problem of how to handle tokens with variable values (for brands, themes, color schemes, information densities, etc. etc.) out of the scope of the DTCG format, which could help keep the spec simple for now. (aside: I do think there are some concepts within that resolver spec that might be nice to absorb into the spec in the future though) However, it does raise at least one requirement for the DTCG format: * A single DTCG file needs must be allowed to contain references that cannot be resolved within that file Otherwise, the files used as modifiers would not be able to contain aliases to tokens provided by the sets. Currently the DTCG spec does not forbid this, but it doesn't explicitly allow it either. If we were to agree that we wanted to allow this, then I think we should explicitly state that in the spec to avoid differing interpretations (e.g. one tool assuming references must be resolvable within the same file and therefore rejecting files where that's not true). (Btw, I think this current ambiguity in the spec was highlighted before in another issue, but I can't find it right now) Thing is, do we _want_ to allow that? Personally, I quite like the idea that every DTCG file is self-contained. I think that can make them easier for humans to reason about. It could also make them more portable - e.g. the use-case mentioned above about referencing tokens from another DS's tokens. If you can cherry pick any `.tokens.json` file What this thread is making What this thread is making clear is -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1610944999 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 June 2023 07:57:14 UTC