Paul Nothaft
1a530aeaa2
Two further fixes for the gallery loading sequence shown in @Rekoo-PS's frame breakdown on issue #358 — both about colours that didn't track the active theme. 1. Initial white frame (frame f1) The pre-React bootstrap script in #359 sets the cached background on documentElement, but the browser may paint the very first frame *before* that <script> tag runs (synchronous parse-time JS in the <head> is still slightly later than CSS apply-time). On first-visit dark-OS devices that meant a single white frame before the script resolved. Fix: move the OS-preference default into a <style> block that precedes the script. CSS @media (prefers-color-scheme) is applied before paint, so dark-OS devices land on dark from frame zero. The script keeps the per-gallery cache hit on top, and now also stamps the colour onto document.body in case the body element has already mounted by the time the script runs. 2. "Most annoying" skeleton tile frame (frame f4) Skeleton placeholders rendered as bright `bg-neutral-200` light grey regardless of theme. On a dark gallery that's the highest-contrast thing on screen during loading — the exact frame Rekoo-PS labelled "the most annoying" in the issue. Fix: the Skeleton component's background now reads `var(--color-surface-border)`, which ThemeContext already wires up per active theme (`#e5e5e5` light / `#2e2e2e` dark by default; per- event themes can override). The bare `<div>` no longer carries any colour utility class — the inline style supplies the active value. Also dropped the leftover `bg-white` on SkeletonCard / SkeletonTable in favour of `var(--color-surface)` for the same reason. Tests: New src/components/common/__tests__/Skeleton.test.tsx covers - Skeleton uses var(--color-surface-border, ...) - bg-neutral-200 is no longer present - SkeletonGalleryGrid tiles all inherit the theme colour - SkeletonCard surface uses var(--color-surface)
58 lines
2.2 KiB
HTML
58 lines
2.2 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
|
|
<title>PicPeak - Photo Sharing Platform</title>
|
|
|
|
<!-- Pre-React theme bootstrap (#358).
|
|
The browser may paint the very first frame before our inline
|
|
<script> below runs, so we set OS-preference defaults via CSS
|
|
here in <head> — that gets applied before any paint. The
|
|
script then layers a per-gallery cache hit on top when one is
|
|
available. Without this CSS, the very first frame on first-
|
|
visit dark-OS devices flashed white briefly (see Rekoo-PS's
|
|
frame f1 in the issue). -->
|
|
<style>
|
|
html, body { background-color: #fafafa; }
|
|
@media (prefers-color-scheme: dark) {
|
|
html, body { background-color: #171717; }
|
|
}
|
|
/* Smooth out the cache → API theme transition for the rare case
|
|
where the cached colour drifts from the freshly fetched theme. */
|
|
html { transition: background-color 200ms ease; }
|
|
</style>
|
|
|
|
<script>
|
|
/*
|
|
* Pre-React theme bootstrap (#358).
|
|
*
|
|
* The CSS @media block above handles the OS-preference default
|
|
* before paint. This script then applies a per-gallery cached
|
|
* background (written by ThemeContext on the previous visit) so
|
|
* revisits land on the exact theme background from frame one.
|
|
*/
|
|
(function () {
|
|
try {
|
|
var m = location.pathname.match(/\/gallery\/([^\/?#]+)/);
|
|
var bg = null;
|
|
if (m && m[1]) {
|
|
bg = localStorage.getItem('gallery-theme-bg-' + decodeURIComponent(m[1]));
|
|
}
|
|
if (bg) {
|
|
var root = document.documentElement;
|
|
root.style.backgroundColor = bg;
|
|
document.body && (document.body.style.backgroundColor = bg);
|
|
root.style.setProperty('--color-background', bg);
|
|
}
|
|
} catch (e) { /* never block render on a cache miss */ }
|
|
})();
|
|
</script>
|
|
</head>
|
|
<body>
|
|
<div id="root"></div>
|
|
<script type="module" src="/src/main.tsx"></script>
|
|
</body>
|
|
</html>
|