- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jan 2022 22:33:52 +0000
- To: public-design-tokens-log@w3.org
@drwpow: I think the `mode` thing you're proposing could be a good be a solution to theming, dark/light modes, etc. - essentially anything where a single token may have alternative values in certain contexts. However, what I was trying to describe in this issue is (at least in my mind) a different problem. I'm trying to define 3 distinct design tokens, but one of them happens to have a name that clashes with a group that contains the other 2. Perhaps I chose the bad names for my example - the "light" and "dark" colors weren't intended as _alternative_ values for light and dark mode, but rather just 2 extra colors. In hindsight, I probably should have used names like "tint" and "shade". I'm less keen on the `mode` approach as a way of doing a group/token hybrid as it's not clear to me how you'd put nested groups into it (after all, groups can contain groups as well as tokens) and/or tokens with their own, different types. I'd prefer something that keeps hybrids as close as possible to group and token's current syntax. But, we should totally look into it for theming, dark/light modes, etc. - feel free to open an issue for that if you like, btw. It's a topic we'll need to address sooner or later. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/97#issuecomment-1012579063 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 January 2022 22:33:53 UTC