larlet-fr-david-cache/cache/2024/0cc2e9c6b29f8326b2ff628f64e22888/index.md

title: Proposal: CSS Variable Groups
url: https://lea.verou.me/docs/var-groups/
hash_url: 0cc2e9c6b29f8326b2ff628f64e22888
archive_date: 2024-02-27
og_image: https://lea.verou.me/mark.svg
description: CSS Variable Groups is a way to define multiple properties under the same namespace
favicon: https://lea.verou.me/mark.svg
language: en_US

<div class=nutshell>
<p>CSS Variable Groups is a way to define multiple properties under the same namespace and pass the entire group around,
addressing several pain points around design tokens, design systems, and integrating third-party components.</p>
</div>
<h2 id="pain-points" tabindex="-1"><a class="header-anchor" href="#pain-points">Pain points</a></h2>
<h3 id="background" tabindex="-1"><a class="header-anchor" href="#background">Background</a></h3>
<p>Design tokens and design systems are about a lot more than color, but I’ll focus on color here, as that is the worst of it and also easier to explain.</p>
<p>The color part of most design systems consists of the following:</p>
<ul>
<li>Core hues: red, yellow, green, blue, etc. These are hues specifically picked by designers, not to be confused with the corresponding named colors.</li>
<li>Neutrals / Grays (often more than one)</li>
</ul>
<p>Each of the above is typically defined as a main color plus tints/shades under a number, with larger numbers corresponding to darker colors.
There is no commonly agreed naming convention wrt the numbering scheme used.</p>
<p>Some popular examples of such design systems:</p>
<table>
<thead>
<tr>
<th>Design system</th>
<th>Hues</th>
<th>Neutrals</th>
<th>Levels</th>
<th>Range</th>
<th>Increment</th>
<th>Extras</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="https://yeun.github.io/open-color/">Open color</a></td>
<td>12</td>
<td>1</td>
<td>10</td>
<td>0 - 9</td>
<td>1</td>
<td></td>
</tr>
<tr>
<td><a href="https://open-props.style/#colors">Open props</a></td>
<td>17</td>
<td>2</td>
<td>13</td>
<td>0 - 12</td>
<td>1</td>
<td></td>
</tr>
<tr>
<td><a href="https://tailwindcss.com/docs/customizing-colors">Tailwind</a></td>
<td>17</td>
<td>5</td>
<td>11</td>
<td>50 - 950</td>
<td>100</td>
<td>50, 950</td>
</tr>
<tr>
<td><a href="https://m2.material.io/design/color/the-color-system.html#color-theme-creation">Material</a></td>
<td>17</td>
<td>2</td>
<td>10</td>
<td>50-900</td>
<td>100</td>
<td>50</td>
</tr>
<tr>
<td><a href="https://spectrum.adobe.com/page/color-palette/">Adobe Spectrum</a></td>
<td>13</td>
<td>1</td>
<td>13</td>
<td>100 - 1300</td>
<td>100</td>
<td>Gray 50, Gray 75</td>
</tr>
<tr>
<td><a href="https://primer.style/foundations/color/base-scales">GitHub Primer</a></td>
<td>8</td>
<td>1</td>
<td>10</td>
<td>0 - 9</td>
<td>1</td>
<td></td>
</tr>
<tr>
<td><a href="https://ant.design/docs/spec/colors">Ant Design</a></td>
<td>12</td>
<td>1</td>
<td>10 (13 for grays)</td>
<td>1 - 10</td>
<td>1</td>
<td></td>
</tr>
<tr>
<td><a href="https://www.ibm.com/design/language/color/">IBM Design Language</a></td>
<td>7</td>
<td>3</td>
<td>10</td>
<td>10 - 100</td>
<td>10</td>
<td></td>
</tr>
<tr>
<td><a href="https://www.radix-ui.com/themes/docs/theme/color">Radix UI</a></td>
<td>25</td>
<td>6</td>
<td>12</td>
<td>1 - 12</td>
<td>1</td>
<td></td>
</tr>
</tbody>
</table>
<p>In terms of CSS variables, this translates to variables like e.g. <code>--color-red-600</code>, <code>--color-gray-10</code> etc on <code>:root</code>. A LOT of them.</p>
<h3 id="summary-of-pain-points-%26-requirements" tabindex="-1"><a class="header-anchor" href="#summary-of-pain-points-%26-requirements">Summary of pain points &amp; requirements</a></h3>
<p>Distilling these pain points into their essence, it looks like the actual pain points are:</p>
<ol>
<li><strong>Aliasing</strong>: Aliasing a set of variables with a common prefix to a different prefix is very commonly needed, and requires <em>a lot</em> of CSS.
Even when using a build tool to automate this, the size of the resulting CSS is huge, and it is hard to debug as it clogs up the devtools.</li>
<li>Defining these tokens requires manually defining every single one, even when it could be computed via interpolation.</li>
<li>Getting arbitrary tokens (e.g. through a calculation) is impossible.</li>
</ol>
<p>Any solution would need to meet the following requirements:</p>
<ol>
<li>Subtree scoped: It needs to be possible to alias a set of variables to a different prefix on a subtree, so <code>@property</code> and any new tree-scoped @-rules are out.</li>
<li>Pave the cowpaths: Assuming a web app involves three classes of users (page authors, design system authors, web component authors)
the syntax should not require opt-in from all parties at once.
Individual classes of users should be able to derive value without all other parties having to change anything.</li>
<li>It should not require more than one declaration to style a single design aspect (e.g. the primary color) of a subtree or web component.</li>
</ol>
<h4 id="biggest-pain-point%3A-aliasing" tabindex="-1"><a class="header-anchor" href="#biggest-pain-point%3A-aliasing">Biggest pain point: Aliasing</a></h4>
<p>Then, to be used in the UI, the colors are also assigned <em>semantic</em> meaning: brand color, primary (or accent) color, secondary color, success, danger, etc. Pure hues can still be used directly for certain cases.</p>
<p>Assigning e.g.</p>
<pre><code class="language-css">--color-primary: var(--color-blue);
</code></pre>
<p>Does <em>not</em> also automatically give you <code>--color-primary-10</code>, <code>--color-primary-20</code> and so on. <strong>You have to painfully define them yourself</strong>:</p>
<pre><code class="language-css">--color-primary-10: var(--color-blue-10);
--color-primary-20: var(--color-blue-20);
/* ... */
--color-primary-100: var(--color-blue-100);
</code></pre>
<p>And this is for <em>all</em> your semantic colors. We’re talking about <em>a lot</em> of variable declarations.
And often specific tints are aliased further, e.g. text, border, background etc.
Often, all of this must be repeated for dark mode, high contrast mode, etc.</p>
<p>But let’s assume we dutifully do all this. Now let’s suppose we want to theme a certain part of the page with a different primary color.  E.g. maybe we have callouts and we want to style notes (with shades of) green, tips yellow, warnings red, etc. We <em>could</em> have a <code>--color</code> or <code>--color-primary</code> property for the callout component, but that does not give us any of its variations, no, we need to define those manually <em>again</em>.</p>
<p>This also means that integrating third-party components is painful, because every single color variation they may need needs to be passed on individually. Most components <a href="https://shoelace.style/tokens/color#primitives">bundle an entire design system</a> and authors are expected to override every single property to integrate it with their own.</p>
<p>Note that this applies regardless of whether the tints and shades are precomputed (as is the case with most design systems today) or dynamically computed from color manipulation functions (our bright future?).</p>
<p>This is also a problem when adopting external libraries and design systems.
Currently, most libaries, design systems, icon libraries etc. have to use lengthy namespacing to avoid conflicts.
E.g. <a href="https://spectrum.adobe.com/page/color-palette/">Adobe Spectrum</a> prefixes each color with <code>--spectrum-global-color-</code> (e.g. <code>--spectrum-global-color-celery-100</code>).
They also often use color names that the author may want to remap to simpler names.
The effort needed for an author to remap all of these to more reasonable names is non-trivial (Radix UI even has <a href="https://www.radix-ui.com/themes/docs/theme/color#aliasing-colors">a section on this</a> — note that this is <em>just</em> for one color!).</p>
<h4 id="pain-point-2%3A-repetitiveness-and-verbosity" tabindex="-1"><a class="header-anchor" href="#pain-point-2%3A-repetitiveness-and-verbosity">Pain point 2: Repetitiveness and verbosity</a></h4>
<p>First, it is important to note that aesthetically pleasing color palettes are not completely perceptually uniform.
Chroma and hue often get skewed as you move towards the lightness edges, and they are skewed in different ways depending on the hue.
As the most obvious example, look at how yellows become orange as they darken in both of these but even more so in OC:</p>
<figure>
<img width="789" alt="image" src="images/yellow-tailwind.png">
<figcaption>Tailwind’s yellow palette</figcaption>
</figure>
<figure>
<img width="1527" alt="image" src="images/yellow-oc.png">
<figcaption>Open Color’s yellow palette</figcaption>
</figure>
<p><em>That said</em>, while we could not generate all tints through interpolation,
interpolation could approximate at least <em>some of them</em>.
But right now, the best we can do is something like this:</p>
<pre><code class="language-css">--color-green-200: color-mix(in oklch, var(--color-green-100) 20%, var(--color-green-500));
--color-green-300: color-mix(in oklch, var(--color-green-100) 40%, var(--color-green-500));
/* ... */
</code></pre>
<p>Now suppose we don’t like the interpolated <code>--color-green-300</code> and want to tweak it.
We’d <em>also</em> need to tweak <code>--color-green-200</code> if we want it to use that!</p>
<h4 id="pain-point-3%3A-cannot-reference-tokens-programmatically" tabindex="-1"><a class="header-anchor" href="#pain-point-3%3A-cannot-reference-tokens-programmatically">Pain point 3: Cannot reference tokens programmatically</a></h4>
<p>Since these are variables and variable names cannot be composed dynamically,
there is no way to transform a number (e.g. <code>200</code>) or a keyword (e.g. <code>red</code>) to a color token,
which could have allowed components to abstract away the specifics of the design system.</p>
<h2 id="proposal" tabindex="-1"><a class="header-anchor" href="#proposal">The Proposal: CSS Variable Groups</a></h2>
<p>The underlying pain point here is that authors need to be able to map <em>a set</em> of CSS variables to a different name, reactively.
What if we allowed them to do <em>just that</em>?</p>
<h3 id="defining-using" tabindex="-1"><a class="header-anchor" href="#defining-using">Defining and using a variable group</a></h3>
<p>This proposal allows authors to define groups of variables with the same prefix, by using braces
and then pass the whole group around to other variables:</p>
<pre><code class="language-css">--color-green: {
	100: oklch(95% 13% 135);
	200: oklch(95% 15% 135);
	/* ... */
	900: oklch(25% 20% 135);
};
</code></pre>
<p>Then this is equivalent to creating <code>--color-green-100</code>, <code>--color-green-200</code>, etc. variables.
But with one difference. When doing:</p>
<pre><code class="language-css">--color-primary: var(--color-green);
</code></pre>
<p>This is passing a structured object behind the scenes so you <em>automatically</em> get <code>--color-primary-100</code>, <code>--color-primary-200</code> etc.</p>
<p>This allows patterns like:</p>
<pre><code class="language-css">/* Author CSS */
:root {
	--color-green: {
		100: oklch(95% 13% 135);
		200: oklch(95% 15% 135);
		/* ... */
		900: oklch(25% 20% 135);
	};
}

