Open LeaVerou opened 2 months 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)
Tints of yellow across 8 popular handcrafted color palettes plotted in OKLCH
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.
#ff0000
or some random red shade the WC author likes.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):
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.