feat: apply token opacity with color-mix()

[tenphi]

Follow-up to #266.

What

The color-token opacity suffix now applies alpha to the token's color, not to its decomposed channel components:

#purple.5
  before  oklch(var(--purple-color-oklch) / .5)
  after   color-mix(in oklab, var(--purple-color) 50%, transparent)

Same color. Mixing premultiplied against a fully transparent color leaves the channels untouched and sets the alpha, so the result is exactly what the channel-level / <alpha> produced — verified against the old form in headless Chromium, including a display-p3 color that in srgb would have clamped.

Why

The old form needed the token decomposed into numbers before opacity could be applied. That is not always possible, and when it failed it failed silently:

Case	Before	After
--ink-color declared in your own CSS, no Tasty token definition	no --ink-color-oklch exists → @property initial value → renders black	fades correctly
'#brand': 'color-mix(…)' then #brand.5	needed the relative-components companion added in #266, and an @property … syntax: "*" to survive	works with nothing extra
#current.5	already special-cased to color-mix()	same path as everything else

So this removes a class of silent wrong-color bugs and collapses three code paths into one.

The mixing space is always oklab, whatever colorSpace is set to — alpha application is space-independent, and oklab is unbounded, so a wide-gamut color survives the round trip.

What is not changing

• --name-color-{space} companions stay. Still generated, still registered as @property, still typed <number>+ where the channels are numeric, and still what you reach for to address a token's channels. They're just no longer load-bearing for opacity.
• The companion still follows the color through a fade. convertColorChainToComponentChain peels the wrapper before converting, so color="#purple.5" still emits --current-color-oklch: var(--purple-color-oklch) — components carry no alpha.
• Replace tokens are still faded in place. A token substituted at parse time has its color right there, so a channel function takes the slash alpha (#brand: 'hsl(220 90% 50%)' → #brand.5 → hsl(220 90% 50% / .5)) and a derived one is wrapped. Shorter output, no needless space conversion, and the color()/okhsl() plugin paths keep working unchanged.

What changes for consumers

• Generated CSS changes for every #token.alpha. The color is the same, but consumer snapshots over emitted CSS or getComputedStyle need updating — computed colors serialize as oklab(…) now.
• color-mix() is required on the common path, moving the effective floor to Safari 16.2 (from 15.4). Chrome 111 and Firefox 113 unchanged; #current.5 already required it.
• parseColor().color returns the wrapper. .name and .opacity are unchanged — both are read through it.

The public API is unchanged, so the changeset is minor.

Also fixed

color(name, 0.07) emitted 7.000000000000001% — opacity * 100 is not exact in IEEE 754 for 8 of the 99 hundredths.

Tests

pnpm test — 2066 pass (70 files). New coverage:

• src/applied-styles.test.tsx — the headline case (a colour variable Tasty never registered, faded correctly), and an equivalence check proving color-mix alpha == channel-slash alpha for sRGB, oklch and display-p3 colours.
• src/parser/parser.test.ts — the new form for .N, .NN, .0, .$prop, a hex token, and that the mixing space ignores colorSpace.
• src/utils/styles.test.ts — parseColor reading name and opacity through the wrapper, dynamic alpha reporting no number, and the color() float-artifact cases.
• src/styles.test.ts — the companion still naming the faded token's own channels, via colorStyle and via a #token definition.
• Snapshot updates in tasty.test.tsx.snap show --current-color-oklch surviving the change intact.

pnpm hygiene clean, knip clean, pnpm size within limits (static 18.86/19.25 kB), public API snapshot unchanged.

🤖 Generated with Claude Code

[github-actions]

📦 Snapshot release

Published 0.0.0-snapshot.73ab317.

pnpm add @tenphi/tasty@0.0.0-snapshot.73ab317

[tenphi]

I found two uncovered regressions in the opacity-suffix semantics.

[tenphi]

[P1] Preserve alpha-replacement semantics for runtime tokens

Wrapping the full variable multiplies any alpha already present in the token instead of replacing it as the old component/slash path did (and as the replace-token path still does). For a runtime token whose value is rgb(255 0 0 / .8), #token.5 now computes to alpha 0.4; before this change, and for the equivalent replace token today, it is 0.5. I confirmed the two results in Chromium. The same regression is present in the changed color(name, opacity) helper, which now also wraps --name-color. This makes runtime and replace tokens behave differently and visibly changes valid existing inputs, so both paths need to keep overriding the token's existing alpha (or the behavior needs to be treated as an intentional breaking change).

[tenphi]

[P1] Keep percentage-valued opacity variables valid

calc(var(--fade) * 100%) only works when --fade resolves to a unitless number. The previous slash-alpha form accepted either a <number> or a <percentage> (and the property resolver explicitly registers opacity variables as <number> | <percentage>). With --fade: 50%, this becomes percentage-times-percentage, so Chromium drops the whole color-mix() declaration; the same expression works for --fade: .5. Please preserve percentage inputs as well, or narrow and validate the public contract rather than silently emitting invalid CSS.

[tenphi]

[P2] Normalize numeric suffixes before emitting percentages

Now that this helper is used for every color token, ordinary DSL inputs inherit the same floating-point artifact that color() explicitly fixes in this PR: #token.07 emits 7.000000000000001%, and #token.29 emits 28.999999999999996%. The old slash form preserved the authored digits (.07, .29), so this is unnecessary generated-CSS churn and can leak through parseColor().opacity too. Please use the same bounded formatting here (or convert the digit string without floating-point multiplication).

[tenphi]

All three findings addressed in 2439331. I reproduced each in Chromium first — both P1s are exactly as described:

token rgb(255 0 0 / .8), #token.5	alpha
color-mix(… 50%, transparent)	0.4 — composes
old channel-slash form	0.5
oklch(from … l c h / .5)	0.5 — replaces

--fade: 50%	result
calc(var(--fade) * 100%) in a mix	rgba(0,0,0,0) — declaration dropped
/ var(--fade) in relative syntax	resolves; so does .5

Fix: relative color syntax rather than a mix. oklch(from <color> l c h / <alpha>) writes the alpha slot instead of compositing, so P1a is fixed by construction. The slot accepts <number> | <percentage>, so the $prop reference passes straight through unscaled — P1b fixed, and it now matches the <number> | <percentage> contract the property resolver registers for --*-opacity. With no percentage conversion left, P2 dissolves: .07 stays .07.

Everything the mix was chosen for is retained — it still needs nothing from the colour but that it is one, so a color-mix()/light-dark() token and a --name-color Tasty never registered both still fade.

oklch, not oklab. The two are interchangeable for a fade (channels are copied, not interpolated — I checked achromatic origins specifically, where a polar space could have carried an undefined hue: identical results, no tint). oklch wins on churn: it is the shape the computed value was already reported in, so consumers snapshotting computed styles now see no change at all. It stays fixed regardless of colorSpace — rgb(from …) would clamp a wide-gamut colour, and there's a test asserting a display-p3 red keeps chroma sRGB cannot hold.

Semantics now consistent between runtime and replace tokens: both replace the alpha. A statically-known colour is still faded in place (hsl(220 90% 50%) → hsl(220 90% 50% / .5)), which is the same operation written more directly.

New coverage: alpha replacement over an existing alpha, an opacity property in both number and percentage form, authored digits surviving verbatim, gamut preservation, and parseAlphaOverride unit tests including nested fades.

2075 tests pass, hygiene/knip clean, size within limits. Changeset stays minor, but the support floor note changed: relative color syntax is Chrome 119 / Safari 16.4 / Firefox 128 — a further step up from color-mix(). Flagging that explicitly since it's the one cost of this approach and it's your call.