some-component,
.callout-note {
	--color-primary: var(--color-green);
}

.callout-note {
	background: var(--color-primary-200);
}

/* some-component.css */
:host {
	background: var(--color-primary-100);
	border: var(--color-primary-400);
	color: var(--color-primary-900);
}
</code></pre>
<div class="note">
<p>We may need to start with a hyphen (or two), because <a href="https://drafts.csswg.org/css-syntax/#ident-token-diagram">the <code>&lt;ident&gt;</code> production does not allow starting with a number</a>:</p>
<pre><code class="language-css">--color-green: {
	-100: oklch(...);
	-200: oklch(...);
	/* ... */
}
</code></pre>
<p>But in the rest of this I’m gonna assume that Tab can come up with some ingenious solution to allow us to have the nicer syntax. 🙂
OTOH if these have a prefix, it means there are no naming conflicts with any predefined ones (<code>base</code>, <code>default</code>, etc.)</p>
</div>
<div class=note>
<p>Do we need a way to reference internal properties without having to use their full name (akin to JS <code>this</code>)?</p>
</div>
<p>The group inherits like a regular value, though if descendants define e.g. <code>--color-green-200</code>,
that would override the group value for that particular key.</p>
<h4 id="defining-or-overriding-tints-outside-the-group" tabindex="-1"><a class="header-anchor" href="#defining-or-overriding-tints-outside-the-group">Defining or overriding tints <em>outside</em> the group</a></h4>
<p>Note that once a variable is defined a group, ANY variable with that prefix on the same element becomes part of the group and is passed around or inherited down.
This means that this should work:</p>
<pre><code class="language-css">:root {
	--color-green: {
		100: oklch(95% 13% 135);
		900: oklch(25% 20% 135);
	}
}

