Repository navigation
Fix #1309: declare color-scheme so native UA surfaces follow dark mode - #1324
Merged
Merged
Conversation
…de (#1309) The chrome's `:root` / `html.dark` token blocks swap CSS custom properties for DOM-rendered surfaces, but that has no effect on surfaces the browser paints in its top-layer system UI: the open `<select>` dropdown panel, native scrollbars, `<input type="date| time|color">` pickers, and form autofill highlighting. Without a declared `color-scheme`, the browser uses its UA default (light) for those surfaces regardless of `html.dark`. The result is most jarring on mobile (iOS Safari, several Android Chromes) where the native `<select>` picker full-screens — opening a Server / Time / Type filter on `?p=banlist` slides a stark-white sheet over an otherwise dark page. Desktop scrollbars and autofill highlighting flash light too. Fix: add `color-scheme: light` to `:root` and `color-scheme: dark` to `html.dark`. The browser then renders the matching scheme for the system surfaces above. The `prefers-color-scheme` media query the JS theme resolver consumes (`web/themes/default/js/theme.js`) reads the OS preference, not the page's declared scheme, so the existing system-pref / toggle path is unaffected. Regression test: `web/tests/e2e/specs/a11y/color-scheme.spec.ts` locks `getComputedStyle(document.documentElement).colorScheme` under both pinned themes via the same `pinTheme` helper shape as `a11y/dark-theme-contrast.spec.ts`. The mobile symptom (full-screen picker) is painted outside the DOM so it can't be read by JS at any viewport, but the contract under test (the declared property) is the upstream cause. Fixes #1309
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
1 participant
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.
Fixes #1309.
Summary
color-scheme: lightto:rootandcolor-scheme: darktohtml.darkinweb/themes/default/css/theme.cssso the browser paints native UA surfaces (the open<select>dropdown panel, native scrollbars,<input type="date|time|color">pickers, and form autofill highlighting) in the matching scheme. Pre-fix the chrome's dark tokens swapped correctly for DOM-rendered surfaces, but anything painted in the browser's top-layer system UI ignoredhtml.darkand rendered light — most jarring on mobile (iOS Safari especially) where the native<select>picker full-screens, sliding a stark-white sheet over an otherwise-dark?p=banlistpage when the user tapped the Server / Time / Type filter.web/tests/e2e/specs/a11y/color-scheme.spec.tsas the regression guard. AssertsgetComputedStyle(document.documentElement).colorSchemeresolves todarkunder pinned dark mode andlightunder pinned light mode, using the samepinTheme(localStorage['sbpp-theme'] + waitForFunction)helper shape asa11y/dark-theme-contrast.spec.ts. Chromium-only (the rule is token-driven; viewport doesn't change the computed value, and the mobile symptom — full-screen picker — is painted outside the DOM so JS can't read it at any viewport).AGENTS.mdnext to the existingprefers-reduced-motionrow so future contributors find thecolor-schemedeclarations + the regression spec without grepping.The fix is the literal suggested fix in the issue body. The
prefers-color-schememedia query the JS theme resolver consumes (web/themes/default/js/theme.js) reads the OS preference, not the page's declared scheme, so the existing system-pref / toggle path is unaffected.Test plan
Ran locally against this worktree's stack (
sbpp-task-1309):./sbpp.sh phpstan— pass (No errors, 228 files analysed at level 5)../sbpp.sh test— pass (403 tests, 1765 assertions; the one PHPUnit deprecation pre-exists onmain)../sbpp.sh e2e --grep "color-scheme"— both new tests pass on chromium; mobile-chromium project skips by design../sbpp.sh e2e --grep "dark-theme contrast|theme toggle"— 13 passed / 7 skipped (no regressions in the related dark-theme + theme-toggle gates).Skipped (no surface touched):
./sbpp.sh ts-check— no.js/.tschanges../sbpp.sh composer api-contract— no API handler changes.