Build the settings page (/settings, currently a placeholder from #36) out with a theme/theme section:
List all available presets (midnight, smooth, pastel-lavender, pastel-peach, pastel-cloud) as selectable cards or swatch rows showing each palette's colors (render 5 mini swatches per preset from the same hex values the CSS uses).
Selecting one applies it IMMEDIATELY client-side (set data-preset on <html>, same mechanism as the ?theme= hook) so the user sees the whole page repaint live - no save button needed for the preview.
Persist the choice: store in localStorage (key e.g. palette-theme) and apply it on every page load via a tiny inline script in the layout head (before CSS paint to avoid flash). The existing ?theme= query param overrides localStorage for testing.
Default: midnight (current behavior for anyone with no stored preference).
This is the same mechanism the end product will use, so stage future presets by just adding their [data-preset] CSS block; they automatically appear in the switcher (read the preset list from a JS constant or scan the stylesheet).
Future/related: server-side preference storage per viewer cookie lands with #30 - the localStorage approach is the client-side half and stays as an override.
Build the settings page (/settings, currently a placeholder from #36) out with a theme/theme section:
- List all available presets (midnight, smooth, pastel-lavender, pastel-peach, pastel-cloud) as selectable cards or swatch rows showing each palette's colors (render 5 mini swatches per preset from the same hex values the CSS uses).
- Selecting one applies it IMMEDIATELY client-side (set data-preset on <html>, same mechanism as the ?theme= hook) so the user sees the whole page repaint live - no save button needed for the preview.
- Persist the choice: store in localStorage (key e.g. palette-theme) and apply it on every page load via a tiny inline script in the layout head (before CSS paint to avoid flash). The existing ?theme= query param overrides localStorage for testing.
- Default: midnight (current behavior for anyone with no stored preference).
This is the same mechanism the end product will use, so stage future presets by just adding their [data-preset] CSS block; they automatically appear in the switcher (read the preset list from a JS constant or scan the stylesheet).
Future/related: server-side preference storage per viewer cookie lands with #30 - the localStorage approach is the client-side half and stays as an override.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
QA review (69da340, dev server): fails check 2 — theme is not actually persisted.
✅ Check 1: /settings renders .theme-grid with 5 cards: Midnight, Smooth, Pastel Lavender, Pastel Peach, Pastel Cloud (verified in headless Chrome against palette-dev).
❌ Check 2: the click handler sets documentElement.dataset.preset and writes localStorage['palette-theme'], but nothing ever reads that key back — on reload dataset.preset is null and the page reverts to Midnight (verified live: after clicking Pastel Peach and reloading, dataset.preset=null, localStorage still pastel-peach, active card is Midnight). Need a restore in the layout/head script: read palette-theme and apply it on load.
✅ Check 3: swatch colors match the preset tokens in app.css (bg/surface/accent values align for all five themes).
✅ Check 4: Admin link present.
✅ Check 5: go vet ./... and go test ./... all pass.
Leaving open — one-line fix needed to read the saved theme on page load.
QA review (69da340, dev server): **fails check 2 — theme is not actually persisted.**
- ✅ Check 1: `/settings` renders `.theme-grid` with 5 cards: Midnight, Smooth, Pastel Lavender, Pastel Peach, Pastel Cloud (verified in headless Chrome against palette-dev).
- ❌ Check 2: the click handler sets `documentElement.dataset.preset` and writes `localStorage['palette-theme']`, but **nothing ever reads that key back** — on reload `dataset.preset` is null and the page reverts to Midnight (verified live: after clicking Pastel Peach and reloading, `dataset.preset=null`, localStorage still `pastel-peach`, active card is Midnight). Need a restore in the layout/head script: read `palette-theme` and apply it on load.
- ✅ Check 3: swatch colors match the preset tokens in app.css (bg/surface/accent values align for all five themes).
- ✅ Check 4: Admin link present.
- ✅ Check 5: `go vet ./...` and `go test ./...` all pass.
Leaving open — one-line fix needed to read the saved theme on page load.
fen
added spent time 25 seconds2026-09-09 23:39:34 +00:00
QA passed: dev CI image (7fde147, run #116) success; deployed to palette-dev; served /settings HTML includes localStorage.getItem('palette-theme') fallback after ?theme= param; no ?theme= override regression. Issue closed.
QA passed: dev CI image (7fde147, run #116) success; deployed to palette-dev; served /settings HTML includes localStorage.getItem('palette-theme') fallback after ?theme= param; no ?theme= override regression. Issue closed.
fen
added spent time 10 seconds2026-09-10 00:25:22 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Build the settings page (/settings, currently a placeholder from #36) out with a theme/theme section:
This is the same mechanism the end product will use, so stage future presets by just adding their [data-preset] CSS block; they automatically appear in the switcher (read the preset list from a JS constant or scan the stylesheet).
Future/related: server-side preference storage per viewer cookie lands with #30 - the localStorage approach is the client-side half and stays as an override.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
Reopening: closed but the theme switcher changes to settings.html are uncommitted in the working tree and not in the deployed binary. Not live on dev server.
QA review (
69da340, dev server): fails check 2 — theme is not actually persisted./settingsrenders.theme-gridwith 5 cards: Midnight, Smooth, Pastel Lavender, Pastel Peach, Pastel Cloud (verified in headless Chrome against palette-dev).documentElement.dataset.presetand writeslocalStorage['palette-theme'], but nothing ever reads that key back — on reloaddataset.presetis null and the page reverts to Midnight (verified live: after clicking Pastel Peach and reloading,dataset.preset=null, localStorage stillpastel-peach, active card is Midnight). Need a restore in the layout/head script: readpalette-themeand apply it on load.go vet ./...andgo test ./...all pass.Leaving open — one-line fix needed to read the saved theme on page load.
QA passed: dev CI image (
7fde147, run #116) success; deployed to palette-dev; served /settings HTML includes localStorage.getItem('palette-theme') fallback after ?theme= param; no ?theme= override regression. Issue closed.