html {
	--color-green-200: oklch(95% 15% 135);
}

my-component {
	--color-primary: var(--color-green);
	background: var(--color-primary-200);
}
</code></pre>
<p>Or even this:</p>
<pre><code class="language-css">/* style.css */
:root {
	--color-green: {};
}

my-component {
	--color-primary: var(--color-green);
	background: var(--color-primary-200);
}

/* design-system.css */
:root {
	--color-green-100: oklch(95% 13% 135);
	--color-green-200: oklch(95% 15% 135);
	/* ... */
	--color-green-900: oklch(25% 20% 135);
}
</code></pre>
<p>Which provides a way to “upgrade” existing design systems to using this new syntax without any changes to their code.</p>
<h3 id="using-groups-on-non-custom-properties%3A-the-base-property" tabindex="-1"><a class="header-anchor" href="#using-groups-on-non-custom-properties%3A-the-base-property">Using groups on non-custom properties: The <code>base</code> property</a></h3>
<p>When referencing a variable whose value is a group (e.g. <code>var(--color-green)</code> above) on a non-custom property,
by default it would either IACVT or resolve to <code>&lt;empty-token&gt;</code> (not sure which one is best here).</p>
<p>However, you can set a base value via the special <code>base</code> property (alternative names: <code>default</code>, <code>value</code>) which defines a plain value for when the property is used in a context that does not support groups, such as any of the existing non-custom properties:</p>
<pre><code class="language-css">--color-green: {
	base: oklch(65% 50% 135);
	100: oklch(95% 13% 135);
	200: oklch(95% 15% 135);
	/* ... */
	900: oklch(25% 20% 135);
};

