Computed Token Values

[tonyjwalt]

This may be a bit much for the MVP spec, but should the spec allow for computed values?

Much of tokens is around defining a system, and much of a system is about relative choices. It'd be nice to define the relative nature of those choices when defining the values. This could apply to colors via things like "tint" and in numbers via basic arithmetic.

It looks like this concept is already underway in the dimension's suggestion to use rem. Isn't that really setting the value relative to an arbitrary master unit that only has value in the Web?

[c1rrus]

Computed values is something that's been asked for a number of times, so I'd certainly agree that it deserves consideration. I would also agree that it's too much for the initial, MVP spec. I can imagine there's a fair bit of complexity when you get into the weeds of it - for instance, if we had a tint function, our spec would also need to specify a detailed algorithm of how to do that in order to ensure that it's implemented consistently across different tools and interoperability of design token files is preserved.

Also, where do you draw the line? I can imagine use-cases for some arithmetic, so it might be tempting to allow +, -, / and *, but if you keep going down that road, would you end up creating a sort of programming language? Maybe that's what the community (eventually) needs, but I imagine that will be significantly more work to specify and implement than the static format we have so far.

My hope is that, in the meantime, tools will fill that gap. Perhaps someone will make a token pre-processor tool (e.g. something along the lines of what SASS is to CSS)? Just because today's tools tend to either extract tokens from elsewhere (e.g. visual design tools), or translate tokens into other languages (e.g. StyleDictionary and Theo) doesn't mean there couldn't one day be tools that read a token file, manipulate it in someway and then write out a different token file. ;-)

---

It looks like this concept is already underway in the dimension's suggestion to use rem. Isn't that really setting the value relative to an arbitrary master unit that only has value in the Web?

Perhaps. I never really thought of it that way. To me rem (and other relative units in CSS) are "just" units for length values, but unlike absolute ones like px, they happen to relative to something in the user's settings. To put it another way, there are 2 distinct concepts there and 1rem is not the same thing as 16px. I therefore don't think of rem as some kind of arithmetic shorthand for 16x a px value.

It's also worth noting that the concept of default-font-size-relative length values is not unique to the web. Android has it too, they just have a different name of it: sp and happen to have defined it as 1/16 of the default font size. In other words, 16sp in Android is the exact equivalent of 1rem in CSS. For our format we could have gone with either of those or made up our own thing, but decided to borrow from CSS and go with rem as the unit for default-font-size-relative length values.

[tonyjwalt]

Thanks for the reply @c1rrus!

Yeah, I can definitely see how it makes the spec much more complex to support custom functions. I’d probably draw the line at basic arithmetic like I think CSS does with calc(), but your point on how far that could go is valid.

I want to make sure it’s clear that I’m fully on board with using rem units, perhaps my statement of “only having value in the Web” could’ve been phrased better. In terms of Android I agree sp is closer to rem since it bases off the users text-size, but it makes me think of the idea of dp which they use for a unit relative to screen density.

I’m not sure I have any answers here, but I think it’s interesting to be able to define how parts of a system are relative to each other versus relative to some other master unit. That said, a pre-processor, or doing a little basic math (paired with a comment denoting the relative nature) when defining tokens could also do that.

[kaelig]

Closing this issue, but feel free to post use-cases below, and we will reopen it if appropriate.

[c1rrus]

Closing this issue as per @kaelig's comment above.

But, wanted to add that there is an active debate around more-or-less the same idea over in issue #88 (though it's mostly focussing on colors).

To make future discussions easier to follow, I suggest additional ideas, use-cases, etc. are added as comments to #88 rather than here.