Re: [community-group] Suggestion: colorList type for DataViz (#228)

I'm partial to the simplicity of the current specification, however, this made me consider something beyond what you are asking. Why not just allow the `$value` of any type to allow a "list" (an Array)?

```json5
{
  "dataviz": {
    "$type": "color",
    "$value": [ ... ]
  },
  "typography-scale": {
    "$type": "dimension",
    "$value": [ ... ]
  },
}
```

A difficulty here is that there's often a separation between token author and token user. While the token author knows that this kind of token is expected as a list (accessible by index), the token user might not know as they _usually_ only apply tokens by name. Having an additional accessor past the dot-notation for some tokens may be easily missed in practice for these "special" tokens. Thereby not applying a value at all. I know the purpose of these tokens isn't for someone to apply individually, but programmatically. However, I don't know if that's enough of a case for them to be different from the rest of the spec.

Also requiring to know how many items exist is a challenge, since some lists could have different lengths. This is especially in the case of the D3 example. In a CSS rendered world, where tokens are often finally written as `var`, the dataviz component would have no idea how many of them are available (is it 4, or 20?) between themes unless you have some socially accepted guard (read on).

I think the reasons above make it challenging for _any_ list type to exist.[^1] In the system we use today, we've explicitly set out for 30 colors across each theme which must all be defined. If they need to loop (meaning one theme only has 6 colors, they are applied 5 times), then so be it. Not listed as an array but as separate names (like all other tokens) such as `dataviz.order7`. In the dataviz component, we know 30 is the max and cyclically render by name for each chart part.

Fundamentally, each token is meant to represent the eventuality of a single value. It's why the `"$type": "shadow"` token is a composite, all of the parts are meant to combine into a single final value. The idea of a list is the opposite; a single token meant to provide multiple values. Full disclosure, I also don't enjoy composite tokens as a concept due to a lack of simplicity.

I'll mention that this family of colors is not only helpful for charting, but any place where color is meant as a differentiator between elements of the same group (like avatar defaults). I've called them "figure" colors in the past, meant to color shapes. This is the most challenging set to name because it's not possible to give them semantic meaning past their group. These are effectively base colors that expect to be applied directly in the UI. I've experimented with going so far as coloring illustrations this way (ie., color-by-number) which takes an extra amount of focus and coordination between themes to get right.

[^1]: I know `fontFamily` can be a list but it's strategically not like any other value in the way it requires additional resources to be useful. The token user placing the token would just render the resulting string, while systems must read as individual resources to load.


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


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

Received on Tuesday, 29 August 2023 13:20:10 UTC