.note {
	/* Same as border: 1px solid oklch(65% 50% 135)); */
	border: 1px solid var(--color-green);
}
</code></pre>
<aside>
In the future we may want to introduce native properties that accept groups.
Another possibility is to allow groups to be used as a shorthand’s whole value.
</aside>
<h3 id="nested-variable-groups" tabindex="-1"><a class="header-anchor" href="#nested-variable-groups">Nested variable groups</a></h3>
<p>Variable groups can be infinitely nested, which allows a single variable to hold an entire color palette:</p>
<pre><code class="language-css">--color: {
	green: {
		base: oklch(65% 50% 135);
		100: oklch(95% 13% 135);
		200: oklch(95% 15% 135);
		/* ... */
		900: oklch(25% 20% 135);
	};
	red: {
		base: oklch(55% 55% 30);
		100: oklch(95% 13% 30)
	}
}
</code></pre>
<p>This color palette could be passed on to a component in one go:</p>
<pre><code class="language-css">--component-palette: var(--color);
</code></pre>
<p>The values are not limited to colors and the keys are not limited to numbers:</p>
<pre><code class="language-css">--font: {
	serif: Vollkorn;
	sans: Inter;
	mono: Inconsolata;
};
</code></pre>
<p>In fact, together with nesting, one could imagine passing <em>entire</em> design systems around with a single variable reference!</p>
<pre><code class="language-css">/* primer.css */
--primer: {
	color: {
		/* ... */
	},
	font: {
		/* ... */
	},
	/* ... */
};

