On a first load of either deck — cold cache, fresh origin — reveal classifies every slide's background before the theme CSS has applied, reads them all as transparent, and marks the whole deck has-dark-background. Quarto then styles its chrome for a dark slide on a white one.
Measured on #/sec-07-inverses-and-pseudoinverse, cold:
slideClasses: title-slide slide level1 center has-dark-background
h1Color: rgb(255, 255, 255) ← white heading on a white slide
footerClass: footer footer-default has-dark-background
footerLinkColor: rgb(123, 198, 250) ← the dark-background link colour
Warm load, same slide: no has-dark-background, h1 is rgb(47,72,88), links rgb(44,95,138). Correct.
This is the failure CLAUDE.md already describes under the $backgroundColor note — $backgroundColor: #ffffff is set and --r-background-color: #ffffff is present in the compiled theme, so the value is right; it is the timing that loses. Being in OS dark mode makes it far more visible.
What it affects
The timer is already immune: updateContrast() in slides/deck-pace.html measures the painted background colour and takes Rec. 601 luma rather than trusting the class, precisely because of this.
Why it was left
The breadcrumb inherits so it stays consistent with the links beside it. Making it self-correct would leave it navy next to light-blue links — readable but mismatched, versus consistently broken. That is a design call, not an obvious fix, which is why this is an issue rather than a patch.
Possible directions
- Apply the same luma measurement to the crumb and accept the mismatch on cold loads.
- Re-run quarto's own background classification after the stylesheet loads (a
load listener calling reveal's sync()), which would fix headings, links and crumb together — the broadest fix, and the one that also repairs Quarto's own chrome.
- Nothing: it is correct on every warm load, and a facilitator hard-reloading mid-workshop is the only realistic way to hit it.
Found while verifying #37.
On a first load of either deck — cold cache, fresh origin — reveal classifies every slide's background before the theme CSS has applied, reads them all as transparent, and marks the whole deck
has-dark-background. Quarto then styles its chrome for a dark slide on a white one.Measured on
#/sec-07-inverses-and-pseudoinverse, cold:Warm load, same slide: no
has-dark-background,h1isrgb(47,72,88), linksrgb(44,95,138). Correct.This is the failure
CLAUDE.mdalready describes under the$backgroundColornote —$backgroundColor: #ffffffis set and--r-background-color: #ffffffis present in the compiled theme, so the value is right; it is the timing that loses. Being in OS dark mode makes it far more visible.What it affects
.deck-crumb, Give the room a visible clock and say which section it is in #37) inherits the footer's colour deliberately, so it disappears with them.The timer is already immune:
updateContrast()inslides/deck-pace.htmlmeasures the painted background colour and takes Rec. 601 luma rather than trusting the class, precisely because of this.Why it was left
The breadcrumb inherits so it stays consistent with the links beside it. Making it self-correct would leave it navy next to light-blue links — readable but mismatched, versus consistently broken. That is a design call, not an obvious fix, which is why this is an issue rather than a patch.
Possible directions
loadlistener calling reveal'ssync()), which would fix headings, links and crumb together — the broadest fix, and the one that also repairs Quarto's own chrome.Found while verifying #37.