Conversation
It has answered `prefers-color-scheme` since it was written, with a comment saying there is deliberately no switch — so someone on a light OS who wants dark, or on a dark OS reading in daylight, has no way to say so. The OS preference stays the default and gains two overrides. The dark values move onto the map's (#0d1b2a canvas, #132240 card, #38bdf8 accent, and the brightened semantics) from the slate set they had. That set was a third palette: the light tokens were already verbatim from the console, but the dark ones answered to neither the console nor the map, and the brand guide's §10 names drift as the estate's main failure mode. Anyone browsing in dark today will see the change; nobody loses a theme. `system` stamps no attribute and lets the media query answer, which is what keeps the OS preference working when it changes mid-session; `:root:not([data-theme="light"])` is what lets an explicit light choice win over a dark OS. Stamping a resolved value instead would pin the page to whatever the OS was at load. Two details the diff does not explain: - The pre-paint script is a file rather than an inline tag, for exactly the reason vendor/ exists: this vhost sends `script-src 'self'`, which does not cover inline code, while a laptop serving these files sends none — so an inline version works in every local check and silently never runs once deployed. - Merely opening the page persists nothing. This surface is public and unauthenticated, so `showTheme` and `chooseTheme` are separate and only a click on the control writes storage. `--accent-ink` is new because the dark accent is a bright sky blue: the white that inked the brand mark and the primary button is about 1.8:1 on it. Verified in a browser: a first visit writes no storage and follows the OS, a click persists and survives a reload, and returning to system clears the attribute and hands control back to the media query. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Claude finished @Babissimo's task in 2m 8s —— View job Code review
No issues found. Checked for bugs and CLAUDE.md compliance. Summary: This PR adds a System/Light/Dark switch to What I checked in detail:
No high-signal bugs or CLAUDE.md violations found by either independent review pass. |
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.
Adds a light/dark/system switch to
data.retina.fmand moves its dark paletteonto the map's.
Sibling of #382, which does the same for
dashandadmin. The two share no code — different apps, different build story — so thisbranches from
mainrather than stacking, and either can land first.What was already there
This surface is not gaining dark mode; it has answered
prefers-color-schemesince it was written. What it lacked was a way to say so: someone on a light
OS who wants dark, or on a dark OS reading in daylight, had no control. The OS
preference stays the default and gains two overrides.
What changes visibly
The dark values move onto the map's — canvas
#0d1b2a, card#132240, accent#38bdf8, and the brightened semantics — from the slate set they had. That setwas effectively a third palette: the light tokens were already verbatim from the
console, but the dark ones matched neither the console nor the map, and the brand
guide's §10 names exactly this drift as the estate's main failure mode. Anyone
browsing in dark today will notice; nobody loses a theme.
--accent-inkis new because the dark accent is a bright sky blue: the#fffthat inked the brand mark and the primary button sits at about 1.8:1 on it.
Two details worth a reviewer's attention
The pre-paint script is a file, not an inline tag — for precisely the reason
vendor/exists. This vhost sendsscript-src 'self', which does not coverinline code, while a laptop serving these files sends no CSP at all: an inline
version works in every local check and silently never runs once deployed.
Opening the page persists nothing. This surface is public and
unauthenticated, so
showTheme(stamp and mark the control) andchooseTheme(also write storage) are separate, and only a click writes.
The
retina.themekey and thedata-themeattribute are the names the dashboardconsole uses for the same job. Separate origins, so a stored choice cannot travel
between them — the matching names are what make the two one idiom rather than two.
Verification
No test suite or build step here, so this was checked in a browser:
data-themedarkdarkrgb(13, 27, 42)systemAn explicit choice survives a reload, and an explicit light beats a dark OS.
Follow-up
The brand guide in
claude-shareddescribes this surface as untheme-able and themap as "the only surface that themes". Worth a small PR there once both of these
land.
🤖 Generated with Claude Code