/* author css */
--design: var(--primer);
</code></pre>
<p>With compatible naming schemes, authors could even compose their design system by mixing and matching from existing design systems.
E.g. using the Primer design system, with the Open Color color palette:</p>
<pre><code class="language-css">/* primer.css */
--primer: {
	color: {/* ... */};
	font: {/* ... */};
	size: {/* ... */};
	/* ... */
}

/* open-color.css */
--oc: {
	red: { /* ... */ }
}

/* author css */
--design: var(--primer);
--design-color: var(--oc);
</code></pre>
<div class=note>
<p>Note that as currently defined, the pattern above would <em>override</em> Primer’s colors with Open Color’s,
so <code>--primer-color</code> would <em>also</em> resolve to <code>var(--oc)</code>.
To avoid this, authors could alias each top-level group separately:</p>
<pre><code class="language-css">--design: {
	color: var(--oc);
	font: var(--primer-font);
	size: var(--primer-size);
	/* ... */
}
</code></pre>
</div>
<h3 id="tweaking-the-default-value-without-destroying-the-group" tabindex="-1"><a class="header-anchor" href="#tweaking-the-default-value-without-destroying-the-group">Tweaking the default value without destroying the group</a></h3>
<p>To minimize surprise, things like this:</p>
<pre><code class="language-css">/* Make core green a little yellower */
--color-green: oklch(65% 50% 130);
</code></pre>
<p>Would need to override the whole variable value, meaning <code>--color-green-100</code> is now undefined (<code>initial</code>).
This is also consistent with how shorthands work.
Also, if we kept the subproperties intact when overriding the base color, they would get out of sync, which is worse.</p>
<p>But this begs the question: then how do we override <em>just</em> the default value?
For example, to tweak the base color and maintain dynamic tints generated from it.</p>
<p>One way would be to expose special properties like <code>base</code> like regular custom properties that can be overridden. Then you could just do that:</p>
<pre><code class="language-css">/* Make core green a little yellower */
--color-green-base: oklch(65% 50% 130);
</code></pre>
<p>And as a bonus, this facilitates debugging, and allows customizing more than just the default value.</p>
<h2 id="continuous" tabindex="-1"><a class="header-anchor" href="#continuous">Facilitating continuous variations</a></h2>
<p>So far, this proposal has been about facilitating the use of predefined static tokens.
But what if we could support <em>dynamic</em> variations, where only a few key values are defined, and the rest are interpolated within them?</p>
<div class=note>
This is the least fleshed out part of this proposal, but I think it could be a very powerful feature (possibly not MVP though).
</div>
<h3 id="the-default-property" tabindex="-1"><a class="header-anchor" href="#the-default-property">The <code>default</code> property</a></h3>
<p>I’m thinking of a <code>default</code> special property (other potential names: <code>any</code>, <code>other</code>, <code>else</code>, <code>*</code> (if possible)), that would be a catch-all for any undefined value.
The key would be passed to the expression as a predefined keyword (e.g. <code>arg</code>), but that can be customized.</p>
<pre><code class="language-css">--color-green: {
	base: oklch(65% 50% 135);
	100: oklch(95% 13% 135);
	default: color-mix(in oklch, var(--color-green-100) calc((100 - arg / 10) * 1%), var(--color-green-900));
	900: oklch(25% 20% 135);
};
</code></pre>
<p>It could even be a shorthand, with <code>default-value</code> and <code>default-type</code> to specify the return type.</p>
<p>Customizing the arg name (both for readabiity and to facilitate nested use cases):</p>
<pre><code class="language-css">--color-green: {
	base: oklch(...);
	100: oklch();
	name: tint;
	default: color-mix(in oklch, var(--color-green-100) calc((100 - tint / 10) * 1%), var(--color-green-900));
	900: oklch();
};
</code></pre>
<h3 id="piecewise-interpolation" tabindex="-1"><a class="header-anchor" href="#piecewise-interpolation">Piecewise interpolation</a></h3>
<p>The previous example always calculates mid points from the ends of the spectrum. However, it would serve use cases far better to be able to set spot colors to course correct and have the intermediate tints compute from them, similar to how gradient color stops work.</p>
<p>Perhaps numerical keys could be auto-detected and the closest min and max keys and values could be made available to the expression as keywords.
Potential names: <code>min</code> and <code>max</code> for values, <code>min-key</code>, <code>max-key</code> for the keys.
Example (see <a href="https://drafts.csswg.org/css-values-5/#progress-func"><code>progress()</code></a>):</p>
<pre><code class="language-css">--color-green: {
	base: oklch(...);
	100: oklch();
	default: color-mix(in oklch, min calc(progress(arg from min-key to max-key) * 100%), max);
	900: oklch();
};
</code></pre>
<p>These would only be available when <code>arg</code> is numerical AND there are other numerical keys defined.
There could be a max without a min and vice versa if only larger or only smaller numerical keys are available.</p>
<p>It could even be specified with <em>just</em> <code>default</code>:</p>
<pre><code class="language-css">--gray: {
	default: color-mix(in oklab, white calc(1% * arg), black);
}
</code></pre>
<h3 id="issues" tabindex="-1"><a class="header-anchor" href="#issues">Issues</a></h3>
<p>One issue is that while defining tokens via interpolation can be convenient, design system authors often do not want to expose the entire spectrum,
but only a few carefully chosen tokens.
So even if we allow the token values to be specified via a formula, we may need to introduce a way to optionally limit the keys that are exposed.
Potential solutions:</p>
<ul>
<li>A <code>default-keys</code> property (potentially a shorthand) that defines the min/max/step for the keys that are exposed.</li>
<li>A way to list specific keys, rather than a catch-all <code>default</code></li>
</ul>
<h2 id="functional-syntax" tabindex="-1"><a class="header-anchor" href="#functional-syntax">Getting group properties dynamically</a></h2>
<p>Currently, we can only access properties via static offsets, even when dynamic variations are allowed.
If we automatically exposed a functional syntax for every group, we could select the right token on the fly, possibly as a result of calculations.
Nested groups would simply involve more than one argument.</p>
<p>This would also allow mapping design tokens to a different naming scheme and reducing verbosity.
E.g. suppose we have <code>--spectrum-global-color-celery-100</code> to <code>--spectrum-global-color-celery-1300</code> and we want to map them to <code>--color-green-1</code> to <code>--color-green-13</code>,
i.e. not just a different prefix, but also a different scale:</p>
<pre><code class="language-css">/* Turn Spectrum colors into a group */
--spectrum-global-color: {};
--spectrum-global-color-celery: {};

