Remove composition tokens
jorenbroekema opened this issue · comments
Cutting right to it: I think composition tokens were a mistake.
A design token is a single design decision, and while object-value/composite token values make sense when a decision has multiple known subparts e.g. a shadow has X and Y offsets.
What doesn't make sense is that a token value can be merely the composition of other tokens.
This is just the assembling of multiple design decisions into a group so that it becomes easy to use when you apply it in code or in a figma component/node. The token type "composition" basically means "convenience". Fundamentally, this doesn't belong in the design token spec, it doesn't align with the spirit of what a design token is, which is an individual design decision about a visual thing.
The biggest practical issues of composition tokens are:
- the set of properties of its value are completely unknown, making it difficult to reason about these tokens or to set up expectations for how they will be outputted/transformed
- composition tokens can infinitely nest? There's a question mark there because this isn't exactly clear, but at the very least it seems to make sense that a composition token's value can contain properties that reference other object-value/composite tokens like typography tokens, this in turn would create an object within an object. Who's to say you can't have composition tokens inside composition tokens too?
These two problems combined really makes it rather untenable to work with these tokens. While trying to understand and build a mental model around what exactly makes them hard to work with, led me to believe that these tokens aren't really design tokens. Hence my opening argument. Composition tokens aren't about design decisions but rather about composing/assembling/grouping tokens instead, which should be done outside of the design token format.
I fully agree. Technically this shouldn't be a token, it is a feature to apply tokens easier. It's more like a css class vs a css variable. While I see users get value from a more efficient workflow of applying tokens and communicating how tokens should be applied (especially on components) I do also believe they should not be part of the format. What we should think about is how we fix this without regressing the experience.
I also agree that this should be a feature and not a token type. I have some thoughts on this to share in a jam whenever we decide to think through how to migrate away from the token types (and other features) we deprecate over time.