Re: [community-group] Defining "design token" from a "technical" perspective (#42)

@lukasoppermann sorry for coming late to the party, only found out about this community a couple of days ago. But, here I am.

Yes, a token _can_ be single or multi value, but that depends on the detail levelling or context. Shorthand vs longhand will also come to play here. The technical aspect of a specc (css) can be changed / broken, and browsers _can_ interpret shorthands differently.

Take gradients for example, in some occasions you just want the start / stop pattern predefined, or only the color, or only a group in the gradient, or event whole stacked gradients. How can a design token spec take this into consideration?

I think the spec needs to allow for both levels of control.

Another example could be `box-shadow` (CSS); you can have a token for the direction of a shadow (lightning), the hardness and the blur. Also, a specific color only used for shadows. That color token can again be a composite of a color and an opacity.

For me, it feels like it's getting lutlf hand. In my use case, in regards of shadows, we've predefined shadows as a whole, combining every attribute into one token. Makes it easier, not many "loose parts". KISS and all that. 

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


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

Received on Saturday, 25 September 2021 22:07:56 UTC