--color-green: {
	default: --spectrum-global-color-celery(calc(arg / 100));
}
</code></pre>
<p>One downside to simply making these functions is that they could potentially clash with custom functions.
Roma Komarov <a href="https://github.com/w3c/csswg-drafts/issues/9992#issuecomment-1962321439">proposed</a> a separate <code>get()</code> function that would take the prefix as its first argument.
I quite like this, and it means it can ship separately, as it can be based on property naming, not groups.
This also means it does not require converting anything into groups.
So the example above would be way simpler:</p>
<pre><code class="language-css">--color-green: {
	default: get(--spectrum-global-color-celery, calc(arg / 100));
}
</code></pre>
<h2 id="decomposed-alternative" tabindex="-1"><a class="header-anchor" href="#decomposed-alternative">Alternative decomposed design</a></h2>
<p>We could decouple this into three separate features.
This is likely easier to implement as a whole, but also these features can ship independently and add value on their own.
However, it also makes it less ambitious, as it becomes harder to add some of the more advanced features (e.g. continuous variations).</p>
<h3 id="a-function-to-map-css-variables-with-a-common-prefix-to-a-different-prefix" tabindex="-1"><a class="header-anchor" href="#a-function-to-map-css-variables-with-a-common-prefix-to-a-different-prefix">A function to map CSS variables with a common prefix to a different prefix</a></h3>
<p>A <code>var()</code>-like function (e.g. <code>vars()</code>, <code>group()</code>) for mapping many variables with a common prefix to a different prefix.</p>
<pre><code class="language-css">--color-primary: group(--color-green);
</code></pre>
<p>Maybe even <code>var()</code> itself, where we’d distinguish between the two because the var reference would include an asterisk:</p>
<pre><code class="language-css">--color-primary: var(--color-green-*);
</code></pre>
<p>The downside of this is that it’s unclear whether that also sets <code>--color-primary</code> to <code>var(--color-green)</code>.
Perhaps we should give up on base values and do:</p>
<pre><code class="language-css">--color-primary: var(--color-green);
--color-primary-*: var(--color-green-*);
</code></pre>
<p>That is certainly more explicit, at the cost of verbosity and potential for error.</p>
<h3 id="a-nesting-syntax-for-setting-multiple-variables-with-the-same-prefix-at-once" tabindex="-1"><a class="header-anchor" href="#a-nesting-syntax-for-setting-multiple-variables-with-the-same-prefix-at-once">A nesting syntax for setting multiple variables with the same prefix at once</a></h3>
<p>This would look just like the one above, but instead of specifying a group, it is just syntactic sugar for setting many variables at once.</p>
<h3 id="continuous-variations%3F" tabindex="-1"><a class="header-anchor" href="#continuous-variations%3F">Continuous variations?</a></h3>
<p>If nesting is merely syntactic sugar, that definitely makes it harder to add continuous variations as a feature.
It would need to be a separate feature that does not depend on nesting.</p>
<p>Perhaps something like this could work:</p>
<pre><code class="language-css">--color-green-*: color-mix(in oklch, var(--color-green-100) calc((100 - arg / 10) * 1%), var(--color-green-900));
</code></pre>
<p>or:</p>
<pre><code class="language-css">--color-green-[tint]: color-mix(in oklch, var(--color-green-100) calc((100 - tint / 10) * 1%), var(--color-green-900));
</code></pre>
<p>It is unclear whether these are possible syntax-wise, since we had to introduce a bunch of restrictions to future syntax to make <code>&amp;</code>-less nesting work.</p>
<h2 id="other-ideas" tabindex="-1"><a class="header-anchor" href="#other-ideas">Other ideas explored</a></h2>
<p>Some of the following may be useful in their own right, but I don’t think solve the pain points equally well.</p>
<h3 id="custom-functions" tabindex="-1"><a class="header-anchor" href="#custom-functions">Custom Functions</a></h3>
<p>At first glance it appears that <a href="https://github.com/w3c/csswg-drafts/issues/9350">custom functions</a> can solve all of these issues.
Instead of defining tokens like <code>--color-red-200</code> authors would instead be defining <code>--color-red(200)</code>.</p>
<p>There are several issues with this approach.</p>
<ol>
<li>Aliasing becomes extremely heavyweight as it requires a whole new function:</li>
</ol>
<pre><code class="language-css">@function --color-red(--tint: 40) {
	/* ... */
}

