Dark palette scales are non-monotonic: step 6 duplicates step 3

[pomfrida]

Found during the Chip dark-mode comparison (#5225) and first documented in a comment on #5221. Still present in the latest Tokens Studio release (pulled in #5280), so filing it separately now that #5221 is being closed.

Problem

In every dark scale, step 6 is byte-identical to step 3, and step 4 is lighter than step 6 — the lightness ladder is non-monotonic. From the CSS export in #5280:

--eds-dark-north-sea-3: oklch(0.47 0.0187 242.96);
--eds-dark-north-sea-4: oklch(0.52 0.0242 242.96);
--eds-dark-north-sea-5: oklch(0.58 0.0303 242.96);
--eds-dark-north-sea-6: oklch(0.47 0.0187 242.96); /* == step 3 */
--eds-dark-north-sea-7: oklch(0.61 0.0328 242.96);

Same duplicate in dark-blue, dark-moss-green and dark-red (3 == 6 in all of them). The light scales are monotonic in the current export.

Related observation from the same finding: step 2 in dark (L 0.226) is nearly the canvas value (step 1 = L 0.19), so subtle/muted fills on step 2 are almost invisible against the dark canvas. In light the step 1 vs 2 difference is equally small but reads fine; in dark it is the difference between a visible fill and a ghost. See the dark-mode comparison comment on #5225 for measured values and screenshots.

Impact

• Any state ladder that steps 4 → 6 in dark inverts: pressed renders darker than hover and identical to step 3 (Button secondary/ghost currently consumes accent-4/accent-6 directly for hover/pressed).
• border.neutral.strong = {neutral.6} renders the same as step 3 in dark.
• The background.interactive.*.muted ladders (steps 1–4) sit almost on the canvas at their default step in dark.

Likely cause

The raw scheme sets define each step as a formula: set_chroma(set_lightness({input.palette.<scale>.anchor}, {input.scale.dark.<N>}), {foundation.gaussian.dark.<N>} * …). Since both L and C are identical between steps 3 and 6 across all scales, {input.scale.dark.6} (and the matching gaussian input) most likely holds the wrong value. The fix belongs on the Tokens Studio side (input scale sets), followed by a new release and studio tokens pull.

Relates to #4742 / parent epic #4740.

[claude]

These may be related to this issue:

• [Button] Migrate to new beta colour tokens #5208 — [Button] Migrate to new beta colour tokens (open): Button secondary/ghost consumes accent-4/accent-6 for hover/pressed, which is exactly the pair that inverts in dark while step 6 duplicates step 3.
• [Chip] Migrate to new beta colour tokens #5223 — [Chip] Migrate to new beta colour tokens (open): Chip's subtle fill ladder uses steps 2/4/6, so it hits both the duplicate step 6 and the near-canvas step 2 — this was found during that migration's dark-mode comparison.
• 🎛 Review & Refine Colour Token values #4742 — 🎛 Review & Refine Colour Token values (open): the design + dev track for the expanded static scale's values, which is where a corrected input.scale.dark.6 would land before a new Tokens Studio release.
• Author import-ready Tokens Studio JSON for the missing beta colour tokens #5221 — Author import-ready Tokens Studio JSON for the missing beta colour tokens (closed as completed): where this duplicate was first documented in a comment; it was closed once the JSON was authored, so the palette-value fix was not part of that resolution.

This comment was generated by an LLM and may be inaccurate. Please verify that the linked issues are actually relevant.

[pomfrida]

Chip dark mode bug found in PR #5225 :

Chip dark mode in prod:

[pomfrida]

From the Chip migration (#5225), one design decision to fold into this rework: in dark mode, should a resting muted fill be subtle (close to the background, which is what shade 2 gives) or clearly grey like the legacy palette renders in production today?

We measured what production actually uses, and it turns out legacy resolves to the beta scale's shades 3/4/5 (rest/hover/pressed) in both light and dark mode — the semantic muted tokens currently point at 2/3/4, one shade lighter across the board. In light mode that difference is barely visible; in dark mode it's dramatic because of the broken shade values this issue covers.

So if the goal is to keep the production look, the fix is to repoint the semantic muted tokens (background-interactive-*-muted-default/hover/pressed) from shades 2/3/4 to 3/4/5 in the Tokens Studio source. Worth noting: shades 3/4/5 progress smoothly even in today's broken dark palettes, so that part doesn't depend on the regeneration — though the palettes still need fixing for everything else.

Chip (#5225) is held in draft on this either way, and follows automatically once the decision lands in a token release.

[pomfrida]

Verified the new release (#5284): the shade 6 duplicate is fixed in all seven dark palettes — 0.47 → 0.595, now sitting neatly between shades 5 (0.58) and 7 (0.61). Thanks!

Flagging what's still open before this issue gets closed, because it's the part testers actually notice in dark mode: the jump between shade 2 (L 0.226) and shade 3 (L 0.47) is unchanged. A resting chip is still nearly invisible against the background, and hover still jumps in brightness.

That ties into the open question above: either keep the production look by repointing the muted tokens to shades 3/4/5, or keep 2/3/4 and smooth out the low end of the dark palettes. Both are fine — but one of them has to happen before Chip (#5225) can ship dark mode.

[eddiman]

Went through the live Tokens Studio project with tsctl to check the state of this after the #5284 release. Confirming the fix, plus two findings that change what's left.

Step 6 is fixed, confirmed live

input.scale.dark.6 now reads 0.595 (was 0.47), so the duplicate is gone in all seven dark palettes. Matches @pomfrida's verification.

New: the same inversion exists at step 12, and it fails LC90

input.scale.dark.11/12/13 = 0.93 / 0.91 / 0.99. Step 12 is darker than step 11 — the identical defect as step 6, just at the top of the ladder, and it's still live.

Because the chroma gaussian is driven by L, chroma wobbles with it too: step 11 resolves to oklch(0.93 0.0187 …) and step 12 to oklch(0.91 0.0209 …) — darker and more saturated.

What consumes it:

• text.primary and icon.primary = {neutral.12} → measures Lc 88.0 against background.canvas in dark. That is below our LC90 body-text target, and below text.interactive.*.hover at step 11 (Lc 92.2).
• text.interactive.* default/hover/pressed = steps 10/11/12 = 0.88 → 0.93 → 0.91. Pressed renders darker than hover.

As a standalone fix: input.scale.dark.12: 0.91 → 0.96. That gives an even 0.93 / 0.96 / 0.99 at the top and lands text.primary at Lc 98.5, clearing LC90. One number, no design decision.

(If the full ladder re-derive below happens instead, step 12 wants 0.92 — but only because step 11 drops to 0.90 in that ladder. 0.92 on its own would leave the inversion in place. The two aren't interchangeable.)

Steps 5/6/7 are compressed

The step 6 fix wedged a value between its neighbours rather than redistributing, so 5/6/7 = 0.58 / 0.595 / 0.61 now deliver Lc 31.5 / 33.6 / 36.4 — a 4 Lc spread where light spans 27.6 / 36.3 / 44.5. border.*.strong (6) and text.tertiary (7) are effectively the same colour in dark. Step 7 is the single worst value on the ladder, ~9 Lc short of its light twin.

On the muted-token question

Measuring in Lc rather than ΔL changes the framing here, so flagging it for the open decision above.

The ΔL 0.244 cliff at 2→3 is not itself a defect — at low luminance you need a large ΔL to buy any contrast. Dark spends 0.24 L to reach Lc 11; light spends 0.03 L for the same Lc 11. The ladder is already at rough parity from step 3 to 8.

What the numbers do show is that step 2 delivers Lc 0.0 against the canvas in both modes:

step	light on canvas	light on surface	dark on canvas	dark on surface
2	0.0	8.4	0.0	0.0
3	11.0	14.2	17.7	18.4

Steps 1–2 are canvas/elevation planes; component fills start at 3. Light gets away with it only because most components carrying a muted fill sit on background.surface, which in light is pure white one notch above canvas and clears the APCA clamp. In dark, surface is L 0.10 — below canvas — so both backdrops stay under the clamp and there's no equivalent rescue.

So the 2/3/4 → 3/4/5 repoint is a correction, not a workaround, and it applies to light too: a muted chip placed directly on the page canvas is Lc 0.0 in both modes today. It needs no palette regeneration and can ship ahead of any ladder work.

Two more in the same group while we're there:

• background.interactive.neutral.muted.* is on 1/2/3 while the other five hues are on 2/3/4, so background.interactive.neutral.muted.default resolves to exactly background.canvas.
• background.interactive.disabled, .read-only, border.neutral.subtle, border.interactive.disabled and the static background.{danger,info,success,warning} all point at step 2 and carry the same canvas-only failure.

Suggested split

1. input.scale.dark.12: 0.91 → 0.96 — standalone, fixes an a11y target miss. Staged on a scratch branch, ready for review.
2. Repoint the muted ladders to 3/4/5 in the semantic set — unblocks Chip (refactor: migrate Chip (next) colours to beta tokens #5225).
3. Re-derive the dark ladder so every step matches its light counterpart's Lc, which subsumes the 5/6/7 compression and the step-13 overshoot (currently Lc 104.8 vs light's 94.7 — also a halation win). Bigger blast radius, wants a design review and visual diff pass.

Worth noting 2 and 3 interact: under a re-derived ladder, step 3 sits at L 0.41 rather than 0.47, so "match light-mode contrast" and "match the legacy production look" stop coinciding. That's the real decision to make.