- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Nov 2023 15:30:01 +0000
- To: public-design-tokens-log@w3.org
Interesting discussion. I can certainly see the value in being able to describe a list of colors. Furthermore, if we were to go down that route I do like the idea of generalizing it so that you could have lists of any kind of token. However, a problem with @ddamato's suggestion of just allowing any `$value` to be an array is that for some types a singular token value might already a JSON array. For example `fontFamily` tokens may have array values (which are meant to be intepreted as a font stack from most to least preferred font family name). Similarly, `gradient` token values are arrays of objects representing the color stops. So, how would a tool reliably differentiate between an ordered set of individual font family names, versus a single font stack? Perhaps not a very real-life example, but hopefully you get the idea. At first, I was thinking an alternative might be to introduce a new `$list` (or perhaps `$valueList`, or just `$values`?) property which tokens can have _instead of_ a `$value`. Its value would always be a JSON array of valid token values for that type. For example: ```json { "color": { "category10": { "$type": "color", "$list": [ "#1f77b4", "#ff7f0e", "#2ca02c", "#d62728", "#9467bd", "#8c564b", "#e377c2", "{reference.to.some.other.color.token.why.not}", "#bcbd22", "#17becf" ] } } } ``` But, an immediate issue with that is that it quickly breaks down when you consider what happens if this list token is (accidentally?) referenced from another token which is expecting a singular value. ```jsonc { "color": { "category10": { "$type": "color", "$list": [ "#1f77b4", "#ff7f0e", "#2ca02c", "#d62728", "#9467bd", "#8c564b", "#e377c2", "{reference.to.some.other.color.token.why.not}", "#bcbd22", "#17becf" ] } }, "gradient": { "rainbow": { "$type": "gradient", "$value": [ { "position": 0, "color": "#000000" }, { "position": 1, "color": "{color.category10}" // It's a color token, Jim, but not as we know it } ] } } } ``` Is that an error? Is there some convention like tools should just pluck out the first value from the array? Neither of those feels particularly intuitive. Maybe I'm overthinking things and we should just add a new `colorList` type along the lines outlined in the OP. There's a clear use-case for it (the DS where I work also has categorical palettes, so I can see the value in it). If a similar need arises for other things - e.g. someone needs a space list or whatever - then we add new types as needed. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/228#issuecomment-1821150175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 November 2023 15:30:03 UTC