Summary
Every -dark.html file under public/examples/** relies entirely on being embedded in ComponentPreview.astro's iframe, which applies bg-gray-900 to the <iframe> element itself (src/components/ComponentPreview.astro). None of the dark example files set an explicit dark background on their own <body> or <html>. Because the loaded document's body/html background computes to transparent by default, the iframe's bg-gray-900 shows through correctly when embedded on the live site — but if a -dark.html file is opened standalone (e.g. navigating directly to /examples/{category}/{slug}/{n}-dark.html, or opening the file outside the site entirely), there is nothing providing a dark backdrop. The page renders on a plain white background while every element still carries its dark: text/border/fill classes (light grays intended for a dark backdrop), producing washed-out, low-contrast, hard-to-read content.
Why this matters
This is easy to hit while reviewing or spot-checking dark-mode output — directly opening a -dark.html URL is a natural way to inspect one component in isolation, and it's how I first investigated a couple of house-style rollout issues before realizing the real site embeds these files in a pre-colored iframe. On the standalone page, hover-state color transitions (e.g. dark:hover:text-gray-50) are technically firing correctly but are nearly imperceptible against the white page, which can look like a broken hover effect even though it isn't.
Scope
Confirmed via public/examples/application/accordions/1-dark.html (untouched, pre-existing file) and multiple files touched by the ongoing house-style rollout (#752) — this is a site-wide gap that predates that effort, not something introduced by it.
Suggested fix
Something like a single global rule (e.g. in src/styles/component.css) so any document with <html class="dark"> gets a sane background regardless of embedding context, for example:
html.dark {
background-color: var(--color-gray-900, #111827);
}or add an explicit dark:bg-gray-900 (or similar) to <body> across all -dark.html files. The former is a one-line fix that covers every existing and future dark example without touching 225+ individual files.
Reproduction
- Start the dev server (
pnpm dev)
- Open
http://localhost:4321/examples/application/accordions/1-dark.html directly (not via the /components/... page)
- Observe: white page background, pale/low-contrast text and borders, rather than the dark backdrop shown when the same file is viewed embedded on
/components/application/accordions
Summary
Every
-dark.htmlfile underpublic/examples/**relies entirely on being embedded inComponentPreview.astro's iframe, which appliesbg-gray-900to the<iframe>element itself (src/components/ComponentPreview.astro). None of the dark example files set an explicit dark background on their own<body>or<html>. Because the loaded document'sbody/htmlbackground computes to transparent by default, the iframe'sbg-gray-900shows through correctly when embedded on the live site — but if a-dark.htmlfile is opened standalone (e.g. navigating directly to/examples/{category}/{slug}/{n}-dark.html, or opening the file outside the site entirely), there is nothing providing a dark backdrop. The page renders on a plain white background while every element still carries itsdark:text/border/fill classes (light grays intended for a dark backdrop), producing washed-out, low-contrast, hard-to-read content.Why this matters
This is easy to hit while reviewing or spot-checking dark-mode output — directly opening a
-dark.htmlURL is a natural way to inspect one component in isolation, and it's how I first investigated a couple of house-style rollout issues before realizing the real site embeds these files in a pre-colored iframe. On the standalone page, hover-state color transitions (e.g.dark:hover:text-gray-50) are technically firing correctly but are nearly imperceptible against the white page, which can look like a broken hover effect even though it isn't.Scope
Confirmed via
public/examples/application/accordions/1-dark.html(untouched, pre-existing file) and multiple files touched by the ongoing house-style rollout (#752) — this is a site-wide gap that predates that effort, not something introduced by it.Suggested fix
Something like a single global rule (e.g. in
src/styles/component.css) so any document with<html class="dark">gets a sane background regardless of embedding context, for example:or add an explicit
dark:bg-gray-900(or similar) to<body>across all-dark.htmlfiles. The former is a one-line fix that covers every existing and future dark example without touching 225+ individual files.Reproduction
pnpm dev)http://localhost:4321/examples/application/accordions/1-dark.htmldirectly (not via the/components/...page)/components/application/accordions