, a child that doesn't cover the whole document). Turns out that's NOT always invisible on desktop the way it first looked:

has its own md:mt-2 top margin (see the layouts) so its rounded card floats slightly below the viewport's top edge — the strip that exposes is /'s own bare background, which visibly didn't match the sidebar sitting right next to it at that same top edge, a distinct seam confirmed live. On iOS Safari, viewport-fit=cover (see the in every layout/standalone page) additionally extends the document under the notch/status-bar safe area, and that strip — along with the elastic overscroll/rubber-band region at the top of the page — falls back to this same root background too. var(--sidebar), not var(--background): on desktop that's what visually continues into this gap (the sidebar sitting directly to its left at the same height) rather than main's own content color; on mobile --sidebar is already pinned to equal --background (see the md-scoped override further down), so this resolves to the exact same value the iOS fix originally used there — nothing about that behavior changes. A plain, static rule (not JS on document.body, which doesn't exist yet while the pre-paint script that sets the "dark" class runs) is enough: both custom properties already resolve correctly the moment this stylesheet applies, since that script has already run by then. */ html { background-color: var(--sidebar); } /* viewport-fit=cover (every layout/standalone page's own ) lets the document paint under the iOS notch/ status-bar and home-indicator safe areas — which is what the html{background-color} rule above needs to actually reach that area — but without this, real content (the sidebar's own header row, the main header's site name/hamburger/checkout button) would extend under the notch too and sit partly behind it. Padding the actual layout root by the safe-area inset keeps the background full-bleed while pulling visible content back into the safe area, the standard pairing for viewport-fit=cover. env() resolves to 0 on any browser/device without a notch or home indicator, so this is a no-op everywhere else. */ body { padding-top: env(safe-area-inset-top); padding-bottom: env(safe-area-inset-bottom); } .dark { --background: oklch(0.147 0.004 49.3); --foreground: oklch(0.986 0.002 67.8); --card: oklch(0.214 0.009 43.1); --card-foreground: oklch(0.986 0.002 67.8); --popover: oklch(0.214 0.009 43.1); --popover-foreground: oklch(0.986 0.002 67.8); --primary: oklch(0.473 0.137 46.201); --primary-foreground: oklch(0.987 0.022 95.277); --secondary: oklch(0.274 0.006 286.033); --secondary-foreground: oklch(0.985 0 0); --muted: oklch(0.268 0.011 36.5); --muted-foreground: oklch(0.714 0.014 41.2); --accent: oklch(0.268 0.011 36.5); --accent-foreground: oklch(0.986 0.002 67.8); --destructive: oklch(0.704 0.191 22.216); --border: oklch(1 0 0 / 10%); --input: oklch(1 0 0 / 15%); --ring: oklch(0.547 0.021 43.1); --chart-1: oklch(0.868 0.007 39.5); --chart-2: oklch(0.547 0.021 43.1); --chart-3: oklch(0.438 0.017 39.3); --chart-4: oklch(0.367 0.016 35.7); --chart-5: oklch(0.268 0.011 36.5); --sidebar: oklch(0.214 0.009 43.1); --sidebar-foreground: oklch(0.986 0.002 67.8); --sidebar-primary: oklch(0.769 0.188 70.08); --sidebar-primary-foreground: oklch(0.279 0.077 45.635); --sidebar-accent: oklch(0.268 0.011 36.5); --sidebar-accent-foreground: oklch(0.986 0.002 67.8); --sidebar-border: oklch(1 0 0 / 10%); --sidebar-ring: oklch(0.547 0.021 43.1); --success: oklch(68% .15 150); --warning: oklch(72% .16 70); } /* Below md (768px, matching every other md: breakpoint this app already uses to distinguish the sidebar's off-canvas mobile behavior from its permanent desktop one), --sidebar is pinned to var(--background) instead of its own distinct value above — confirmed live on iOS Safari via an A/B test that removed the sidebar entirely: with it gone, the browser's own chrome (status bar and address bar) matched the page correctly; with it back, the mismatch returned. The sidebar sits off-canvas via translate on mobile, not display:none, so it's still there for whatever heuristic Safari uses — giving it the same background as the page it's never visually distinguishable from on mobile anyway (an overlay drawer, not a permanent panel) removes the mismatch regardless of the exact mechanism, without touching the desktop sidebar's own deliberately-different look. Overriding :root alone (not :root and .dark separately) is enough: var(--background) itself already resolves to whichever theme is active. */ @media (max-width: 767px) { :root { --sidebar: var(--background); } } /* corner-shape only takes effect on an element that already has a border-radius — it changes the curve rounded corners are drawn with (circular arc vs. a squircle/superellipse), it doesn't add rounding of its own — so applying it to every element is inert everywhere there's no radius and reaches every rounded corner in the app (buttons, cards, inputs, badges, the sidebar's own outline above, ...) without having to chase down each of Basecoat's own radius-setting selectors individually. Still very new (Chromium 139+ at the time this was added); browsers without support just keep their normal circular-arc corners. */ * { corner-shape: squircle; } .badge[data-variant="success"] { background-color: color-mix(in oklab, var(--success) 10%, transparent); color: var(--success); } .badge[data-variant="success"]:hover { background-color: color-mix(in oklab, var(--success) 20%, transparent); } .badge[data-variant="warning"] { background-color: color-mix(in oklab, var(--warning) 10%, transparent); color: var(--warning); } .badge[data-variant="warning"]:hover { background-color: color-mix(in oklab, var(--warning) 20%, transparent); } /* The product-detail page's colour swatches (data-colour-swatch, see selectColour in app.js) toggle aria-pressed on click with no visual change otherwise — a plain outline badge reads identically whichever one is "on". Same primary near-black/near-white fill the sidebar's own active-nav-item state uses, since this is the same "you are here" role applied to a badge instead of a nav link. */ .badge[data-colour-swatch][aria-pressed="true"] { background-color: var(--primary); color: var(--primary-foreground); border-color: var(--primary); } /* Basecoat's own `@layer base` sets `* { border-color: var(--color-border); outline-color: var(--color-ring) }` so that any element which only sets a border *width* (e.g. Tailwind's bare `border-t`/`border-l` utilities, which this app uses directly in the layout templates, and which don't carry a color of their own) still gets the app's neutral hairline gray instead of a stray color. `@tailwindcss/browser`'s own Preflight reset also touches `*` in `@layer base` with a bare `border: 0px solid` shorthand — and a shorthand implicitly resets every longhand it doesn't mention, so it resets border-color too, to its initial value (`currentcolor`). Both stylesheets' `base` layers merge into one, and which of the two same-specificity `*` rules wins the tie for border-color/outline-color depends on load-order timing between a render-blocking `