[High-level] Making it less painful to communicate design tokens across parties

[LeaVerou]

This is a high level issue to discuss potential directions and track relevant proposals in one place.

Background

Any UI component ¹ that needs to render UI, needs to use certain design tokens: colors, fonts, sizes, etc. Currently, there is no way to read these from the host page. Instead, it needs to define its own, and (at best) provide its own CSS variable as styling hooks. Authors then can write dozens of CSS declarations to make this component look like it belongs in their page, live with a component that looks completely out of place (rarely acceptable). If they want to swap the component with a different one, they need to start over, and figure out the CSS properties the new component uses.

In practice, they gravitate towards monolithic component libraries for which they only need to write the glue code once, since the components cooperate in using the same design tokens. But no single library will ever have all the components

Here’s a concrete example. Suppose you’re making a component for e.g. a calendar widget.

• When you want to highlight the current date with an accent color, you want it to be the accent color the page uses already, not some random accent color the WC author decided was good.
• When you want a lighter version of the accent color for e.g. a date range or a hover highlight, you want that to be an existing tint the page uses.
• When you want to display an error message, you want the red palette the page uses, not #ff0000 or some random red shade the WC author likes.
• When you want to display some grayed out help text, you want it to be a neutral shade already present on the page and the smaller font size already used on the page.
• When you want to add a badge that says "today" on the current date, you want to pull in the sans serif font the page already uses and one of the font sizes that already exist on the page.
• When you want to draw borders between dates, you want to use existing colors and border widths.

The problem space may seem huge, but a little goes a long way. The biggest pain point is colors, as that is what is most noticable when it’s different, hardest to figure out from inheritance, and hardest to come up with simple defaults. With fonts you can often get by utilizing inheritance, and you mainly need access to the actual design tokens when you need a specific type of font (e.g. in a badge you need a sans serif font, or a code area you need a monospace font) and for sizes the difference tends to be less noticeable.

High level solutions

The main solutions fall into two categories (which are not mutually exclusive):

1. Standardize certain "core" design tokens
2. Making it less painful to pass multiple design tokens around
3. Ways to derive tokens from other tokens
4. Ways to reduce the tokens that need to be passed around in the first place

These are not mutually exclusive, they are actually composable: 1 reduces the tokens that need to be passed around, and 2 could improve things for the ones that still do need to pass around, and 3 makes it possible to generate derivative tokens from 1 and 2

1. Standardized "core" design tokens

This involves standardizing certain design tokens that are frequently needed and/or can be used to derive others and providing. This may involve both designing new values, as well as making existing values writable or dynamic.

Relevant proposals:

• Making design systems first-class citizens #9999
• [css-fonts] Allow authors to redefine generic font families #10452
• [css-color-adjust] Allow authors to define custom color-scheme values. #9660
• [css-color] [css-ui-4] Authors should have access to accent-color value to use in their code #5900
• [css-env] Adding custom env() variables #2627
• [css-color] New Message/Action system colors #11199

2. Introducing high bandwidth ways to pass CSS variables around

This involves ways to make the current workflow more high bandwidth: integration effort would still be needed, but if reduced to a few declarations rather than the dozens required today, it might be more palatable.
Ways to derive tokens from other tokens

Relevant proposals:

• Proposal: CSS Variable Groups (as a solution to several design systems pain points) #9992
• [css-color-5] color-scale() for creating color scales via interpolation #10034

3. Ways to derive tokens from other tokens

E.g. tints from an accent color, or single lengths from a scale would also belong to this category

• [css-color-5] color-scale() for creating color scales via interpolation #10034
• [css-values] Proposal: round() to a finite scale #11067

4. Ways to reduce the tokens that need to be passed around

These involve ways to reuse styles from other elements to reduce the tokens that need to be passed around in the first place.

• [css-values-4] inherit() function: like var() for parent value, for any property #2864
• [css-mixins] Proposal: @like rule for repurposing page default styles #10222

Footnotes

1. component in the general sense — this could be a web component (and a lot of this is about WCs) but even just a reusable stylesheet suffers from the same issues. ↩

[LeaVerou]

TPAC 2024 Breakout

Present: lea, khush, miriam, noamr, Rain, JJ, vmpstr, estelle, JRJurman

Minutes: https://www.w3.org/2024/09/25-design-integration-minutes.html

Links mentioned:
Tailwind (and other palettes) plotted in OKLCH (website is very slow, give it some time)

Tints of yellow across 8 popular handcrafted color palettes plotted in OKLCH

Github’s palette generation tool