- From: Steve Dodier-Lazaro via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 May 2023 12:37:41 +0000
- To: public-design-tokens-log@w3.org
> My main concern is also what @nesquarx mentioned, about scalability. If I'm adding a theme with only a small bit of overrides, after the fact.. it might be easier to have this in a separate file, so I can easily see what a theme overrides on the core. > > @connorjsmith 's comment addresses my concern in that regard: > > > Depends on the heuristic we'd want to use for what constitutes an "extension" of the base theme (either via some sort of $extends, or just via name matching), but I'd think that defining more modes would be something like this > > I also think that is very closely related to [my proposal of an $extends property](https://github.com/design-tokens/community-group/issues/116), some sort of simple metadata that defines a contract between token files or token groups even. For us, having distinct files would be unmanageable. We define hundreds and hundreds of tokens, currently with 18 different modes applied. Getting the full picture of what a token's value can be would be difficult, and we find that once the token system is set up, we update _tokens_ rather than updating modes. Having a single file where a token showcases all its values make that easier to manage. I'd love to see both formats supported by tools, though I believe what tools like Style Dictionary currently do (multiple files with a value per token per file) is too inconvenient for long-term maintenance workflows. -- GitHub Notification of comment by Sidnioulz Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1534704687 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 May 2023 12:37:43 UTC