Skip to content

fix(theming): move the grey palette reads onto --pie-* tokens PIE-856 - #2310

Merged
CarlaCostea merged 1 commit into
developfrom
fix/PIE-856-grey-palette-tokens
Aug 20, 2026
Merged

fix(theming): move the grey palette reads onto --pie-* tokens PIE-856#2310
CarlaCostea merged 1 commit into
developfrom
fix/PIE-856-grey-palette-tokens

Conversation

@chillenious

@chillenious chillenious commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

What

theme.palette.grey[N] does not follow --pie-*, so every one of those reads held a
fixed hex under every colour scheme. This moves the ten reads in config-ui,
editable-html-tip-tap and math-toolbar onto the color.*() accessors, and adds
color.buttonFocusOutline() for --pie-button-focus-outline.

Part of PIE-856. The pie-elements half is
pie-framework/pie-elements#3102, and both need to land before
pie-elements-ng can sync the generated files.

Why these tokens

Measured against each scheme's own --pie-background across the ten schemes in
pie-playerspackages/theme/src/color-schemes.css:

role token worst ratio
stroke, divider, connector --pie-border 3.23:1
focus ring --pie-button-focus-outline 3.68:1
text, interactive icon --pie-text 6.21:1
disabled affordance --pie-disabled 3.17:1
fill --pie-background-dark n/a — a fill belongs close to the page

--pie-border-light is not used for strokes: it measures 1.53:1 in the default scheme.
--pie-keyboard-focus-indicator is not used for the focus rings even though
color.keyBoardFocusIndicator() exists — it is absent from the pie-players token
registry, so no scheme can reach it. --pie-button-focus-outline is
canonical-semantic/active there, which is why the new accessor points at it.

Notable

The two editor focus rings were drawing themselves in grey[700] — 1.28:1 on
yellow-on-navy.

settings-box moves background.paper to --pie-white alongside its stroke. Both have
to move together: background.paper is MUI's #fff regardless of scheme, so tokenising
the stroke alone would put a scheme's border colour on a permanently white panel, and
under white-on-black --pie-border is #ffffff — the outline would vanish. --pie-white
inverts with the scheme, which is what background.paper was standing in for.

#C0C3CF in MathTemplated is --pie-blue-grey-300's default value, but that token is
a fill and measures 1.00:1 against some schemes' backgrounds, so the response-slot
outline takes the stroke token instead.

Tests

packages/config-ui/src, packages/math-toolbar/src,
packages/editable-html-tip-tap/src and packages/render-ui/src: 85 suites, 1278
passing. eslint at exact parity with develop — 0 errors, same 119 warnings, none new.

Two toolbar-buttons assertions changed. They pinned color: 'black'; jsdom does not
resolve custom properties, so toHaveStyle normalises var(--pie-text, black) to the
empty string and cannot compare it. They now read the declaration emotion emitted for
the element's class.

MUI's palette does not follow `--pie-*`, so every `theme.palette.grey[N]` read held a
fixed hex under every colour scheme. Measured against each scheme's own
`--pie-background`, shades 100-500 fall below the 3:1 non-text minimum in six of the
ten schemes and 600-800 in three or four, so none of these reads were correct -- the
multiple-choice separator George reported is the visible end of one defect, not a
special case.

Each site moves to the accessor that matches its role rather than to one replacement
token, because the roles differ and so do the contrast requirements:

- strokes, dividers and connectors -> `color.border()`, which holds at least 3.23:1
  against every scheme's background. `--pie-border-light` was rejected for these: it
  measures 1.53:1 in the default scheme.
- fills -> `color.backgroundDark()`, and pressed or selected fills ->
  `color.dropdownBackground()`. A fill is meant to sit close to the page, so the 3:1
  floor does not apply to it; whatever stroke sits on it carries the separation.
- text and interactive icons -> `color.text()`. No neutral token clears 4.5:1 in every
  scheme (`--pie-border-gray` tops out at 3.17:1), so muted body text has no
  scheme-following option and takes full-strength ink.
- de-emphasised non-text glyphs -> `color.borderGray()`, where 3:1 is the requirement.
- disabled affordances -> `color.disabled()`, whose default is the same `grey` literal
  several of these sites already used.

Three surfaces move alongside their strokes. `palette.common.white` and
`background.paper` are MUI's #fff regardless of scheme, so tokenising a stroke while
leaving the surface fixed would put a scheme's border colour on a permanently white
panel -- under white-on-black, `--pie-border` is #ffffff, which would erase the outline
the change was meant to fix. `--pie-white` inverts with the scheme, which is what those
two were standing in for.

Adds `color.buttonFocusOutline()` for `--pie-button-focus-outline`, used by the two
editor focus rings that were drawing themselves in grey[700] -- 1.28:1 on
yellow-on-navy. `--pie-keyboard-focus-indicator` was the other candidate and is not
used: it is absent from the pie-players token registry, so no scheme can reach it.

`#C0C3CF` in MathTemplated is `--pie-blue-grey-300`'s default, but that token is a fill
and measures 1.00:1 against some backgrounds, so the response-slot outline takes the
stroke token instead.

The two toolbar-button assertions pinned `color: black`; jsdom does not resolve custom
properties, so `toHaveStyle` flattens `var()` to the empty string and cannot compare it.
They now read the declaration emotion emitted. The `row.test.jsx` render-ui mock gains
`border`, the accessor answer-config-block now calls.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants