Suggestion: colorList type for DataViz about community-group HOT 6 OPEN

❌ At least in JavaScript-land, objects are not meant to preserve ordering (0 appearing before 1 is never guaranteed, and it would have to be on the tool itself to manually sort each time, which isn’t clear from the spec it should do).

I don't have any feedback on the dataviz scenarios themselves, but JavaScript does explicitly define iteration order now and it's supported everywhere. Strings that contain integers in numerical order, then all other strings in insertion order, then Symbols.

from community-group.

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)?

{
  "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.¹ 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.

from community-group.