w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.46k stars 657 forks source link

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

Open LeaVerou opened 5 days ago

LeaVerou commented 5 days ago

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

Background

Any UI component [^1] 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.

[^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.

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.

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:

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:

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

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.

LeaVerou commented 5 days ago

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)

image

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

image

Github’s palette generation tool