- From: Kevin Powell via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Nov 2021 13:25:07 +0000
- To: public-design-tokens-log@w3.org
This part of the spec needs more definition. Defining what composites should and shouldn't be used for with a lot more examples. I view a composite token as a set of _additive_ design decisions applied to a _single_ element. So border, transition, text styles, shadows, (any css shorthand property basically). What gives me pause are mutually exclusive sets of values. @rfrey-rbx's mention of **color pairs** doesn't fit as a composite to me, I'll try to articulate why. I think it's because there's additional information required to correctly apply those values like the specific keys of `Color`, `OverSurface` and `ForText`. Those feel very system-specific and too bespoke for us to bake into the spec. I have similar hesitation when I hear of light/dark mode color sets as composites or responsive font sizes for different viewports. In all those cases there's implementation-specific information required to apply the correct token at the correct time and I see implementation details starting to drift into the tokens file itself, which makes it harder to standardize. In my view a tokens file should not contain any context-specific implementation hooks or keys that trigger automatic switching between tokens or automatic application of tokens. -- GitHub Notification of comment by kevinmpowell Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/54#issuecomment-957566711 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 November 2021 13:25:09 UTC