Relative Alpha Colors

[CGQAQ]

Specification title

Relative Alpha Colors

Specification or proposal URL (if available)

https://drafts.csswg.org/css-color-5/#relative-alpha

Explainer URL (if available)

No response

Proposal author(s)

No response

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

No response

WebKit standards-position

WebKit/standards-positions#657

Other information

Relative alpha colors refer to an origin color, and only change the alpha channel. The meaning of alpha channels is defined in CSS Color 4 § 4.2 Representing Transparency in Colors: the syntax.

[keithamus]

/cc @emilio @tiaanl

[emilio]

seems not too hard, but is a custom function warranted? color-mix and rcs are existing ways of doing this right?

[CGQAQ]

Adjusting the transparency of a color is one of the most common operations in CSS, yet the current toolset forces authors into unnecessarily verbose or semantically misleading patterns. Developers regularly reach for workarounds such as:

• Hard-coding RGBA values (losing the connection to design tokens or custom properties)
• Using color-mix(in srgb, var(--color) 50%) — a variadic trick that is non-obvious and hard for most authors to understand intuitively, also this is not implemented in any browsers IIRC
• Writing full relative color syntax like rgb(from var(--color) r g b / 0.5) — which forces the author to pick a color space even though alpha is colorspace-agnostic, and to redundantly spell out channel keywords that carry no meaning in this context

The core insight motivating alpha() is that alpha manipulation is invariant of color space. Whether you write rgb(from pink r g b / 0.3) or oklab(from pink l a b / 0.3), the result is identical in terms of transparency. Requiring authors to specify and repeat channel keywords, or to choose a color space, is pure ceremony that obscures intent.

A dedicated alpha(from var(--color) / 0.5) function would:

1. Make intent immediately legible. Any developer reading alpha(from var(--glow-color) / 0.25) instantly understands that only the transparency is changing.
2. Work naturally with CSS custom properties and light-dark(). Patterns like alpha(from light-dark(white, black) / 85%) or alpha(from var(--brand-color) / 0.6) are precisely what authors need in design-token-driven systems.
3. Avoid the colorspace selection trap. Because it doesn't change any channel values, there's no need to involve a color space at all — the origin color is returned in its original space with only alpha modified.
4. Align with developer mental models. As the Mastodon poll result confirms (55% for alpha() vs. 42% for opacity()), authors correctly distinguish between element-level opacity (the opacity property, which affects children) and color-level alpha (which affects only the color value itself).
5. Permit relative alpha adjustments. Supporting alpha(from var(--color) / calc(alpha * 0.8)) would cover the incremental-transparency case that's currently painful to express in any notation.

See: w3c/csswg-drafts#10689 for more details

[romainmenke]

The core insight motivating alpha() is that alpha manipulation is invariant of color space.

This is especially important because the color space might not be known to the author (variables provided by a 3rd party library, or an export from a design system).

And the chosen color space can have side effects.
For example a color described in oklch should have gamut mapping, while a color described in color(display-p3 ...) should not have gamut mapping. (even if no browser currently ships gamut mapping)

Without the alpha() function it is impossible to mutate only the alpha without unintended consequences.