Re: [community-group] [RFC] Format specification (#1)

Regarding functions, I think it's not too uncommon for some type of function to generate tokens, whether it be a function of one token against another (`tokenC = fn(tokenA, tokenB)`), some basic generic function against a token (`tokenB = saturate(tokenA, 10%)`), or even some more complex function that is an invention of the design system authors themselves (such as Polaris' "[color factory](https://github.com/Shopify/polaris-tokens/pull/89)", or Adobe's contrast-based color generation tools). In some cases this is a 1:1 (one token resulting of a single function call), whereas other cases this is a one-to-many (small set of values generates many more tokens).

I do not believe we should define sets of functions within the spec, however it's worth noting that tokens may be generated as a result of these functions. I'm not entirely sure what would need to be defined in order to support this appropriately, but the simplest use case of type scales would be a good straw man.

> Isn't the colorspace just a variant (as discussed more on #2)? Do we need to be arbitrary about the kind of variants we allow for each "types"?

I don't see this as a variant per se but that might work. Althoug variant implies that it's a choice, whereas in this case it's not a choice; it's a _correct or incorrect value_ for a token based on ouptut that a product/consumer needs. In this type of structure https://github.com/design-tokens/community-group/issues/2#issuecomment-537613456, it could become messy. At that point you're defining a light/dark theme variant, and then for each theme variant of a color there would also need to be colorspace variants. The model would become difficult to reason about.

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

Received on Tuesday, 28 January 2020 16:25:45 UTC