/* ═══════════════════════════════════════════════════════════ studio-pretty-websites — Google AI Studio design language dark #121317 · surfaces #1a1b1f/#212226 · accent blue #2E96FF Google Sans Flex (display) · Inter (body) · Google Sans Code (mono) ═══════════════════════════════════════════════════════════ */ :root { /* SPACING LADDER — 4pt, with 2px as the single sub-step. See tools/spacing-scale.mjs. 556 literal values across 34 sizes became these thirteen. */ --s-05: 2px; --s-1: 4px; --s-2: 8px; --s-3: 12px; --s-4: 16px; --s-5: 20px; --s-6: 24px; --s-8: 32px; --s-10: 40px; --s-12: 48px; --s-16: 64px; --s-20: 80px; --s-24: 96px; /* SPACING LADDER — 4pt, with 2px as the single sub-step. See tools/spacing-scale.mjs. 556 literal values across 34 sizes became these thirteen. */ --s-05: 2px; --s-1: 4px; --s-2: 8px; --s-3: 12px; --s-4: 16px; --s-5: 20px; --s-6: 24px; --s-8: 32px; --s-10: 40px; --s-12: 48px; --s-16: 64px; --s-20: 80px; --s-24: 96px; /* Radius ladder — see tools/radius-scale.mjs. Three rungs and a pill; 50% stays 50%. */ --r-s: 8px; --r-m: 12px; --r-l: 16px; --r-pill: 999px; /* TYPE SCALE. Before this there were 42 distinct font sizes, 43 of them half-pixel values that accumulated rather than being chosen, and the eyebrow role was implemented ~20 times at seven different sizes. Five rungs cover every role on the site; the two clamp() ramps for h1 and h2 were already deliberate and are untouched. */ --t-eyebrow: 11px; /* mono, uppercase, tracked — labels, counts, kickers */ --t-micro: 12px; /* captions, meta */ --t-body-s: 13px; /* dense prose, table cells, card copy */ --t-body: 15px; /* reading prose */ --t-h3: 17px; /* --t-h2 was used by three rules in the teardown modal and defined nowhere, so each of those declarations was invalid and dropped in silence: the section headings fell back to inherited body size and the hierarchy they were written to create did not exist. An undefined custom property does not warn, does not fail a build, and does not show up as anything but a heading that looks slightly wrong. */ --t-h2: 21px; /* card and panel titles */ /* Filled buttons need a darker blue: #fff on --blue is 3.03:1 and on --blue-bright 2.15:1, so the primary action on the gate — the first screen of the site — failed hardest. --blue stays as it is for borders and the active-tab underline, where 3:1 is the bar. */ --blue-fill: #0b62c4; /* Status colours. The set had --blue/--green/--amber and no red, no purple, and none of the soft tints the pills use, so every status colour on the site was written as a literal and the same green appeared as three slightly different hexes. Named here once. */ --red: #f0a0a0; --red-deep: #6a3a3a; --purple: #c58af9; --green-soft: rgba(91, 209, 139, .13); --amber-soft: rgba(249, 171, 0, .13); --red-soft: rgba(220, 80, 80, .13); --scrim: rgba(8, 9, 10, .82); --bg: #121317; --bg-deep: #0e0f12; --surface: #1a1b1f; --surface-2: #212226; --surface-3: #26272c; --border: rgba(255,255,255,0.09); --border-strong: rgba(255,255,255,0.15); --text: #e8eaed; --white: #ffffff; --text-2: #9aa0a6; --text-3: #8a9096; /* was #6b7076 — 3.44:1 on --surface, failing AA at every one of ~20 call sites, all of them <=12px normal text. 4.54:1 on --surface-3 now. */ --blue: #2e96ff; --blue-bright: #6bb6ff; --blue-soft: rgba(46,150,255,0.14); --blue-border: rgba(46,150,255,0.42); /* THE CHIP SURFACE, ONE DEFINITION. A chip on a diagram and a chip in a card are the same object in this site's grammar — a raised tile carrying one action or one name — and the value was written literally rather than tokenised. On the Graph tab `.vc-sec,.vc-node` carried `rgba(255,255,255,.055)` with NO light-theme counterpart, so the affordance its own comment describes ("reader chips get a raised surface") painted white-on-white and did not exist on the light theme. Same value, same meaning, one token that flips with the theme. /method declares the identical pair inline in build-method.mjs as `--mth-chip`. That file is not ours to edit today; when it is next touched, point it here and delete the local copy. */ --dgm-chip: rgba(255,255,255,0.055); --dgm-chip-hi: rgba(255,255,255,0.09); /* ── THE OPEN-HERE MARK ────────────────────────────────────────────────────────────────────── A raised chip surface (`--dgm-chip` above) says "this tile is an object". It does NOT say "this one opens something and the fourteen beside it do not", and on the Graph tab that was the whole defect: a law chip and a corpus-query chip both measured 11px / 400 / #9aa0a6 / 23.6px tall, differing only by a 5.5%-alpha wash that is invisible at any size. LA: "it is not clear when we can click to see laws. That pill should have special color." So the strongest affordance this site has — a FILLED accent, the same one `button.chip.on` and `.card-chips .chip-full` already use for "this control is the live one" — is reserved for a control that opens a reader in place. Named for the behaviour rather than for the tab, because the mark has to mean the same thing wherever it is drawn. ONE VALUE IN BOTH THEMES, and that is deliberate rather than lazy: --blue-fill is #0b62c4 on dark and on light, so #fff measures 5.98:1 on it either way (--blue-fill exists precisely because #fff on --blue is 3.03:1). A theme-conditional fill would need two contrast proofs and would drift; this needs one. --act-open-hi is the hover, checked the same way: #fff on #1272d8 is 4.79:1, still AA at the 12px this chip is set in. */ --act-open: var(--blue-fill); --act-open-hi: #1272d8; --act-open-ink: #ffffff; --amber: #f9ab00; --surface-elev: #1c1d22; --shadow-elev: 0 48px 110px -32px rgba(0,0,0,0.85), 0 12px 32px -14px rgba(0,0,0,0.6); --shadow-modal: 0 60px 140px -40px rgba(0,0,0,0.9), 0 16px 40px -18px rgba(0,0,0,0.65); --green: #5bd18b; --disp: "Google Sans Flex", "Google Sans", -apple-system, sans-serif; --sans: "Inter", -apple-system, "Helvetica Neue", sans-serif; --mono: "Google Sans Code", "Roboto Mono", Menlo, monospace; } /* ── LIGHT THEME ─────────────────────────────────────────────────────────────────────────────── LA: "add a theme button to manually change in case." Dark stays the default and the shipped identity; this is a manual alternative, set by `data-theme="light"` on and remembered. Only the TOKENS are redefined — not one rule below this block knows which theme is active, which is the whole reason the token layer exists. Three things are not simple inversions, and getting them wrong is what makes a bolted-on light theme look bolted on: 1. `--white` is not "white", it is STRONGEST INK. On dark that is #fff; on light it has to be near-black, or every heading on the site vanishes. Same for --bg-deep, which is "further back" and therefore DARKER on dark and LIGHTER on light only in the sense of receding. 2. The blues had to change value, not just role. #2e96ff on white is 2.6:1 — it fails as text everywhere it is currently used as text. Light gets a darker blue for ink and keeps a bright one only for fills. 3. The surface ORDER inverts. On dark, surfaces get lighter as they come forward; on light they get whiter as they come forward and the page ground is the grey. Keeping the dark ordering would put a dark panel on a white page. */ :root[data-theme="light"] { --bg: #f5f5f7; --bg-deep: #ececef; --surface: #ffffff; --surface-2: #fafafa; --surface-3: #f0f0f2; --surface-elev: #ffffff; --border: rgba(0,0,0,0.11); --border-strong: rgba(0,0,0,0.19); --text: #1d1d1f; --white: #0b0b0d; /* strongest ink — see note 1 */ --text-2: #55595f; /* 7.1:1 on --surface */ --text-3: #63686e; /* 5.4:1 on --surface. #6b7076 measured 4.24:1 at one 11px call site on --surface-3, which is the ground that matters. */ /* The light counterpart the chip surface never had: ink-tinted, not white-tinted. */ --dgm-chip: rgba(0,0,0,0.045); --dgm-chip-hi: rgba(0,0,0,0.075); --blue: #0b62c4; /* 5.9:1 on white — usable as text, unlike #2e96ff at 2.6:1 */ --blue-bright: #0a4fa0; /* links and hovers go DARKER on light, not brighter */ --blue-fill: #0b62c4; --blue-soft: rgba(11,98,196,0.09); --blue-border: rgba(11,98,196,0.30); --green: #17794c; --amber: #8a5a00; --red: #b3261e; --red-deep: #f3d6d4; --purple: #6d3bbf; --green-soft: rgba(23,121,76,.10); --amber-soft: rgba(138,90,0,.10); --red-soft: rgba(179,38,30,.09); --scrim: rgba(28,28,32,.55); --shadow-elev: 0 24px 60px -24px rgba(0,0,0,0.20), 0 6px 18px -10px rgba(0,0,0,0.12); --shadow-modal: 0 40px 100px -32px rgba(0,0,0,0.28), 0 10px 28px -14px rgba(0,0,0,0.16); } /* The semantic layer is derived, so it has to be re-derived — otherwise a light page keeps the dark theme's signal colours and "one colour, one meaning" quietly breaks at the theme boundary. */ :root[data-theme="light"] { --sig-good: var(--green); --sig-good-soft: var(--green-soft); --sig-warn: var(--amber); --sig-warn-soft: var(--amber-soft); --sig-bad: var(--red); --sig-bad-soft: var(--red-soft); --sig-info: var(--blue); --sig-note: var(--text-2); } /* Media wells are painted near-black across the site so a photograph never lands on a bright rectangle while it loads. On a light page that reads as a hole, so the well follows the theme. */ :root[data-theme="light"] .card-media, :root[data-theme="light"] .plate-card img, :root[data-theme="light"] .side img { background: var(--surface-3); } /* The toggle itself. Same pill as the rest of the chrome, in the topbar. */ /* THE THEME SWITCH IS AN ICON BESIDE THE MARK, NOT A PILL IN THE CORNER. It was `☾ DARK` in an outlined lozenge with `margin-left: auto`, which parked it at the far right of the bar — the loudest object on every page of the site, naming a state nobody had asked about, as far from the identity as the bar allows. It read as a section rather than a control. A theme preference belongs against the mark it re-colours. NO BORDER AND NO GROUND until you point at it: an always-outlined 36px lozenge next to a wordmark competes with it. The affordance arrives on hover and focus, which is where it is needed, and the glyph alone carries it the rest of the time. */ .theme-btn { display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 32px; padding: 0; margin: 0; border: 1px solid transparent; border-radius: var(--r-pill); background: transparent; color: var(--text-3); font-size: 15px; line-height: 1; cursor: pointer; } .theme-btn:hover { color: var(--text); border-color: var(--border); background: var(--surface-elev); } .theme-btn:focus-visible { color: var(--text); border-color: var(--text-3); background: var(--surface-elev); } /* 32px clears the 24px WCAG 2.5.8 minimum with room, but a thumb wants 44 — and the icon must not grow to get it, or it stops being a quiet mark beside the wordmark. The box expands, not the glyph. */ @media (pointer: coarse) { .theme-btn { position: relative; } .theme-btn::after { content: ""; position: absolute; inset: -6px; border-radius: inherit; } } /* The button is injected by theme.js as the last child, so `order` is what puts it beside the wordmark rather than a DOM move — one declaration, and no script has to know about layout. */ /* `.topbar-in` is `justify-content: space-between`, which is what actually pinned the switch to the far corner — removing its `margin-left: auto` changed nothing, and the button stayed 906px from the mark. Ordering it second and giving it `margin-right: auto` makes the pair hug the left together, while any third child a tab injects still goes to the right where it belongs. */ .topbar-in .wordmark { order: 1; } .topbar-in .theme-btn { order: 2; margin-right: auto; } /* ON A PHONE THE ICON GOES IN FRONT OF THE MARK, NOT AFTER IT. The home tab's wordmark is not the same width as everyone else's — app.js appends a "what's new" pill into it, taking it to 338px. At 390 the bar has 350px of room, so mark + gap + icon is 382 and the icon wrapped onto a second line, sitting alone under the mark at y:50 while every other tab kept it beside. LA's own first framing was "an icon on the left of / or after" the wordmark; after is right when there is room and left is right when there is not, because a 32px icon leading the line always fits and the mark can then take whatever remains. */ /* THE ICON WRAPPED BECAUSE THE LINE IS 32px TOO SHORT, so the fix is the 32px, not the order. Measured at 390: the bar has 350px between its paddings, and the home tab's wordmark — which carries a "what's new" pill the other tabs do not — is 338. Add the 12px gap and the 32px icon and it is 382. Reordering the icon in front only moved the wrap from below the mark to above it; the arithmetic was unchanged. Dropping the mark to 11px takes it to ~296 and the row closes at ~336. 11.5px was not enough: it landed on 350 against exactly 350 of room, and equal is still a wrap. The pill shrinks with it because it inherits, and at this size the mark is still the second-largest thing in a bar whose job is not to shout its own name. SCOPED TO `.topbar-in .wordmark`, NOT `.wordmark`, and that is not cosmetic: this block sits above `.wordmark { font-size: 13px }`, so a bare-class rule loses on document order and the mark stayed 338px wide with the icon still wrapped. Two selectors beat one wherever it sits. This file already records the colour and the text-decoration versions of the same trap. And the version of this note that fixed the specificity SHIPPED BROKEN for one measurement round, because I opened it after the previous comment had already closed: the prose became raw CSS, the parser discarded tokens until it could recover, and it took the media query with it. The measurement said 13px and I nearly went looking for a cascade problem that did not exist. Every rule in this file is a rule somebody could not see. */ @media (max-width: 430px) { .topbar-in .wordmark { font-size: 11px; } .topbar-in { gap: var(--s-1, 8px); } } * { margin: 0; padding: 0; box-sizing: border-box; } [hidden] { display: none !important; } html { scroll-behavior: smooth; } body { font-family: var(--sans); background: var(--bg); color: var(--text); font-size: 15px; line-height: 1.6; -webkit-font-smoothing: antialiased; letter-spacing: -0.006em; } img { display: block; max-width: 100%; } button, input, select { font: inherit; color: inherit; } button { font-family: inherit; cursor: pointer; } /* ── Gate ─────────────────────────────────────────────── */ .gate { position: fixed; inset: 0; z-index: 100; display: flex; align-items: center; justify-content: center; background: radial-gradient(1100px 560px at 72% -10%, var(--blue-soft), transparent 62%), radial-gradient(820px 480px at 8% 112%, rgba(46,150,255,0.06), transparent 60%), var(--bg); padding: var(--s-6); } .gate-card { width: 100%; max-width: 400px; text-align: center; } .gate-mark { font-family: var(--mono); font-size: 14px; letter-spacing: 0.32em; color: var(--text-2); text-transform: uppercase; margin-bottom: var(--s-5); } .gate-mark span { color: var(--blue); } .gate-title { font-family: var(--disp); font-size: 32px; font-weight: 500; letter-spacing: -0.02em; color: var(--white); } .gate-sub { color: var(--text-2); font-size: 14px; margin: var(--s-2) 0 var(--s-6); } .gate input { width: 100%; padding: var(--s-3) var(--s-4); border: 1px solid var(--border-strong); border-radius: var(--r-s); background: var(--surface); outline: none; text-align: center; font-family: var(--mono); font-size: 15px; } .gate input:focus { border-color: var(--blue-border); } .gate input::placeholder { color: var(--text-3); } .gate button { margin-top: var(--s-3); width: 100%; padding: var(--s-3); border: none; border-radius: var(--r-s); background: var(--blue); color: #fff; font-weight: 500; } .gate button:hover { background: var(--blue-bright); } /* ── THE PINNED CHROME — THE ONLY PLACE THAT DECIDES WHAT STICKS ─────────────────────────────── THIS BLOCK OWNS EVERY `position: sticky` IN THE PAGE CHROME. Nothing else in this stylesheet and nothing in site/tools/build-v5-shell.mjs may pin a band to the top of the viewport. If you are adding one, add it here, to the stack below, with its own `top` — do not write a second rule somewhere closer to the thing you are working on. WHY THE RULE HAD TO BECOME A BLOCK. `.topbar`, `.tabs` and `.bar` are siblings inside `#app`, and all three resolved to `position: sticky; top: 0; z-index: 40` — from FOUR rules in TWO files, each carrying a comment that claimed to be the only sticky element on the page: · `.bar` below, in the control-band block · `.tabs` below, in the v2-tabs block · `.tabs` again, inside `@media (max-width: 760px)` · `.topbar` in the CSS string appended by build-v5-shell.mjs Same top, same z-index, so the last of the three in DOM order — `nav.bar` — painted over the other two. Measured at scrollY 3000 on the corpus tab: `document.elementFromPoint()` over the centre of the ACTIVE tab returned `span.dl-file`, a child of the bar. The tab was not merely hidden, it was not clickable — and all three tab links, both wordmark links and the theme control stayed focusable while visually obscured, which is WCAG 2.2 SC 2.4.11 Focus Not Obscured, a Level AA failure. The corpus tab is 280,611px tall at 375, so the only route to another tab was to scroll the whole way back to the top: LA's original complaint, "can't go back once I am there", returned by the comment that claimed to have fixed it. Four rules, each locally correct, none of them able to see the other three. That is why there is now one. WHAT IS PINNED, AND WHAT IS NOT: · `.tabs` — PINNED at top: 0. It is the go-back affordance and the entire reason anything here is sticky. Being topmost, it is also what sits under the notch in landscape. · `.bar` — PINNED at top: var(--tabs-h), immediately under the strip. It carries the search, the filters, the segmented control and the download: the controls a reader operates WHILE scrolling, which is what earns a band its place on a screen. · `.topbar` — NOT PINNED. It scrolls away with the page, at every width. It holds the wordmark and the theme control — an identity and a preference, neither of them navigation, neither something a reader reaches for mid-page. Measured: 64px tall, so pinning it costs 64 + 51 = 115px at 1440 before a single control that acts on the page, and 64 + 48 + 117 = 229px of a 667px phone, a third of the screen, to keep a wordmark on it. The earlier comment for that rule argued the tab strip was "reachable by going back up"; on a 280,000px page it is not, which is the defect above, so the strip is the one that stays and the bar above it goes. THE OFFSETS ARE DISTINCT AND THE Z-INDICES ARE NOT EQUAL. Two bands at top: 0 sharing a z-index IS the defect; the stack is declared once, here, in numbers that cannot both be zero. `--tabs-h` IS THE STRIP'S MEASURED HEIGHT, NOT A GUESS: 46px at ≤360, 48px from 361 to 620, 51px from 621 up. Those two steps are exactly the widths at which the tab font-size drops — and THOSE RULES ARE NOT IN THIS FILE, they are in the CSS tail appended by site/tools/build-v5-shell.mjs, which is why the three numbers here are stated with their breakpoints rather than left implicit. It is applied to the strip as `min-height` as well as to the bar as `top`, so the number cannot quietly become larger than the thing it offsets — and check-v5-tabs.mjs asserts, at all 18 widths and on all three tabs, that `.bar`'s pinned top equals `.tabs`'s pinned bottom and that nothing else is pinned at all. If a future edit changes the strip's height and not this number, that check fails instead of the navigation. */ :root { --tabs-h: 51px; } @media (max-width: 620px) { :root { --tabs-h: 48px; } } @media (max-width: 360px) { :root { --tabs-h: 46px; } } .topbar { position: static; } .tabs { position: sticky; top: 0; z-index: 41; min-height: var(--tabs-h); } .bar { position: sticky; top: var(--tabs-h); z-index: 40; } /* THE PINNED SURFACES GO TRANSLUCENT AT ≥768px. LA, on an iPad, dark theme, templates tab mid-scroll: "is that on top normal? maybe the bar should be transparent too. This looks broken." A row of cards cut dead at an opaque band's bottom edge reads as a defect; the same row dimming through the band reads as chrome, and the blur is what says the veil is deliberate. THE ALPHA IS PER-THEME AND MEASURED, NOT TASTED. A translucent band's real ground is whatever scrolls beneath it, so AA is computed against the worst content each theme can carry under its chrome: pure white under the dark theme's, pure black under the light theme's. The weakest ink sitting directly on either band is --text-3 (pill keys, ≤12px, so the floor is 4.5:1): dark 92% → worst 4.87:1 (--text-3 on the bar, white beneath) light 98% → worst 4.57:1 (--text-3 on the strip, black beneath) Light gets almost no translucency because it CANNOT have more: a light veil over black content drowns its own grey ink, and blur is atmosphere, not a contrast substitute — 97.5% is the AA floor there, 98% is the margin. check-v5-tabs.mjs folds the same two backstops, so an alpha that breaks this arithmetic fails the gate rather than the reader. PHONES KEEP THE OPAQUE BASE SURFACES. The site-wide performance rule is backdrop-filter at 768px+ only; below that nothing here applies and the base .tabs/.bar rules elsewhere in this file already paint solid token grounds. The hairline border-bottom each band carries is untouched: translucent or not, the chrome still terminates on an edge. */ :root { --chrome-a: 92%; } :root[data-theme="light"] { --chrome-a: 98%; } /* THE SELECTORS ARE DOUBLED ON PURPOSE. This block sits near the top of the file and the bands' opaque surface rules sit far below it at the same specificity, so a plain `.tabs { background }` here loses the cascade to its own fallback and the chrome silently stays opaque — which is exactly how the first draft of this rule shipped nothing: the sabotage run (--chrome-a at 52%) still measured an opaque bar. `.tabs.tabs` outweighs any later single-class rule without touching the surface blocks, which keeps the whole translucency decision in this one place. */ @media (min-width: 768px) { .tabs.tabs { background: color-mix(in srgb, var(--bg-deep) var(--chrome-a), transparent); -webkit-backdrop-filter: blur(14px); backdrop-filter: blur(14px); } /* The bar's opaque ground sits one step above the strip's — color-mix(--bg-deep 80%, --bg), declared in THE CONTROL BAND below. The translucent version keeps that same step. */ .bar.bar { background: color-mix(in srgb, color-mix(in srgb, var(--bg-deep) 80%, var(--bg)) var(--chrome-a), transparent); -webkit-backdrop-filter: blur(14px); backdrop-filter: blur(14px); } } /* ── Topbar ───────────────────────────────────────────── */ /* RESERVE THE HEIGHT TWO SCRIPTS ARE ABOUT TO ADD. The bar paints at 50px, theme.js appends the theme control at ~840ms taking it to 65px, and app.js appends the "what's new" pill at ~2310ms taking it to 96px — so the entire viewport is shoved down 46px in two steps after first paint. Measured cost on the landing tab: CLS 0.458, where 0.1 is the threshold. Reserving the final height here, in the stylesheet rather than at runtime, means the space exists from parse time and the controls drop into it. Measured 0.458 -> 0.145 when injected late; declared it should reach near zero. If a control is ever added to this bar, this number moves with it. */ /* NO BORDER HERE. The topbar and the tab strip both used to pin at top:0 and both carried a 1px bottom border, so scrolling parked them one under the other and the page showed two hairlines a few pixels apart. LA: "there remain a double line when I scroll." The topbar does not pin any more (see THE PINNED CHROME above) so that pairing cannot recur, but the border stays off: the tab strip's is the one that separates chrome from content, and this bar is already distinguished by sitting above it. */ .topbar { background: var(--bg-deep); min-height: 96px; } .topbar-in { max-width: 1280px; margin: 0 auto; padding: 14px clamp(20px, 4vw, 48px); display: flex; align-items: center; justify-content: space-between; gap: var(--s-3); flex-wrap: wrap; } .wordmark { font-family: var(--mono); font-size: 13px; letter-spacing: 0.01em; white-space: nowrap; } .wm-a { color: var(--text-2); } .wm-sep { color: var(--text-3); margin: 0 var(--s-05); } .wm-b { color: var(--blue); } /* THE METHOD PILL WAS HERE, AND IT IS A TAB NOW. The rule that stood here styled a pill in the topbar, under a comment arguing that /method must not be a tab: check-v5-tabs held every TAB to the full control grammar — a download-first .ctl bar, a manifest placeholder, identical bar geometry — and /method hands over no dataset, so a tab faking a download to satisfy its own gate would be a defect wearing a feature's clothes. That reasoning was about the gate, not about the reader. The gate now carries two page classes (site/tools/tabs.mjs `DATA_TABS`): a data tab must draw the control bar, a page tab must draw none, and BOTH are asserted — so the exemption is a rule instead of a hole. Method is the fourth tab, build-v5-shell strips any surviving pill, and the shell and the tab sweep both fail on one. The rule is deleted rather than left unused: a stylesheet that describes a component the site no longer has is how the next reader concludes it still does. */ .topbar-meta { display: flex; gap: var(--s-3); flex-wrap: wrap; } .topbar-meta span { font-family: var(--mono); font-size: 11px; text-transform: uppercase; letter-spacing: 0.08em; color: var(--text-3); } .topbar-meta b { color: var(--text-2); font-weight: 500; } /* ── Hero ─────────────────────────────────────────────── */ .hero { max-width: 1280px; margin: 0 auto; padding: clamp(36px, 6vh, 72px) clamp(20px, 4vw, 48px) 10px; } .hero h1 { font-family: var(--disp); font-weight: 500; font-size: clamp(30px, 4.6vw, 48px); letter-spacing: -0.025em; line-height: 1.08; color: var(--white); } .hero-sub { max-width: 620px; margin-top: var(--s-3); color: var(--text-2); font-size: 15px; } /* ── Filter bar ───────────────────────────────────────── */ /* ── THE CONTROL BAND ────────────────────────────────────────────────────────────────────────── LA: "the controls are not vertically centred in the control bar's band." THE CAUSE WAS `margin-top: var(--s-5)`, AND NO AMOUNT OF PADDING WOULD HAVE FOUND IT. `.bar` painted `color-mix(--bg 86%, transparent)` over a `--bg` page — the same colour — so the 20px margin above it was INSIDE the strip a reader perceives, which runs from the tab strip's bottom border (the last edge above) to `.bar`'s own (the first edge below). Measured across three tabs × six widths × two themes: 29px above the controls, 10px below, 36 of 36 off. `tools/check-v5-band.mjs` now measures that painted span rather than `.ctl`'s box — the first instrument I wrote measured `.ctl` inside `.bar` and reported a 1px skew on every single case, because the box the code calls the band is not the band anybody sees. AND THE BAND IS CHROME, SO IT SITS UNDER THE PAGE RATHER THAN ON IT. Three surfaces, three relationships: the tab strip is deepest, this band is one step above it and still BELOW the content ground, and the page is the ground. Before, all three landed within a couple of luminance values of each other and only a hairline separated them, which is why the whole top of the site read as one flat slab with lines drawn across it. THE OPAQUE GROUND BELOW IS NOW THE PHONE'S SURFACE AND THE TABLET'S FALLBACK. Blur and translucency left this rule in the flat-slab pass, then came back at ≥768px only — LA, mid- scroll on an iPad: a card row cut dead at an opaque band's edge "looks broken". The translucent version lives in THE PINNED CHROME near the top of this file, derived from the same mix at a measured per-theme alpha; under 768px this solid ground is all there is, which is the site's performance rule (backdrop-filter 768px+ only). The theme still follows the tokens — the light-theme failure this rule was written for cannot come back, because nothing here is a literal colour. */ /* THE PIN IS NOT HERE. `position: sticky; top: 0; z-index: 40` used to sit in this rule and it was one of four such rules; the band's offset and stacking are declared once, in THE PINNED CHROME near the top of this file. Everything below is the band's SURFACE, which is what this block is about. */ .bar { background: color-mix(in srgb, var(--bg-deep) 80%, var(--bg)); border-bottom: 1px solid var(--border); margin-top: 0; } .bar-row { max-width: 1280px; margin: 0 auto; padding: 10px clamp(20px, 4vw, 48px); display: flex; gap: var(--s-2); align-items: center; flex-wrap: wrap; } /* The filters take the row; the count is pushed to the far end so it reads as a result, not a label sitting in front of the controls that produce it. */ .bar-filters { display: flex; gap: var(--s-1); flex-wrap: wrap; } .bar-filters + .hit-count { margin-left: auto; } .search { flex: 1 1 220px; min-width: 150px; padding: var(--s-2) var(--s-3); border: 1px solid var(--border); border-radius: var(--r-s); background: var(--surface); outline: none; } .search:focus { border-color: var(--blue-border); } .search::placeholder { color: var(--text-3); } .bar select { padding: var(--s-2) var(--s-3); border: 1px solid var(--border); border-radius: var(--r-s); background: var(--surface); cursor: pointer; max-width: 44vw; -webkit-appearance: none; appearance: none; } .seg { display: flex; height: 36px; border: 1px solid var(--border); border-radius: var(--r-s); overflow: hidden; background: var(--surface); } .seg button { padding: 0 var(--s-3); border: none; background: transparent; color: var(--text-2); font-size: 14px; } .seg button.on { background: var(--blue-soft); color: var(--blue-bright); } /* ── Sections ─────────────────────────────────────────── */ main { max-width: 1280px; margin: 0 auto; padding: 4px clamp(20px, 4vw, 48px) 80px; } .genre { padding-top: var(--s-10); } .genre-head { display: flex; align-items: baseline; gap: var(--s-3); flex-wrap: wrap; } .genre-head h2 { font-family: var(--disp); font-weight: 500; font-size: clamp(20px, 2.4vw, 27px); letter-spacing: -0.015em; color: var(--white); } .genre-head .n { font-family: var(--mono); color: var(--text-3); font-size: 12px; } /* ── List view (default) ──────────────────────────────── */ .rows { margin-top: var(--s-3); border: 1px solid var(--border); border-radius: var(--r-m); overflow: hidden; } .row { display: grid; align-items: baseline; column-gap: var(--s-3); grid-template-columns: minmax(150px, 190px) 1fr auto auto; padding: var(--s-3) var(--s-4); background: var(--surface); border-top: 1px solid var(--border); cursor: pointer; text-align: left; width: 100%; border-left: none; border-right: none; border-bottom: none; font-size: 14px; } .row:first-child { border-top: none; } .row:hover { background: var(--surface-2); } .row-name { font-family: var(--disp); font-weight: 500; color: var(--white); font-size: 15px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } .row-name .anchor { color: var(--amber); font-size: 12px; margin-left: var(--s-1); } .row-why { color: var(--text-2); overflow: hidden; white-space: nowrap; text-overflow: ellipsis; min-width: 0; } .row-dim { font-family: var(--mono); font-size: 11px; text-transform: uppercase; letter-spacing: 0.07em; color: var(--blue-bright); white-space: nowrap; } .row-meta { font-family: var(--mono); font-size: 11px; color: var(--text-3); white-space: nowrap; } .row-meta .dark-dot { color: var(--text-2); } /* ── Cards view ───────────────────────────────────────── */ .grid { margin-top: var(--s-3); display: grid; gap: var(--s-4); grid-template-columns: repeat(auto-fill, minmax(min(330px, 100%), 1fr)); } /* ── THE CARD IS A MOUNT AND THE CAPTURE IS A PRINT LAID ON IT ───────────────────────────────── LA, on the gradient that used to end each thumbnail: he disliked it, and he was right — see the note on the mask rule further down for what it actually did to 739 photographs. The mount is the answer to the problem that fade was reaching for. A crop through the middle of someone's page looks broken when nothing frames it and intentional when something does; a fade makes the crop foggy, a mount makes it a decision. 4px of the card's own surface shows on all four sides of every capture, so the picture is an OBJECT PLACED ON A BOARD rather than the card's own skin — which is the "detaching the object from the surface" LA asked for, said in the one place it is said 739 times. THE RADII ARE CONCENTRIC AND THAT IS THE WHOLE TRICK. outer = inner + inset, so 4px of mount under a 12px print gives a 16px card: --r-l over --r-m over --s-1. Get this wrong by even 2px and the corners bulge and the inset reads as a misalignment rather than as a margin. This is also why the radius ladder gains no new value — the three rungs it already had are exactly the three this needs. ── HOW IT LEAVES THE SURFACE, AND WHY THE TWO THEMES DO NOT GET THE SAME ANSWER ── On #121317 a drop shadow is invisible: there is nothing darker for it to be, so a shadow on a dark ground is a blurred smudge that costs a paint and buys nothing. What a raised object actually does under light from above is CATCH ITS TOP EDGE — so the dark theme lifts with a 1px highlight and a surface one step lighter than the page, which is how a physical control panel reads and how every well-made dark interface does it. The light theme gets the shadow, because there the physics work and a white card on a grey page has no lighter edge to catch. Same object, two grounds, two mechanisms. */ .card { background: var(--surface); border: 1px solid var(--border); border-radius: var(--r-l); padding: var(--s-1); overflow: hidden; cursor: pointer; box-shadow: inset 0 1px 0 0 color-mix(in srgb, var(--white) 7%, transparent); /* Named properties only — `box-shadow` is deliberately NOT in this list. Animating a shadow repaints the card and its ground on every frame of a 250ms transform, on up to 739 of them. */ transition: border-color .2s, transform .25s cubic-bezier(.2,.7,.2,1); } :root[data-theme="light"] .card { box-shadow: 0 1px 2px rgba(0,0,0,.05), 0 10px 24px -14px rgba(0,0,0,.16); } @media (hover: hover) { .card:hover { transform: translateY(-3px); border-color: var(--border-strong); } .card:hover .card-visit { opacity: 1; } } .card-media { position: relative; aspect-ratio: 16 / 10; background: var(--surface-3); overflow: hidden; border-radius: var(--r-m); } .card-media img { width: 100%; height: 100%; object-fit: cover; object-position: top; } /* THE PLACEHOLDER SHIMMER WAS THE MOST EXPENSIVE THING ON THIS SITE, AND IT DECORATED NOTHING. It animated `background-position` — a paint property, on the main thread, every frame — on every card at once. A performance audit measured 712 concurrent infinite animations on the landing tab three seconds after load, the main thread saturated at 5.13s of work per 5s of doing nothing, a median frame of 33ms (30fps) sitting still, and 44.2% of frames dropped across a full scroll of the 127-screen page. With it removed: 60fps at rest and 0.1% dropped on the same scroll. It also drove the style-recalc cost, because `:has(img.ld)` re-invalidates as each of 739 images loads — +2,386 recalcs and +1.59s of recalc time on one scroll. Kept as a shimmer, moved onto the compositor: the gradient now rides a pseudo-element under `transform: translateX()`, which never touches paint or layout, and the loaded state hides the pseudo-element instead of switching an animation off. The card looks the same and the frame budget comes back. */ .card-media { background: var(--surface); isolation: isolate; /* THE PRINT ALWAYS HAS AN EDGE, WHATEVER IS IN IT — and it has to be an INSET ring, not a border. 739 captures include white pages, near-black pages and full-bleed photography; a border sits outside the picture, so a white capture on a white card swallows it and a black capture on a dark card swallows it too. Drawn over the image, the edge survives every one of them. Mixed from `--text` so it inverts with the theme by construction rather than by a second rule somebody has to remember to update. */ box-shadow: inset 0 0 0 1px color-mix(in srgb, var(--text) 12%, transparent); } .card-media::before { content: ""; position: absolute; inset: 0; z-index: 0; background: linear-gradient(110deg, var(--surface) 30%, var(--surface-2) 45%, var(--surface) 60%); background-size: 55% 100%; background-repeat: repeat-x; animation: shimmer 1.5s linear infinite; } .card-media:has(img.ld)::before, .card-media:has(.noshot)::before { content: none; } .card-media img { position: relative; z-index: 1; opacity: 0; transition: opacity .4s ease; } .card-media img.ld { opacity: 1; } @keyframes shimmer { from { transform: translate3d(-55%, 0, 0); } to { transform: translate3d(0, 0, 0); } } /* A placeholder that animates is decoration; a reader who has asked for less motion gets the static ground instead, which is what the rest of this stylesheet already does. */ @media (prefers-reduced-motion: reduce) { .card-media::before { animation: none; } } .genre { animation: fadeUp .4s ease both; } @keyframes fadeUp { from { opacity: 0; transform: translateY(10px); } } .card-media .noshot { position: absolute; inset: 0; display: flex; align-items: center; justify-content: center; color: var(--text-3); font-family: var(--mono); font-size: 12px; } /* AN OVERLAY ON A PHOTOGRAPH DOES NOT FOLLOW THE PAGE THEME. This chip sits on top of a site capture, so its ground is the picture, not the page — and its ink has to be legible against a photograph in either theme. It took `--blue-bright` from the palette, which is a bright blue on dark and a DARK blue on light, so in the light theme it became dark ink on a dark scrim: 2.41:1, measured on 777 cards. Both the scrim and the ink are stated here and stay stated. Same rule the components already needed for text laid over their own media. */ .card-visit { position: absolute; right: 10px; bottom: 10px; opacity: 0; transition: opacity .2s; font-family: var(--mono); font-size: 11px; padding: var(--s-1) var(--s-3); background: rgba(14,15,18,.85); color: #b9d9ff; border-radius: var(--r-pill); border: 1px solid rgba(46,150,255,0.42); } /* THE PADDING A READER SEES IS UNCHANGED, and that is deliberate: the mount takes its 4px out of the body's own inset rather than out of the card, so the copy sits exactly where it sat before (16px from the card's edge, 12px under the print) and only the picture moved. A material change that also reflows every line of text is two changes, and the second one nobody asked for. */ .card-body { padding: var(--s-3); } .card-top { display: flex; align-items: baseline; gap: var(--s-2); } .card-top h3 { font-family: var(--disp); font-size: 15px; font-weight: 500; color: var(--white); } .card-top .origin { font-family: var(--mono); color: var(--text-3); font-size: 11px; } .card-top .anchor { color: var(--amber); font-size: 12px; } .card-why { margin-top: var(--s-1); color: var(--text-2); font-size: 13px; display: -webkit-box; -webkit-line-clamp: 3; -webkit-box-orient: vertical; overflow: hidden; } .card-chips { margin-top: var(--s-2); display: flex; gap: var(--s-1); flex-wrap: wrap; } /* A CHIP THAT NAVIGATES MUST LOOK LIKE IT DOES. The Taxonomies chips became links to the filtered Design tab, and an inherits none of a chip's affordance: without this it reads as the same inert label it was, which is the half of the complaint that a working href does not fix. Given the pointer, the underline-on-hover and the focus ring every other link on this site has, plus a dimmed count so the number reads as a quantity rather than as part of the name. */ .chip-link { display: inline-flex; align-items: baseline; gap: .5ch; text-decoration: none; cursor: pointer; transition: border-color .15s, color .15s, background-color .15s; } .chip-link:hover { color: var(--text); border-color: var(--border-strong); background: var(--surface-2); } .chip-link:focus-visible { outline: 2px solid var(--blue); outline-offset: 2px; } .chip-n { color: var(--text-3); font-variant-numeric: tabular-nums; } .chip-link:hover .chip-n { color: var(--text-2); } .tx-cell-link { color: inherit; text-decoration: none; border-bottom: 1px solid transparent; } .tx-cell-link:hover { border-bottom-color: currentColor; } .tx-cell-link:focus-visible { outline: 2px solid var(--blue); outline-offset: 2px; } .chip { font-family: var(--mono); font-size: 11px; letter-spacing: 0.05em; text-transform: uppercase; padding: var(--s-05) var(--s-2); border-radius: var(--r-pill); border: 1px solid var(--border); color: var(--text-2); /* STATE A SURFACE OR THE BROWSER WILL. `.chip` set a border and a colour and no background, which is invisible on a and catastrophic on a