Component colors
Once UI typically does not use component-level tokens, and we recommend considering them only under specific circumstances, such as:
-> Working with a large design team
-> Managing a diverse product range
-> Supporting products with diverse branding
-> Streamlining the component styling process for designers
-> Having the necessary resources to implement custom tooling
While some view component-level tokens as a futuristic workflow, there are significant challenges to consider:
-> They can lead to overly complex token systems
-> Maintaining consistency becomes challenging at this scale
-> Implementing dummy tokens may be necessary if a component lacks a specific property but needs to be updated via tokens
Despite these challenges, I'll guide you through setting up a component-level token system in the upcoming example.
Component tokens
When considering component-level tokens, it's not just about colors but about the ability to fully customize a component through a single variable file.
This approach requires a focused, component-centric design strategy to maintain consistency in naming conventions.
Take the ❖Button component as an example. Interactive components like this have various states, each needing its own set of tokens.
For a button, you would typically account for:
-> default
-> hover
-> active
-> focused
-> disabled
Additionally, you might have common properties, such as:
-> size (s, m ,l)
-> style (primary, secondary, destructive)
-> fullWidth (boolean)
Let's delve into how these elements come together in a component-level token system.
Example
We can break down the states and properties of a button into specific CSS properties and tokens, as shown in the following list:
CSS property
background
border-radius
border-width
border-color
border-style
font-family
font-size
font-weight
color (font)
padding
height
->
->
->
->
->
->
->
->
->
->
->
Token / Variable
button-{{ style }}-{{ state }}-background
button-{{ size }}-borderRadius
button-{{ style }}-borderWidth
button-{{ style }}-{{ state }-borderColor
button-{{ style }}-borderStyle
button-fontFamily
button-{{ size }}-fontSize
button-fontWeight
button-{{ style }}-{{ state }}-color
button-{{ size }}-padding
button-height
These examples are just the tip of the iceberg.
You could incorporate some less frequent properties, such as:
box-shadow
backdrop-filter
background-image
->
->
->
button-{{ style }}-{{ state }}-boxShadow
button-{{ style }}-{{ state }}-backdropFilter
button-{{ style }}-{{ state }}-backgroundImg
The complexity multiplies with the dynamic elements for states and properties. A seemingly simple component like a button can lead to the creation of hundreds of tokens.
Venturing into component-level tokens without a solid framework, thorough documentation, and the right tools can quickly become overwhelming. It's crucial to carefully consider whether this level of detail is necessary for your project.