fix(passage): let the stimulus tabs follow the theme PIE-818 - #3097
Merged
Conversation
The paired-passage tabs stayed white with black ink on every color scheme while the passage body beneath them went dark, because the tab fill, the tab ink and the selection indicator came from MUI's palette (`theme.palette.common.white` / `.black`), which does not follow `--pie-*`. They now read `color.background()` and `color.text()` from `@pie-lib/render-ui`, which resolve to `var(--pie-background, ...)` and `var(--pie-text, ...)` -- the same tokens the passage body already uses, so the tab now carries the colour of the panel it opens. The two `#D9DADA` borders -- the tab outline and the strip's bottom rule -- become `color.borderGray()`. The literal measured roughly 1.2:1 against the dark schemes' surfaces, and the tab outline is the only thing separating an unselected tab from the strip, so it was effectively absent exactly where it did the most work. `--pie-border-gray` is stepped to the 3:1 non-text minimum in every built-in scheme. The strip behind the tabs keeps a host-supplied `--pie-passage-header-background` unchanged on every scheme, which is deliberate: Knowledge Checks' pale green-blue is a client decision and not a scheme's business to override. What changes is the no-host fallback, from a white literal to `color.backgroundDark()`, so the strip follows the theme instead of staying white over a dark body. That covers hosts which never opt in, including the section player when its own card-header token is unset. Both `theme.palette.common.*` lines carried "replace with color.background() once PD-2801 is DONE". PD-2801 is about adding background styling to OT's `color-contrast` class -- the mechanism pie-theme superseded -- and has been Blocked since 2023, so it no longer gates this. Not changed: the selected indicator stays `color.tertiary()` and the MUI indicator bar stays `color.white()`. Both already resolve through tokens every scheme sets, `--pie-white` being remapped to the scheme's own background rather than to white.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The paired-passage tabs stayed white with black ink on every color scheme while the
passage body beneath them went dark, because the tab fill, the tab ink and the selection
indicator came from MUI's palette (
theme.palette.common.white/.black), which does notfollow
--pie-*. They now readcolor.background()andcolor.text()from@pie-lib/render-ui, which resolve tovar(--pie-background, ...)andvar(--pie-text, ...)-- the same tokens the passage body already uses, so the tab nowcarries the colour of the panel it opens.
The two
#D9DADAborders -- the tab outline and the strip's bottom rule -- becomecolor.borderGray(). The literal measured roughly 1.2:1 against the dark schemes'surfaces, and the tab outline is the only thing separating an unselected tab from the strip,
so it was effectively absent exactly where it did the most work.
--pie-border-grayisstepped to the 3:1 non-text minimum in every built-in scheme.
The strip behind the tabs keeps a host-supplied
--pie-passage-header-backgroundunchanged on every scheme, which is deliberate: Knowledge Checks' pale green-blue is a
client decision and not a scheme's business to override. What changes is the no-host
fallback, from a white literal to
color.backgroundDark(), so the strip follows the themeinstead of staying white over a dark body. That covers hosts which never opt in, including
the section player when its own card-header token is unset.
Both
theme.palette.common.*lines carried "replace with color.background() once PD-2801is DONE". PD-2801 is about adding background styling to OT's
color-contrastclass -- themechanism pie-theme superseded -- and has been Blocked since 2023, so it no longer gates
this.
Not changed: the selected indicator stays
color.tertiary()and the MUI indicator barstays
color.white(). Both already resolve through tokens every scheme sets,--pie-whitebeing remapped to the scheme's own background rather than to white.
Verification
Builds and lints clean. Not verified in a rendered dark scheme: reproducing the tabs needs a
passage-pair item from the datastore (E266912 in the ticket), which needs a session, and this
package has no standalone demo page with a pair. Someone with a dev login should walk the
repro in the ticket before this is called done.
Not in scope
Heather's Figma also gives the unselected tab a distinct darker fill, where the component
still distinguishes selection by
.passage-labelopacity plus the underline. That is a designrefinement rather than a theming defect, so it is left alone here.