Re: [community-group] Conditional token values (#169)

Commenting here with a similar issue and a slightly different proposal made on https://github.com/amzn/style-dictionary/issues/909. I believe there's room in the spec for tokens to have multiple value properties, though without embedding the logic as to what they mean.

I have developed multi-brand white-label token systems before and it made perfect sense there to use multiple files, but I believe the use case brought up by @romainmenke is legitimate and distinct.

In my current org, we have responsive size tokens, responsive typography tokens (size and leading), typography fonts that depend on country, dark mode, some token values changing for web vs mobile, and soon high-contrast too. If we were to have a files-based approach,

* we'd have 8 or 9 token files with _lots_ of repetition
* we'd need to write completely custom code to deliver tokens for some platforms by aggregating the 8 or so files (some declarative styling frameworks like Tailwind require us to declare the whole CSS class at once)
* we'd find it harder to check our source of truth to understand the possible values a token can take

For those who don't know, SD processes tokens with two layers: transforms first process the value and attributes of individual tokens, and formats then aggregate a group of tokens to produce a platform-specific output.

I've come up with a proposal to only add extra value fields to a token because:
* It would allow us to apply transforms consistently to all value properties of a token
* It would allow us to encode arbitrary logic, potentially platform-specific at times, in our SD formats

If I were to generalise, additional `$value` fields in the spec would:
* Allow value processing / display / editing tools to handle multiple value fields with little impact (just need to declare the value field names)
* Let end-of-the-pipeline output tools encode arbitrary logic, possibly with manual coding or possibly with proprietary conventions developed by such tools

I believe this proposal could provide much of the value you seek, @romainmenke, whilst avoiding the complexity linked to having logic management in a spec. I'm curious to have your opinion on it.

-- 
GitHub Notification of comment by Sidnioulz
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/169#issuecomment-1371939482 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 5 January 2023 08:54:55 UTC