@function --color-primary(--tint: 40) {
	result: --color-red(var(--tint));
}
</code></pre>
<ol start="2">
<li>Which part is variable is part of the syntax, so e.g. in the example above, there is no clear path to defining a <code>--color()</code> function from that.</li>
<li>There is no way to pass a few key colors to a component or subtree and have the rest be computed from them.
In fact, we cannot pass functions around at all, only the result of their invocation.</li>
<li>Functions are global, whereas things like “primary color” often need to be scoped to a subtree.</li>
<li>The fallback story is unclear (see <a href="https://github.com/w3c/csswg-drafts/issues/9990">#9990</a>)</li>
<li>This approach works far better for tints that are generated as samples on a continuous axis.
It is unclear how a set of predefined tints would look like as something like that.</li>
<li>The migration path from existing design systems is rocky, whereas nested groups paves the cowpaths by allowing the same syntax to continue to be used and even provides a way to convert <em>existing</em> tokens to a group (and potentially <a href="#functional-syntax">allowing a functional syntax <em>as well</em></a>).</li>
<li>This only allows a single level, so entire palettes or design systems cannot be passed around unless the entire design system is encapsulated in a single function.</li>
</ol>
<h3 id="tint-shade" tabindex="-1"><a class="header-anchor" href="#tint-shade">Handle tints and shades in CSS …automagically?</a></h3>
<p>This idea involves trying to eliminate the need for precomputed variations by simply doing it in CSS. E.g. <code>color-tint(var(--color-yellow) 30%)</code>.
While these functions would be useful in their own right, it is incredibly difficult (and likely impossible) to design something that would completely remove the need for custom designer intervention due to the <a href="">lack of uniformity in the current manual palettes</a>.</p>
<h3 id="design-systems-syntax" tabindex="-1"><a class="header-anchor" href="#design-systems-syntax">Make design systems a first-class citizen</a></h3>
<p>This would involve standardizing a dedicated syntax and naming scheme (for the low level common denominator things — tints, hues, fonts, etc.) for design tokens,
and providing authors with a whole different syntax for passing design tokens around.
In some ways a bit like <code>accent-color</code> on steroids.</p>
<p>There is certainly some value in such an endeavor:</p>
<ul>
<li>Something like this would work <em>wonders</em> for making it easier to integrate web components into a page without having to tweak a ton of knobs (since even with variable groups, the component needs to be aware of the naming scheme used for the variations)</li>
<li>Similarly, authors could experiment with different themes without having to tweak anything in their own CSS or page.</li>
<li>They would be visible everywhere, even in non tree-abiding pseudo-elements and <code>@-rules</code> (but we could solve that in a much simpler way, e.g. via a <code>@document</code> or <code>::document</code> rule).</li>
</ul>
<p>However, this would be a far bigger undertaking and the Impact / Effort does not seem favorable.
It is unclear if there is any advantage other than standardizing names (which could simply be “standardized” by convention).
Variables get you a lot out of the box, that with this would need to redefine.
E.g. it would be very important to pass design tokens to SVGs, but <a href="https://tabatkins.github.io/specs/svg-params/">SVG params</a> are designed around variables.</p>
<p>It is also unclear if baking a naming scheme into CSS, even just for the lowest common denominator things, is feasible, given the amount of variation out there.</p>
<hr>
<p>I ran this by a couple design systems folks I know, and the response so far has been overwhelmingly “I NEED THIS YESTERDAY”.
While I’m pretty sure the design can use a lot of refinement (especially around continuous values) and I have not yet checked with implementors about feasibility, I’m really hoping we can prioritize solving this problem.</p>
<p>Note that beyond design systems, this would also address many (most?) of the use cases around maps that keep coming up (don’t have time to track them down right now, but maybe someone else can).</p>