Parent
#922
Found while doing #978, which surfaced it rather than fixing it. Not a regression: this is how the code behaves on main today.
services/frontend/src/styles/island.css pins the dark treatment inside a swipeable band, so that a photograph is never filtered by a wash that follows the viewer's theme. It sets color and the --color-ground/-pit/-surface/-raised/-hairline/-chalk/-ash family on the band.
The values are byte-for-byte the dark defaults, so in the dark theme the rule is a no-op. It only bites in the light half.
The problem. A custom property built out of another is substituted where it is declared, not where it is read. Two properties derived from that family are declared above the band:
--band-ground on .island (island.css:206), out of --color-pit--accent-ink on .board-page (pages/Board.vue), out of --color-chalk
So inside the pinned band the ink flips to chalk while the grounds those properties paint stay the light theme's pale. White text on a pale wash.
This is live on the esports pages now. Their slice band sits inside the pinned swipe and reads --band-ground, so the same mismatch applies wherever a light-theme viewer opens a slice there.
Evidence. #978 captured it by pointing the selector at the shared class, which extended the pinning to the board band and made the failure obvious: the eyebrow, the board name and the description all went near-invisible on the pale wash, while the cheer kept its colour because --accent-ink is computed outside the band. Shots are in that ticket's report.
Why it is not fixed there. #978's scope was decided as naming only, and #973 is a mechanical rename epic. Making the grounds follow the ink is a styling change with a visual review attached, and it belongs in its own PR.
The fix, when someone takes it. Move the derived declarations inside the pinned block, or redeclare them there, so a ground computed from --color-pit and an ink computed from --color-chalk are both evaluated against the pinned values. Confirm first whether anything else in the island layer derives from that family above the band. Then look at an open slice on the esports pages in the light theme, which is where the bug is reachable today.
Parent
#922
Found while doing #978, which surfaced it rather than fixing it. Not a regression: this is how the code behaves on
maintoday.services/frontend/src/styles/island.csspins the dark treatment inside a swipeable band, so that a photograph is never filtered by a wash that follows the viewer's theme. It setscolorand the--color-ground/-pit/-surface/-raised/-hairline/-chalk/-ashfamily on the band.The values are byte-for-byte the dark defaults, so in the dark theme the rule is a no-op. It only bites in the light half.
The problem. A custom property built out of another is substituted where it is declared, not where it is read. Two properties derived from that family are declared above the band:
--band-groundon.island(island.css:206), out of--color-pit--accent-inkon.board-page(pages/Board.vue), out of--color-chalkSo inside the pinned band the ink flips to chalk while the grounds those properties paint stay the light theme's pale. White text on a pale wash.
This is live on the esports pages now. Their slice band sits inside the pinned swipe and reads
--band-ground, so the same mismatch applies wherever a light-theme viewer opens a slice there.Evidence. #978 captured it by pointing the selector at the shared class, which extended the pinning to the board band and made the failure obvious: the eyebrow, the board name and the description all went near-invisible on the pale wash, while the cheer kept its colour because
--accent-inkis computed outside the band. Shots are in that ticket's report.Why it is not fixed there. #978's scope was decided as naming only, and #973 is a mechanical rename epic. Making the grounds follow the ink is a styling change with a visual review attached, and it belongs in its own PR.
The fix, when someone takes it. Move the derived declarations inside the pinned block, or redeclare them there, so a ground computed from
--color-pitand an ink computed from--color-chalkare both evaluated against the pinned values. Confirm first whether anything else in the island layer derives from that family above the band. Then look at an open slice on the esports pages in the light theme, which is where the bug is reachable today.