/* ========================================================================== GameOnTime — the customer-side design system ========================================================================== /admin and /pro look like one product because Filament gives them a design system. The customer side was 2,172 lines of hand-written CSS with nothing governing it, so every page was a fresh set of decisions and read as a different company. This file is the thing that was missing. ---------------------------------------------------------------- WHAT IT IS Two sections and nothing else: 1 · TOKENS — the complete vocabulary. Every number and every colour the customer side is allowed to use. 2 · COMPONENTS — classes that consume ONLY those tokens. A component rule containing a hex, a px font size or a px gap is a bug, and `SiteTokensTest::test_no_component_or_page_rule_carries_a_raw_value` says so. ------------------------------------------- WHERE THE COLOUR VALUES LIVE NOT HERE. `config/brand.php` is and remains the one place a colour is decided; App\Support\Brand::cssVariables() prints it into every page as `--accent`, `--card`, `--text` and the rest. Every colour token below is an ALIAS onto one of those — `var(--card)`, never `#171B28`. So there are two homes and the split is a rule rather than an accident: · a COLOUR VALUE is a brand decision -> config/brand.php · the TOKEN VOCABULARY is a design decision -> this file Which means this file is the one place the SYSTEM is defined, and that file is the one place a COLOUR is defined, and neither contains a copy of the other. Anything the system needs that the brand source does not have gets added THERE and aliased HERE. That is how the surface, line and text ramps arrived on 15 Aug — they were sitting in `:root` in site.css, which was beside the source rather than in it. ------------------------------------------------------------- LOAD ORDER layouts/site.blade.php loads this file BEFORE public/css/site.css, and prints the brand variables AFTER both. That order is deliberate: · system.css first — so a legacy page rule in site.css can still win on equal specificity while its page is being migrated. No `@layer`, on purpose: a layered rule loses to EVERY unlayered one regardless of specificity, and a silent, invisible loss is the exact failure mode this project has paid for twice with Tailwind utilities in Filament Blade. · brand vars last — custom properties resolve at use time, so the order would not strictly matter; it is last because that is where it already was and moving it would be a change with no reason. 🔴 NO TAILWIND, NO UTILITY CLASSES, NO BUILD STEP. This file is served as written. That is not a preference — Filament ships precompiled CSS and a utility class in a custom Blade view compiles to nothing and fails SILENTLY, which has bitten this project twice. 🔴 LOGICAL PROPERTIES ONLY. `margin-inline-start`, `padding-block`, `inset-inline-end`, `text-align:start`. The site is RTL-safe by construction and every rule below keeps it that way with no [dir="rtl"] override. `background-position` has no logical form and is the one documented exception; nothing here uses it. ========================================================================== */ /* ========================================================================== 1 · TOKENS ========================================================================== */ :root { /* ------------------------------------------------------------------ COLOUR Roles, not colours. "surface-raised" survives a change of mind about what a card is made of; "dark-blue-grey" does not — which is config/brand.php's own naming argument, applied one level up. Every ratio in a comment below is WCAG 2.1 against `--gt-ink`, computed from the two hexes and then pixel-sampled off the rendered /design page. Both numbers, because a comment quoting one reads as proof the rule was checked once. */ /* Surfaces — a ladder, and a thing's step says how far off the page it is. */ --gt-surface-page: var(--bg); /* 15.45:1 */ --gt-surface-sunken: var(--bg-2); /* 14.30:1 — inputs, wells, anything recessed */ --gt-surface-raised: var(--card); /* 13.86:1 — cards, panels */ --gt-surface-overlay: var(--card-2); /* 12.50:1 — toasts, menus, hover fills */ /* 🔴 THE MODULE SURFACE — V-27 B2, and it is a ROLE alias over the ladder, not a fifth colour. "The page's one decision object sits a step above the ordinary card" — the gift page's purchase module is its first reader. WHY IT CANNOT SIMPLY READ `--gt-surface-overlay`: the two ladders do not agree about what their top step is. On dark, overlay (#1E2434 through the emitter) is the top and the module wants it — measured on the rendered gift page 30 Aug: raised-on-page was 1.11:1, the "wall rather than an object" figure, and overlay-on-page is 1.24:1. On LIGHT the top is `raised` (white, 1.13:1 against the page — computed from the two hexes) and overlay is the WEAKER step there (1.05:1, computed) — and it is not a surface role at all on light: brand.php's own ladder note makes it the hover wash and the floating ground, so a module built of it would be a panel painted the colour its own hovers wash to. So the light blocks below re-point this alias at `raised`, exactly as `--gt-accent-hover` re-points for the same the-ladders-disagree reason. One role, one name, the theme decides the step — and no new value joins brand.php, because both answers already exist on the ladder. */ --gt-surface-module: var(--gt-surface-overlay); /* Hairlines. Never text and never a fill. --gt-line-strong is the edge of every control (input, select, textarea, check, radio, secondary button) and since 19 Aug (BUG-344) it clears WCAG 1.4.11's 3:1 on every surface: 4.08 / 3.78 / 3.66 / 3.30 on page / sunken / raised / overlay — computed from config/brand.php, then pixel-sampled by the round's verifier. It is still nowhere near what a glyph needs (text is 4.5:1), which is why it stays a border. --gt-line is the divider and the decorative card edge, which 1.4.11 does not reach. */ --gt-line: var(--line); --gt-line-strong: var(--line-2); /* Text. TWO ROLES, NOT THREE. config/brand.php carries a third (`text.faint`, #68748F) because eight legacy rules still paint it. It is deliberately NOT given a token here: it measures 4.08 / 3.78 / 3.66 / 3.30 against the four surfaces above and so fails the 4.5:1 floor on every one of them, including the best case. There is no surface in this product on which it is legal, so there is no honest token to define. Reaching for it has been a filed bug four times (BUG-010, BUG-101, BUG-118, and the hint rule corrected on 14 Aug); a token would be the fifth invitation. */ --gt-ink: var(--text); /* 13.86:1 on raised */ --gt-ink-muted: var(--muted); /* 6.53:1 on raised — passes AA on all four */ /* Accent. `--gt-ink-on-accent` is the dark text that goes ON an accent fill: the accent is a pale cyan and white on it is 1.3:1. Ink on it is 11.74:1. */ --gt-accent: var(--accent); /* 🔴 `--gt-accent-soft` IS AN ARTWORK COLOUR AND IT IS THE SAME IN BOTH THEMES. It is the LIGHT END of `--gt-gradient-brand` and of `--gt-media-placeholder` — the tile's edge ring and the gradient a game with no cover paints — and both of those sit ON or BESIDE artwork, where a bright cyan is right whatever the page is made of. The light theme's first cut overrode `--accent-2` underneath it so the primary button's hover would go darker, and the verifier caught what that did: the no-artwork tile's gradient started at a dark teal on a light page, and the comment two blocks down claimed these gradients were "deliberately not themed" — a statement about a mechanism nobody had measured, which is this project's most-repeated defect, reproduced by the round that keeps naming it. The button's hover has its own token below. One token painting two things that need opposite answers is the split this system keeps making. */ --gt-accent-soft: var(--accent-2); --gt-accent-strong: var(--accent-dim); /* THE PRIMARY BUTTON'S HOVER, and it is a SEPARATE token from the artwork's light end for the reason above. On dark "more" is brighter, so it is the soft accent; on light "more" is darker, so the light block points it at the strong one — a button that got paler on hover would lose its own label. */ --gt-accent-hover: var(--gt-accent-soft); --gt-ink-on-accent: var(--bg); /* Status. Meaning, not brand. As TEXT these are surface-dependent and danger is the one that bites: 7.53 / 7.99 / 4.56 on raised, but danger drops to 4.11 on overlay and fails there. So the system NEVER paints a message in danger — it paints --gt-ink on a danger tint (12.36:1) and lets the tint and the edge carry the meaning. The status colour is for the EDGE and the ICON only. */ --gt-success: var(--green); --gt-warning: var(--amber); --gt-danger: var(--red); /* The tints those edges sit on. 12% is the measured floor at which the tint is distinguishable from the card behind it without dragging the text on top of it below AA: danger at 12% over raised leaves --gt-ink at 12.36:1, success 11.42:1, warning 11.25:1. */ --gt-tint-success: rgba(var(--success-rgb), .12); --gt-tint-warning: rgba(var(--warning-rgb), .12); --gt-tint-danger: rgba(var(--danger-rgb), .12); --gt-tint-accent: rgba(var(--accent-rgb), .12); /* COMING SOON — Omar's decision, 19 Aug: the one place the site is orange. From config/brand.php `soon` (sampled from the GTA VI artwork's sunset), through the emitter's --soon / --soon-rgb. Scoped by BrandPaletteTest to the soon tile's badge, wash and decorative hover; nowhere else. */ --gt-soon: var(--soon); --gt-tint-soon: rgba(var(--soon-rgb), .16); /* A hover wash that works on any surface, because it is the surface plus light rather than a named colour. Two steps, because a control on a card needs a different amount of lift than one on the page. */ --gt-wash-soft: rgba(var(--wash-rgb), .04); --gt-wash-strong: rgba(var(--wash-rgb), .07); /* And its opposite, for a press. Going DARKER on press and LIGHTER on hover is the whole of the depth illusion; see --gt-lift below. */ --gt-press: rgba(var(--elev-rgb), .18); /* -------------------------------------------------------------- TYPE SCALE ONE SCALE, NINE STEPS, and `md` is the body. Before this file the customer side used .7, .74, .8, .82, .84, .86, .88, .9, 1.05, 1.35 and 1.5rem AND 12.5px, 13.5px, 14.5px and 20px — twenty-plus sizes, most of them within a pixel of a neighbour, none of them chosen against the others. Every step is a whole pixel at a 16px root, because half-pixel text rasterises differently between the two languages' fallback faces and the Arabic page ends up a hair taller than the English one for no reason anybody can see. */ /* 🔴 THE FLOOR IS 12px — Omar's decision, 19 Aug 2026 (BUG-342). The two smallest steps were 11 and 12; the audit found the micro-labels (COMING SOON, .got-label, "Total price", the pay page's NOT AVAILABLE YET tags) at 11px and the checkout's money help sentences at 12. Both steps are one pixel up, so nothing customer-facing renders under 12px, and 2xs now MEETS xs at 13px. That is deliberate: the two names name two ROLES (help text vs dense UI), and a role keeps its token so the day the floor moves again the help text moves with it and the metadata does not. Nine names, eight sizes; the /design specimen shows both. */ /* 12px — uppercase micro-labels, and (since V-06) the media card's meta line, which is the smallest thing this product prints on an image. The "and nothing else" this comment used to carry stopped being true the moment a second role needed the floor; a comment that names its callers goes stale the day one is added, so it names the SIZE's job instead: the smallest step, for a label or a datum that is read after the thing above it. (was 11) */ --gt-text-3xs: 0.75rem; --gt-text-2xs: 0.8125rem; /* 13px — help text, captions, table headers (was 12) */ --gt-text-xs: 0.8125rem; /* 13px — dense UI, secondary metadata */ --gt-text-sm: 0.875rem; /* 14px — controls, buttons, inputs */ --gt-text-md: 1rem; /* 16px — body. The default, and the only one that is */ --gt-text-lg: 1.125rem; /* 18px — card headings */ --gt-text-xl: 1.375rem; /* 22px — section headings, money totals */ --gt-text-2xl: 1.75rem; /* 28px — page headings */ --gt-text-3xl: 2.25rem; /* 36px — the one hero line on a page that has one */ /* The display size: 36px on a phone to 56px on a desktop, by clamp, so the scale has one entry above 3xl rather than a rule per breakpoint. 🔴 IT SAID "for the ONE headline on the home page" UNTIL V-22, AND THAT STOPPED BEING TRUE THE DAY V-22 B3 GAVE IT A SECOND READER: the gift card's price, which became that page's one hero line when the two repetition rows under it were deleted. A comment naming a caller goes stale the day one is ADDED just as surely as the day one is removed — the hover-skill records that exact shape — and this one was left standing by the batch that added the reader. The scope is now "the one hero line on a page that has one", of which there are two. 🔴 AND THE SECOND READER TAKES THE SIZE WITHOUT THE LEADING, WHICH IS STATED RATHER THAN LEFT TO BE FOUND. `--gt-leading-display` exists because the home page's headline is DESIGNED to wrap; the price never wraps, so it keeps `.total`'s inherited `--gt-leading-tight` (measured: 56px on a 67.2px line box, 1.2). Defensible, and a divergence from the pairing this step declares. Weight and position carry the hierarchy from here down; no letter-spacing (the system reserves tracking for the micro-label — it is inert or harmful on Arabic, and this line will be Arabic when its key lands). 🔴 AND V-25 B3 TOOK THE SECOND READER BACK OFF, so the clamp is one reader again: the home headline. MEASURED at 1536 the ceiling put the gift price at 56px against the same page's 28px H1 — exactly double — and the figure out-shouted the column it concludes. The price wears `--gt-text-price` below now; the two paragraphs above are kept as the history of how a caller was added and removed inside three rounds. */ --gt-text-display: clamp(2.25rem, 1.5rem + 3vw, 3.5rem); /* 🔴 THE PRICE STEP — V-25 B3, retuned by V-27 B2, and it is ONE component's own size (the `--gt-text-tile` shape), not a new step of the scale: the gift card product page's price, read by the two banded `.got-gcpage .total` rules in pages.css and by nothing else. 🔴 40 / 32 ARE OMAR'S NUMBERS, VERBATIM FROM THE V-27 B2 BRIEF — "The price: 40px desktop / 32px mobile" — which outranks the scale-position argument the 46px version of this comment made (22 -> 28 -> 36 at x1.27–1.29; 36 x 1.28 ≈ 46). That derivation was honest and it answered a different page: 46 was chosen while the figure stood ALONE in a wide panel with nothing beside it. V-27 B2 gives it company — the exchange block puts the face value and its label on the same line — and a figure with company does not need to shout. Both values measured rendered (V-27 B2, 30 Aug): 40px against the same page's 28px H1 on the wide band, 32px in the phone bar against the bar's own 44px buttons. 🔴 ONE TOKEN, TWO VALUES, MOVED BY THE QUERY — the `--gt-text-tile` shape exactly, stated at that token in this file: put the value in a token and let the breakpoint move the token. The root value is the PHONE's (32px); the 56.25em block beside the tile's own breakpoints rewrites it to 40px on the wide band. Both banded pages.css rules read the one name, so the two bands cannot disagree about anything except what the breakpoint says — and the breakpoint is this file's, written once. */ --gt-text-price: 2rem; /* 32px */ /* 🔴 THE DISPLAY STEP GETS ITS OWN LEADING — V-06 Batch 5, 22 Aug, and it is a FIFTH value rather than a retune of `tight` because the two are answers to different questions. `--gt-leading-tight` is 1.2 for a HEADING, which is usually one line: what it buys there is room for a descender under an ascender when a long one does wrap. The display step is the one line on this site that is DESIGNED to wrap — 18ch, balanced, two lines at every desktop width — and 1.2 at 56px puts 11px of air between the two halves of one sentence, which reads as two sentences. Measured on the rendered page at 1536 this round, same element, both values, a real frame between the change and the read: the headline's box is 134.38 tall at 1.2 and 120.94 at 1.08 — 13.44px, which is most of one card's worth of the fold budget this batch is spending. The reference file asks for 1.08 at 52px; this is that number at the size the scale already decided. 🔴 ITS SCOPE IS THE HOME PAGE'S HEADLINE, AND IT SAID "the ONE hero line on the ONE page that has one" UNTIL V-22. `--gt-text-display` had two readers from V-22 B3 to V-25 B3 — the gift card's price took the size, without this leading, because a price never wraps — and V-25 B3 moved that price onto its own `--gt-text-price`, so the size and this leading have ONE reader each again, and it is the same one: the headline. The wrap argument above is unchanged and is why this value survives its second reader leaving. */ --gt-leading-display: 1.08; --gt-leading-tight: 1.2; /* headings */ --gt-leading-snug: 1.35; /* controls and short labels */ --gt-leading-normal: 1.6; /* body prose */ --gt-weight-normal: 400; --gt-weight-medium: 500; --gt-weight-semibold: 600; --gt-weight-bold: 700; --gt-weight-heavy: 800; /* Only the 11px uppercase micro-label gets tracking. Letter-spacing on Arabic is at best inert and at worst breaks the joins between letters, so it is confined to one step that the Arabic pages use for Latin-free labels and is never applied to body text. */ --gt-tracking-label: .07em; /* THE FACE — and since V-30 B3 (GAP-176, 2 Sep 2026) it is DELIVERED, not hoped for. This token used to say "not a new font: adding a webfont would be a network request on a page that needs none". MEASURED before the change: `document.fonts.size` 0, zero `@font-face` anywhere, and every "Inter" surface on the site rendering in whatever the visitor owned — Segoe UI here — so `font-variant-numeric` was answering for a face nobody had chosen (TRAPS: a declared font is not a delivered font). Inter Variable is now self-hosted under public/fonts/inter/ and declared by `Brand::fontFaces()` in the layout head, latin + latin-ext, one variable file per subset, `swap` with a preload. THIS IS THE ONLY PLACE THE FACE IS DECIDED. `body` in site.css reads it; the controls that do not inherit (`.got-btn`, `.got-input`) read it; the figure surfaces read `--gt-family-numeric`, which reads it. A second spelling anywhere is the defect the batch removed (site.css's body rule carried one, and it — not this token — was what the site rendered in). The fallbacks after Inter are for a Latin page whose font has not arrived yet (`swap`): a metric-near system sans, so the re-flow when Inter lands is small (measured per page in the batch report). */ --gt-family: Inter, -apple-system, "Segoe UI", Arial, sans-serif; --gt-family-numeric: var(--gt-family); /* THE ARABIC STACK — named, not inherited. Inter carries no Arabic range (the batch's impact pass measured an Arabic run at +0.18% under Inter: unchanged, every glyph fell past it), so on /ar what matters is what FOLLOWS Inter, and "-apple-system, Segoe UI, Arial" is a Latin answer that happens to have Arabic glyphs in one member. Chosen Windows-first, because that is where this site is built and mostly read. Segoe UI is the Windows UI face and carries Arabic at weights 400-700 (MEASURED, CSS.getPlatformFontsForNode: every 400-700 Arabic run rendered in Segoe UI / Segoe UI Bold before and after this token) — BUT NOT AT 800, where the family resolves to Segoe UI Black, a Latin-only face. MEASURED on /ar/login, /ar/register and the signed-out /ar/cart, `h1` at weight 800 28px: BEFORE this token the old Latin list fell past Segoe UI Black and Arial to `[Times New Roman ×11, Segoe UI Black ×1]` — every weight-800 Arabic heading on the site was in a Latin SERIF; AFTER, `[Tahoma ×11, Inter ×1]`. Tahoma is second here for exactly that reason: it is the older Windows Arabic face and it has the weight-800 Arabic that Segoe UI does not. Whether an 800 heading in Tahoma beside 400-700 body in Segoe UI is the wanted pairing is Omar's call, filed by the coordinator; the stack's ORDER is what this token decides. Then the other platforms by name: Geeza Pro (macOS/iOS), Noto Naskh Arabic and Noto Sans Arabic (Android and any machine with the Noto set), system-ui — INFERRED, no such device was measured. Inter stays FIRST on /ar so a Latin run — a brand name, a price — keeps the site's face and its tabular figures; the Arabic glyphs never came from it and now fall to a stack chosen for them. */ --gt-family-arabic: Inter, "Segoe UI", Tahoma, "Geeza Pro", "Noto Naskh Arabic", "Noto Sans Arabic", system-ui, sans-serif; /* ---------------------------------------------------------------- SPACING A 4px rhythm, twelve steps. Named by step and not by size, so a rule saying `--gt-space-5` is choosing a position in the rhythm rather than asking for 16 pixels — which is what makes the whole scale adjustable from here. */ --gt-space-0: 0; --gt-space-1: 0.25rem; /* 4 */ --gt-space-2: 0.375rem; /* 6 */ --gt-space-3: 0.5rem; /* 8 */ --gt-space-4: 0.75rem; /* 12 */ --gt-space-5: 1rem; /* 16 */ --gt-space-6: 1.25rem; /* 20 */ --gt-space-7: 1.5rem; /* 24 */ --gt-space-8: 2rem; /* 32 */ --gt-space-9: 2.5rem; /* 40 */ --gt-space-10: 3rem; /* 48 */ --gt-space-11: 4rem; /* 64 */ /* ------------------------------------------- THE PAGE SHELL (18 Aug) Container, gutter, section rhythm and the tile grid, as tokens — the customer-site UI/UX round's Batch 0. The relationship these fix is between the container width, the tile width, the gutters and the whitespace between blocks; none of them is "bigger". Measured at 1440 and 1920 before choosing: a 1280 container moved the games row 40px and made every tile 6% larger for a three-point change and was rejected; 1180 stays. What was wrong was two AXES (a centred hero over start- aligned sections) and gaps that summed two paddings — the tokens below make one axis and one rhythm possible; the pages that read them do the rest. The gutter and the section rhythm are clamps: 20→40px and 40→64px between a phone and a desktop, on the 4px scale at both ends. A `vw` is a viewport fact, not a spacing literal, and it lives here with the other raw values, which is why the guard permits it. */ --gt-container: 71.25rem; /* 1140 of CONTENT — the 1180 box less its two 20px gutters, kept; the gutter is added outside it, so the content width the tiles were measured against does not move when the gutter grows */ /* 🔴 THE SECOND MEASURE — V-01, 20 Aug. DEFINED HERE AND READ BY NOTHING YET, WHICH IS A STATEMENT AND NOT AN OVERSIGHT. Say which of the two kinds of unused you have written, next to it: this is the guard-for-a-state-not- yet-reached, not the fallback-nothing-can-reach. `ContainerWidthTest` pins that it is unused, so the day somebody applies it the test goes red and asks whether the catalogue has grown enough to want it. THE VALUE IS DERIVED, NOT PICKED. 95rem = 1520px, and 1520 is exactly `.got-cat__grid`'s own floor five times over plus its four gaps (5 x 288 + 4 x 20 = 1520) — the first width at which the catalogue grid yields five equal columns at the measured minimum with nothing left over. It also gives the games grid six tracks at 237px against its measured 224px floor, and it is the largest content width that still fills a 1600 display exactly once the 40px gutters are taken off. A round number in this position would be a number nobody could re-derive. 🔴 AND IT IS APPLIED TO NOTHING, ON THE MEASUREMENT. Simulated on the live site at 1366 / 1440 / 1600 / 1920 in both languages, against 1140, 1440, 1520 and 1560 of content, every candidate surface got WORSE: homepage games grid 3 tiles. 1140 -> 4 tracks, 1 empty. 1520 -> 6 tracks at 1600+, THREE empty. catalogue grid 4 of the 5 Call of Duty groups hold ONE tile. 1140 -> 3 tracks at 367px. 1520 -> 5 tracks at 288px: every tile 79px SMALLER and four empty. home store strip 4 brands. 1140 -> 4 tracks, exactly full. 1520 -> 5 tracks, 1 empty. account order list the row is `1fr auto`, so the whole gain lands between the order title and its price: the gap from title to figure goes 831px -> 1211px. account stat tiles three tiles at 375px become three at 501px, each holding one number and one word. `auto-fill` keeps empty tracks, so a wider container at this catalogue size buys dead space, not density. THE CONTAINER IS NOT WHAT LIMITS THIS PRODUCT TODAY — THREE GAMES IS. Turn this on when a grid is FULL at 1140: four or more games on the homepage, four or more tiles in a catalogue group. It is one class at that point, which is what the token is for. */ --gt-container-wide: 95rem; --gt-gutter: clamp(var(--gt-space-6), 3vw, var(--gt-space-9)); --gt-section-y: clamp(var(--gt-space-9), 6vw, var(--gt-space-11)); /* The rhythm INSIDE a section - the store's three shelves, and whatever groups come next. It is the section step's own clamp at 60%, so the two cannot come apart the day the outer rhythm is retuned; a second literal here would be a number nobody could re-derive. */ --gt-section-y-tight: clamp(var(--gt-space-7), 3.6vw, var(--gt-space-9)); /* 🔴 THE CATALOGUE TILE'S FLOOR — 240px (V-06 Batch 4, 22 Aug). It was 224 from 17 Aug, then 260 for the few hours V-05 Batch 2 stood. V-05 AND V-06 ARE NOT TWO SETTINGS OF ONE IDEA. V-05 held the shelf to a narrow COLUMN (1240, widening to 1560 above 1800) and raised the floor so that four cards inside that column landed at ~295px. V-06's container is FLUID — 1680 with fixed 48px gutters — and the floor is what DECIDES the track count at every width, so it comes back down and nothing hand-writes a column anywhere. The old scheme is deleted rather than retuned, and the figures it derived (295px cards, a 1560 five-track band, a 595px 1↔2 boundary) are gone with it: they described a container that no longer exists. THE ARITHMETIC THIS FLOOR PRODUCES, with the gap at --gt-tile-gap (20) and the gutters at 48 / 24 / 16 (see `.container--shelf` in site.css). `n` tracks fit a content box of C when 240n + 20(n-1) <= C: viewport content C tracks a card is 1920 1584 (capped) 6 (7 want 1780) (1584 - 5x20) / 6 = 247 1536 1440 5 (6 want 1540) (1440 - 4x20) / 5 = 272 1280 1184 4 (5 want 1280) (1184 - 3x20) / 4 = 281 1100 1052 4 (5 want 1280) (1052 - 3x20) / 4 = 248 768 720 2 (3 want 760) ( 720 - 1x20) / 2 = 350 390 358 1 (2 want 500) 358 🔴 THOSE CONTENT WIDTHS CARRY NO SCROLLBAR, AND AT 1100 THAT WAS NEARLY THE WHOLE MARGIN. Every figure above is read off the rendered page with the round's harness, which drives a Chrome whose clientWidth equals the viewport (measured — at 1536 the grid's box is 1440.00, not 1425). A real Windows Chrome takes 15px out of the layout viewport BEFORE the gutter resolves, and the CSS only ever sees the layout viewport, so the honest way to ask what 1100 does on such a machine is to drive 1085. WITH THE GUTTER AT 32 — the reference's number, and this file's for its first hour — 1100 gave 1036 of content against the four tracks' 1020: SIX- TEEN pixels, of which fifteen were the scrollbar it had just said it excluded. Measured: 1085 -> 1021, four tracks by one pixel; 1083 (a 17px scrollbar) -> 1019, and the row DROPS TO THREE. The comment claimed 22px of slack, which was wrong twice over — the subtraction and the premise. THE GUTTER IS THE ONE NUMBER HERE TUNED RATHER THAN DERIVED, so it is what was tuned: 24 under 1150, measured at four scrollbar widths — 1100 no scrollbar content 1052 4 tracks 32px of slack 1085 (15px bar) content 1037 4 tracks 17px 1083 (17px bar) content 1035 4 tracks 15px 1080 (20px bar) content 1032 4 tracks 12px — and no discontinuity where the band ends: 1150 gives 1102 and four tracks, 1151 steps to the 48px gutter, gives 1055, and still four. AND THE BAND NOBODY LOOKS AT, NAMED RATHER THAN LEFT: two tracks need 500 of content, so the 1↔2 boundary is viewport 548 (500 + 2x24) — BISECTED at one-pixel steps, 1 track at 547 and 2 at 548. Below 520 the gutter steps to 16 and the content box jumps UP — 473 at a 521 viewport, 488 at 520 — which is still one track, so the step is invisible in the count and visible only as a wider card. One column runs 320..547. EVERY BOUNDARY BISECTED AT ONE-PIXEL STEPS after the gutter moved, and each one lands where the floor puts it (a viewport of 260n - 20 + 2 x gutter): 1->2 at 548, 2->3 at 808, 3->4 at 1068, 4->5 at 1376, 5->6 at 1636, and the cap engages at exactly 1680. The gutter's own step at 1150 is NOT a discontinuity in the count — 1150 gives 1102 of content and four tracks, 1151 gives 1055 and four — which is the property a gutter has and a hand-written column count does not. */ --gt-tile-min: 15rem; /* THE SHELF'S MEASURE — one measure, one wearer (`.container--shelf`). 1680 COMES FROM THE APPROVED DESIGN STUDY, and rather than dress it up as a derivation it is stated with the band it sits in, so the next person can check it. SIX tracks land anywhere from 1636 (6x240 + 5x20 + 2x48, the first box that holds them) to 1895 (one under what a seventh needs: 7x240 + 6x20 + 2x48 = 1896). 1680 is inside that band and near its floor, which is what puts the six cards at 247 rather than at the 283 they would reach at the ceiling. A seventh track is wider than the displays this product is used on. Above 1680 the container stops growing and the page gains side margin; below it the container IS the viewport and the floor decides the count. WHAT IT REPLACES: V-05's `--gt-shelf-max` (1240) and `--gt-shelf-max-wide` (1560, behind an 1800 breakpoint). The pair is DELETED, not retuned — V-06 has one cap and no breakpoint, and a second measure left defined and unread is indistinguishable from one somebody forgot to wire up. IT IS STILL SEPARATE FROM --gt-container-wide, which stays defined and applied to nothing: that one is derived from `.got-cat__grid`'s floor — the SERVICE grid on a game page — and is a statement about a different grid that V-06 did not measure. ContainerWidthTest goes on asking the next person which grid they widened. This is not that answer. */ --gt-shelf-max: 105rem; /* 1680 — six tracks at the floor, gutters included */ --gt-tile-gap: var(--gt-space-6); /* THE HEADER'S HEIGHT — V-30 B4, the one new layout token the round allows. Until this batch the height was written in five places that disagreed (site.css `.nav{min-block-size:72px}`; this offset at 5.75rem here and 5rem in the phone band; pages.css's basket summary at 5.5rem; site.css's order chat at 5.75rem, twice), so a change to the row moved four sticky offsets by hand or not at all. Now the row's min-block-size (site.css `.nav`), the scroll offset below and — through it — every sticky surface, the anchored sections, `#main` and the phone toast DERIVE from this line. HeaderHeightTest asserts the exact set of declarations and the derived set of consumers. 4rem is the header's TOTAL height, border included: `.nav` takes `calc(var(--gt-header-height) - var(--gt-border-hair))`, so the 1px transparent border that carries the gradient hairline is inside the figure and the header's border-box lands on the token. MEASURED 2 Sep 2026, headless Chrome 152: 64.00 on the wide row at 1536, signed out and signed in, both languages (V-30 B4, unchanged by B5); on the phone the header is NOT this token's value any more — 116.00 at 390, 375, 360 and 320, both languages, both states (V-30 B5), because the band below declares its own. The floor under this one is the wide row's content: the tallest item is the pill and the language switch at 46.00 (the wordmark is 45.98) + 2×8 padding = 62, one under the 63 this resolves to, so the token binds. The phone's floor is two lines — 8 + 44 + 8 + 46 + 8 = 114 under its own 115 — and is worked out where that band is declared (THE HEADER MENUS). */ --gt-header-height: 4rem; /* An in-page anchor's clearance from the sticky header, so a target's title is not scrolled UNDER it (the hero's action → #games was, at every width — verified 18 Aug). The header plus one --gt-space-6 of air — the step the desktop toast keeps from the viewport's edge, so the phone toast under the bar and the desktop toast above the edge share one distance: 84px over a 64px bar on the wide row and 136 over 116 on the phone (V-30 B5), MEASURED in both bands. It was a literal 5.75rem here (92 over the old 73) until V-30 B4 made it a derivation. */ --gt-scroll-offset: calc(var(--gt-header-height) + var(--gt-space-6)); /* THE PILL NAVIGATION'S OWN NUMBERS — V-30 B5 (`.got-tabs`, THE HEADER MENUS). Component tokens, beside the header's, because two of them are read by an ARITHMETIC: the indicator bar is a fixed-width span placed by `translateX()` alone, and its distance is computed from the tab width and its own width — `tab × (index + ½) − bar ÷ 2` — so those two must be tokens the calc can read, never a measured pixel written into a rule (this project has paid four times for a number read off one render and baked in; see TRAPS). EQUAL-WIDTH TABS are what make that arithmetic true in both languages without measuring either: a tab is `--gt-tabs-tab-size` wide whatever its label, so the bar lands on the same centre on /ar as on /, and Omar's Arabic labels (GAP-193) will not move it when they land. 7rem holds the widest label with air to spare (MEASURED in Inter 14px/500 with a Range over the text: Store cards 76.75px of glyphs in the tab's 100px inner box — 6px padding a side; Home 39.55, Games 46.63; بطاقات المتاجر, the proposed Arabic, 85.56px, which fits the wide tab and NOT the narrow band's 78px inner box — the request sheet says so and offers shorter words) and three of them make a 338px pill — which is why the narrow band below steps it down: at 320 the row's content box is 288. The glow is three blurred layers of the accent behind the bar — box- shadow, the same device as `--gt-media-glow-soon`, on an element that never animates (there is no motion between tabs: every page load renders the bar already in place), so the shadow is painted once and never re-rasterised. Alpha needs channels, hence `--accent-rgb` from the emitter, and hence a token: `rgba()` is banned in a component rule (SiteTokensTest) for the reason the header's own literal channels were (BUG-096's family). The blur is the pill's own backdrop, over the header's glass. MEASURED 2 Sep at 1536×960 by a pixel diff of the pill with and without it: at rest 13,850 (en) / 13,868 (ar) of 15,548 pixels differ by at least 1/255, 1,554 / 1,921 by more than 1, 91 / 96 by more than 2 and none by more than 3/255; scrolled 300px with artwork under the bar, 0 pixels differ at all. It composites over the header's own blur(12px) without a paint difference — which also means it paints nothing that blur has not already painted, and it can be dropped without a visible change. Kept as the round asked, and said plainly. */ --gt-tabs-tab-size: 7rem; --gt-tabs-bar-size: 2rem; --gt-tabs-blur: 12px; --gt-tabs-glow: 0 0 6px rgba(var(--accent-rgb), .55), 0 0 14px 2px rgba(var(--accent-rgb), .35), 0 0 26px 6px rgba(var(--accent-rgb), .18); /* BUG-037's tap minimum, as a token rather than as `44px` written into five rules. It is already quoted by four of them in site.css. */ --gt-tap-min: 44px; /* V-33 B3 — the basket line's artwork box. BOTH axes, written: a ratio cannot size an unloaded image (TRAPS), and the summary beside the line must not move when the picture lands. 2:3 — the product tile's own frame since V-20 B4, so an uploaded card face and a bundled poster are both exactly this shape and `object-fit: cover` throws nothing away; a store brand's square mark (the parent's cover, GAP-165) is cropped, as it is on the product page. The phone band below steps it down where a 390px line has a name, a stepper and a trash to fit beside it. */ --gt-cart-art-inline: 5rem; --gt-cart-art-block: 7.5rem; /* The checkbox and radio box. 18px, and the number is not free: the label beside it is `--gt-text-sm` at `--gt-leading-snug`, whose line box is 14 x 1.35 = 18.9px, so a box of 18 sits on that line with 0.45px to spare at each end and needs NO nudge — which is what the two rules this component replaces were doing with `margin-block-start: .12rem` and `.28rem`, two different magic numbers for the same job. Change the control's type step and this number has to move with it; that is why it is a token and why this comment states the arithmetic. */ --gt-check-size: 1.125rem; /* The tick and the dot inside it. A fraction of the box rather than a second measurement, so the two cannot come apart. */ --gt-check-mark: 0.625rem; /* ----------------------------------------------------------------- RADII */ --gt-radius-xs: 6px; --gt-radius-sm: 8px; --gt-radius-md: 10px; --gt-radius-lg: 14px; /* the site's existing --radius; cards */ --gt-radius-xl: 20px; --gt-radius-pill: 999px; /* -------------------------------------------------------- BORDER WEIGHTS Three, and the third is not a border in the visual sense — it is the status bar down the reading edge of a message box, which is why it is thick enough to read as a bar rather than as a heavy hairline. `--gt-hairline` is ONE DEVICE PIXEL as a primitive, and it exists because two unrelated things want exactly that and neither is spacing: the hairline border below, and the 1px box the visually-hidden recipe uses. Without it `.got-sr-only` would be the only rule in the system carrying a px literal, and the test that forbids them would need a carve-out — which is a worse outcome than naming the primitive, because a carve-out is a list and lists rot. */ --gt-hairline: 1px; --gt-border-hair: var(--gt-hairline); --gt-border-thin: 1.5px; --gt-border-bar: 3px; /* -------------------------------------------------------------- ELEVATION 🔴 THE ONE IDEA THIS SYSTEM IS BUILT AROUND, and it is worth stating plainly because every component below leans on it and a future edit that drops it will make the whole thing look flat without anybody being able to say why. ONE LIGHT SOURCE, ABOVE. Every raised surface gets a 1px inset highlight along its TOP edge and a shadow BELOW it. Nothing else. The highlight is what makes a dark card read as an object rather than as a lighter rectangle — on a #171B28 card it computes to #212532, which is a quarter of the way to the next step of the surface ladder and is why the ladder and the lift do not fight each other. A press REMOVES the lift and adds a dark wash, so a pressed control looks like it has gone into the page rather than merely changed colour. That is the entire press interaction in the system, applied identically to every control, and it is the reason the buttons, the card and the toast read as one family. */ --gt-lift: inset 0 1px 0 rgba(var(--wash-rgb), .045); /* How far a pressed control travels. A TOKEN because it is a decision about how the whole system feels, and it was written out five times before the test that forbids raw pixels found it — which is exactly the kind of thing that guard is for. One number, one place, five callers. */ --gt-press-shift: 1px; /* How far a pressed MEDIA SURFACE shrinks. The game card is a different kind of object from a button — a picture, not a control with a label — and it presses by scaling down for one instant rather than by moving into the page. Omar's decision, 17 Aug: media cards may press differently from buttons, AS A TOKEN, so the next media surface reuses this number instead of writing .978 again. Buttons and panel cards keep the shift above; nothing in the system reads both. */ --gt-press-scale: .978; --gt-shadow-0: none; --gt-shadow-1: 0 1px 2px rgba(var(--elev-rgb), .35); --gt-shadow-2: 0 4px 12px -2px rgba(var(--elev-rgb), .45); --gt-shadow-3: 0 12px 28px -6px rgba(var(--elev-rgb), .55); --gt-shadow-4: 0 24px 56px -12px rgba(var(--elev-rgb), .65); /* -------------------------------------------- THE FOUR SURFACE LEVELS (V-02) 🔴 THE RAMP ABOVE IS A VOCABULARY OF SHADOWS. THESE ARE THE FOUR ANSWERS THE SYSTEM ACTUALLY GIVES, and they exist because the composition — one light source above, so a highlight AND a shadow, never one alone — was written out by hand in TWELVE rules before this: both filled buttons at rest and on hover, the four `.got-card` weights, the stat tile, the list row, the account panel and the basket thumbnail. Twelve private answers to "how far off the page is this", and the tell is that they had picked three different N for what turned out to be one job. (The count says twelve because it was counted off the diff. The first draft of this comment said "nine" and named the toast and the sticky price bar among them — the round's verifier checked and neither was ever one: the toast is exempt on purpose, below, and `.buy`'s sticky bar has only ever carried `--gt-shadow-3` with no highlight at all. A comment stating a mechanism it has not measured is this project's named defect and it does not get a pass for being about shadows.) A level is a POSITION, not a shadow: raising the whole product by a step is now one edit here instead of nine, and the next surface joins the ladder rather than guessing an N. base flat on the page. The highlight alone — no shadow. Account panels stack several of these and a page of shadows reads as a mess; at that size the lit top edge is enough to separate a panel from the ground. elevated an object resting on the page. The default for a card. hover the same object, picked up. This is also the ACTIVE/selected level: a thing under the cursor and a thing that is chosen are the same distance off the page, and giving them two levels would mean a selected card outranks a hovered one for no reason a customer could name. featured the ONE thing on a page that IS the page. Never more than one in a viewport, the same discipline the brand gradient is held to — a page where three things are featured has featured nothing. `--gt-shadow-0` is deliberately absent from all four: `none, inset …` is not a valid box-shadow list, and a level meaning "no depth at all" is the absence of the declaration rather than a token. */ --gt-level-base: var(--gt-lift); --gt-level-elevated: var(--gt-lift), var(--gt-shadow-1); --gt-level-hover: var(--gt-lift), var(--gt-shadow-2); --gt-level-featured: var(--gt-lift), var(--gt-shadow-3); /* `--gt-tint-featured` AND `--gt-edge-featured` WERE DEFINED HERE AND ARE GONE — V-18d, 27 Aug. Their comment's own last paragraph had already said it: "one consumer each, and both are the store card's" — the edge was the square card's SEAM and the tint its FALLBACK WASH, and V-18d deleted that card wholesale (the store card is the game tile now, whose bare state is `--gt-media-placeholder` and whose edge is `__edge`). A token nothing reads is indistinguishable from one somebody forgot to wire up, so both went with their readers. The A/B history (edge .22 invisible / .45 chosen / .60 too close to the soon orange; tint .05 imperceptible / .10 the reviewer's number) lives in the V-18b round report if a featured surface is ever built again — measured against a card that no longer exists, so it would be a starting point, not an answer. */ /* ------------------------------------------------- THE FOCUS RING, IN FULL 🔴 TWO TONES, AND THE SECOND ONE IS NOT DECORATION. A plain `outline: 2px solid var(--gt-accent)` is what this site had, and it is INVISIBLE on the primary button: that button is FILLED with the accent, so the ring measures 1.00:1 against the thing it is drawn on. Measured, not assumed — it is the reason this token exists in the shape it does. The answer is a dark separator band between the control and the accent ring, so the ring always has something to be seen against: control edge | 2px --gt-surface-page | 2px --gt-accent | page `outline` draws the accent, `box-shadow` draws the dark band in the offset gap. Against the page the band is invisible (it IS the page) and the ring does the work; against the accent button the band is 11.74:1 and the ring reads off the band. One treatment, correct on every background, which is what the round asked for and what one tone cannot deliver. `outline-offset` and the ring width are tokens so a component can never invent its own ring — `.got-btn:focus-visible` and `.got-field input:focus-visible` are literally the same three declarations. */ --gt-ring-width: 2px; --gt-ring-gap: 2px; --gt-ring-color: var(--gt-accent); --gt-ring-band: var(--gt-surface-page); --gt-ring-shadow: 0 0 0 var(--gt-ring-gap) var(--gt-ring-band); } /* ------------------------------------------------- THE ARABIC PAGE'S FACE V-30 B3. `/ar` is ``, and the face is re-pointed by LANGUAGE rather than by direction because the stack is about which glyphs a font carries, not about which way the line runs. One declaration, on the root, so every reader of `--gt-family` — the body, the controls that do not inherit, the figure surfaces through `--gt-family-numeric` — follows without a second rule. `:root:lang(ar)` is (0,2,0) against the token's (0,1,0), so it wins on any page whose root says Arabic and on no other. */ :root:lang(ar) { --gt-family: var(--gt-family-arabic); } /* ------------------------------------------------ THE RING INHERITS THE STATE 🔴 A FIELD MAY NOT SAY "WRONG" AND "FINE" AT THE SAME TIME. Measured on /register: the name field showed the error dot, the sentence "Please enter your name" and a RED border — with a BLUE focus ring around it. Six combinations, three states in two languages, and the ring was `rgb(122,214,255)` in all six. The border already followed the state; only the ring did not. ============== WHY THIS IS ONE DECLARATION AND NOT THREE RULES =========== The obvious repair is three more `:focus-visible` rules, one per state. That is the shape this project has already paid for three times over with BUG-234 / BUG-239 / BUG-242 — a list of selectors that has to be widened every time somebody adds a case, and is therefore always one case behind. `--gt-ring-color` is a CUSTOM PROPERTY, and custom properties INHERIT. So a state does not restyle the ring; it says what colour rings mean inside it, and every component in that subtree picks it up. The ring rules themselves — on the button, the input, the card, the toast close, the links — are untouched and never need touching again. 🔴 A SIXTH STATE IS ONE LINE HERE AND NOTHING ELSE. `.got-field.is-pending { --gt-ring-color: var(--gt-warning) }` and every ring inside a pending field is amber, including ones written after this comment. That is the property three rounds of widening a selector never had. ================ AND ONE STATE STROKE, NOT TWO — BUG-247 ================= 🔴 A RING THE SAME COLOUR AS THE BORDER IT SURROUNDS PAINTS THE FIELD TWICE. Pixel-sampled on /register, focused, contact handle in its valid state — a 16px strip cut across the edge: card #171B28 x4 | #22C55E x2 | band #0D0F17 x2 | #22C55E x1 | fill TWO green strokes with the dark band between them. It reads as a doubled border, not as a ring, and it is the COST of the fix above rather than a defect in it: while the ring was always accent it could not match the border, so the two-tone geometry always read as two different things. The moment the ring learned the state, it could — and did. THE FIX IS THE SAME MECHANISM ONE STEP FURTHER. A state now declares ONE colour, `--gt-edge-color`, and the ring is DEFINED AS that colour: --gt-edge-color: var(--gt-success); --gt-ring-color: var(--gt-edge-color); so a state cannot recolour one stroke and forget the other — not because a test says so, but because there is only one value. And because the state no longer writes `border-color` ITSELF, the control's own `:focus-visible` rule out-specifies the edge with no source-order argument and no per-state exception: WHILE FOCUSED, THE BORDER JOINS THE BAND. rest control edge (state) | page focused control fill | 3px band | 2px ring (state) | page One state stroke either way. What tells the two apart is measured below and not left to be inferred: at rest a 1px edge hugging the control; focused a 2px stroke standing 3px off it — four times the ink, in the same colour, with a dark moat that exists in neither the rest state nor the unfocused one. 🔴 `--gt-edge-color` IS DELIBERATELY NOT DEFINED AT `:root`, and its ABSENCE is the neutral state. That is what lets ONE declaration serve both "no state" and "a state" — `var(--gt-edge-color, var(--gt-line-strong))` is the neutral edge until a state supplies one, and the same idiom gives hover and disabled their own neutral colours without any of the three needing to know which states exist. A `:root` default would make the fallback dead code, which in this project is indistinguishable from a bug. 🔴 A SIXTH STATE IS STILL TWO LINES AND NOTHING ELSE. `.got-field.is-pending { --gt-edge-color: var(--gt-warning); --gt-ring-color: var(--gt-edge-color) }` and the border, the ring, the hover edge and the disabled edge inside a pending field are all amber, including components written after this comment. THE BAND STAYS THE PAGE COLOUR on purpose. It is what separates the ring from the control, and with the border now joining it, it is 3px of the four the focused state is made of. Measured on the card (#171B28), which is the surface the ring is drawn on at `outline-offset: 2px`: accent 10.53:1, danger 4.56:1, success 7.53:1 — all clear of the 3:1 floor for a non-text indicator. Pixel-sampled off the rendered page in both languages, not computed from the two hexes. */ .got-field--error, .got-field.is-invalid, .got-input--error { --gt-edge-color: var(--gt-danger); --gt-ring-color: var(--gt-edge-color); } .got-field.is-valid { --gt-edge-color: var(--gt-success); --gt-ring-color: var(--gt-edge-color); } /* 🔴 AND THE DESTRUCTIVE BUTTON, WHICH THE GUARD FOUND AND I HAD NOT. `test_a_state_that_recolours_the_border_recolours_the_ring` named it the first time it ran: `.got-btn--destructive` paints its border `--gt-danger` and was ringing in accent — the same contradiction as the field, one component over, on a control whose whole job is to look consequential. It is fixed by EXTENDING the rule rather than excusing the button from it. Carving component variants out of the invariant would have meant a list of exceptions, which is the shape being replaced; and "a control coloured by meaning rings in that meaning" is the better rule anyway. The separator band is what keeps the ring readable against the button's own red edge — which is more work than it did when the two were never the same colour. And it doubled for the same reason the field did, on the same measurement: a red 1px border, the band, a red 2px ring. It is fixed by the same one token, which is the point — the button is not a variant carved out of the invariant, it is a control that declares a state colour, and every control that declares one is answered here. */ .got-btn--destructive { --gt-edge-color: var(--gt-danger); --gt-ring-color: var(--gt-edge-color); } :root { /* ------------------------------------------------------------------ MOTION Durations as tokens is what makes prefers-reduced-motion ONE RULE instead of one per component. site.css answers that query in five separate blocks today, each naming the classes it happens to know about, and a component added after any of them is animated for everybody. Below, the query rewrites the tokens and every transition in the system collapses at once — including ones written after the query. Falsification: delete the @media block at the bottom of this section and SiteTokensTest::test_reduced_motion_rewrites_every_duration_token goes red — its first assertion is that this block exists. */ --gt-duration-instant: 80ms; --gt-duration-fast: 140ms; --gt-duration-base: 200ms; --gt-duration-slow: 320ms; /* Standard: fast out of the gate, settles gently. Everything that moves between two resting states uses it. */ --gt-ease-standard: cubic-bezier(.2, 0, 0, 1); /* Entering: no acceleration at the start, so a thing that appears looks like it was already moving. */ --gt-ease-out: cubic-bezier(0, 0, 0, 1); /* Leaving: the reverse, so a dismissal accelerates away. */ --gt-ease-in: cubic-bezier(.3, 0, 1, 1); /* The one composite: hover and press feedback, so a component says `transition: var(--gt-transition-control)` rather than restating the property list. Restating it is how one control ends up transitioning `background` while its neighbour transitions `all`. */ --gt-transition-control: background-color var(--gt-duration-fast) var(--gt-ease-standard), border-color var(--gt-duration-fast) var(--gt-ease-standard), color var(--gt-duration-fast) var(--gt-ease-standard), box-shadow var(--gt-duration-fast) var(--gt-ease-standard), transform var(--gt-duration-instant) var(--gt-ease-standard); /* One-shot sweeps — the game card's sheen. A finite animation, not a transition, so the reduced-motion block below rewrites it like the others AND the card stops the animation itself where it is defined, because a 1ms sweep is still a flash. */ --gt-duration-sweep: 720ms; /* 🔴 THE CROP FADE — V-27 B2, the phone band's product-artwork window. A MASK, not a paint: the gift page's poster is cropped on a phone (a window anchored to the top of the card, Omar's requirement) and its lower edge dissolves into whatever the page is made of — a mask reads alpha, so the fade lands on the DARK page and the LIGHT page alike with no colour named here, where an ink-coloured overlay gradient would have painted a dark fog on the light theme (the --gt-scrim family is deliberately theme-blind, which is right ON artwork and wrong AROUND it). `black` is a keyword for the same reason --gt-mask-ring's is: a mask's colour is irrelevant and a hex near it reads as one. Vertical, so there is no direction to mirror on /ar. The stops were looked at rendered at 390 against 70%/100% and 50%/95%: 62→98 keeps the flag and the value fully solid in a 4:3 window and lets the wave dissolve rather than end at a cut. */ --gt-media-crop-fade: linear-gradient(180deg, black 62%, transparent 98%); /* -------------------------------------------- MEDIA SURFACES (hover-skill) The artwork treatment for a card whose body is a picture: the game and store-card tiles on the home grid, and whatever media tile comes next. Written as tokens rather than inside the component so a second media surface reads the same veil, the same rest and lit filters and the same lift, and so `SiteTokensTest`'s raw-value guard can hold the component itself to tokens only. These are the ONLY places in the system a gradient stop or a filter is decided. The colours are the site palette — accent, blue, cyan and the page ink, all from config/brand.php through the emitter. The hover-skill was first drafted against a purple/violet gradient; purple is RETIRED (BrandPaletteTest::RETIRED) and Omar's decision of 17 Aug is that the UI palette wins and the logo is allowed to differ. */ --gt-blue: var(--blue); --gt-cyan: var(--cyan); /* V-40: the pink the site header's hairline already draws. Aliased here for the same reason blue and cyan are — a `--gt-*` token is what the sheet is allowed to read, and `SiteTokensTest` refuses one the system does not define. */ --gt-accent-secondary: var(--accent-secondary); /* 🔴 THE ON-ARTWORK COLOURS — V-06 Batch 6, 22 Aug, AND THE REASON THEY ARE A SEPARATE FAMILY IS THE LIGHT THEME. V-06 put the title, the meta and the call to action back ON the picture, over the veil. The veil is the DARK ink in both themes (see --gt-scrim below: artwork does not get lighter because the page did), so at the FOOT of the frame a card is a dark context even on a light page — and every ordinary text token would walk straight into it and turn dark-on-dark. Measured on the rendered glyph, the title is 14.67:1 at 1536 and 15.00:1 at 390, in both themes. 🔴 AND "THE CARD IS A DARK CONTEXT" IS ONLY TRUE WHERE THE VEIL IS. It is a gradient — clear to 34%, .74 at 74%, .96 at the foot — so the answer depends on WHERE a thing sits, and the first version of this comment said it of the whole card. That cost a real defect: the TYPE MARK sits at 42% of the frame, where the veil is thin, over `--gt-media-placeholder` — so it is the one thing on this card whose polarity is decided by the PLACEHOLDER rather than by the veil, and Batch 6 pointed it at `--gt-on-ink` on the "the card is dark" generalisation and took it from 5.09:1 to 2.05:1. 🔴 AND THEN THE GROUND ITSELF MOVED, WHICH IS WHY THIS PARAGRAPH HAS NOW BEEN WRONG TWICE. Batch 6's repair was `--gt-on-accent-ink` — a DARK ink, correct against the bright gradient it was measured on. Omar's row-rhythm rule then put a .6 ink scrim into `--gt-media-placeholder`, and the ground under the mark went dark with it, so the dark ink was stranded and the mark reads `--gt-on-ink` again. Re-measured on this tree on 23 Aug, /games at 1536, the mark hidden so this is the composite alone: the ground is rgb(20,66,102), luminance .05004, IDENTICAL IN BOTH THEMES — which is the mechanism these tokens exist for, not a coincidence. A dark ink on that ground scores 1.82:1, same run. THE MARK'S OWN RENDERED-GLYPH RATIO IS NOT REPEATED HERE: it is measured and tabulated beside `.got-gamecard__initials`, and a second copy of a number is a number that can go stale on one side. So the rule these tokens exist for is NOT "the card is dark", and it is not "the mark is bright" either — that was the second wrong answer. It is: MEASURE THE GROUND WHERE THE THING SITS, choose the polarity from that, pin it here so the theme cannot move it, AND RE-MEASURE WHEN ANYTHING UNDER IT CHANGES. A colour chosen against a ground is only as current as the ground. So: `--on-accent`, `--on-accent-ink` and `--on-ink` are emitted by Brand::cssVariables() from the DARK palette's own keys and are deliberately ABSENT from its light block, which is the mechanism — a variable the light block never mentions cannot follow the theme. 🔴 AND THAT ABSENCE IS GUARDED NOW, 23 Aug — IT WAS AN UNGUARDED PHP ARRAY. Every "does not follow the page" assertion in the suite searched THIS FILE's light blocks, which is not where the value is decided: one line added to Brand::lightBlock()'s map painted this mark the light palette's own near-black, rgb(20,26,38), on a light page — with the whole suite green and nothing anywhere able to say so. `GameCardTest::test_the_on_ artwork_family_is_emitted_once_and_the_light_theme_never_names_it` derives the `--on-*` set from the emitter, pins it for exactness, and asserts the light block names none of it — and closes the naming convention from the other side by requiring every `--gt-on-*` alias below to read a member of that set. WHAT IS NOT HERE AND WHY. The round's brief also asked for `--on-soon`. `--soon` is ALREADY theme-independent — the light block does not override it either — so `--on-soon` would be a second name for a variable that already never follows the page, which is the second-copy shape this file exists to refuse. The soon treatment goes on reading `--gt-soon` and `--gt-tint-soon`, unchanged. */ --gt-on-accent: var(--on-accent); --gt-on-accent-ink: var(--on-accent-ink); --gt-on-ink: var(--on-ink); /* 🔴 `--gt-on-warning` / `--gt-on-muted` AND THEIR TWO TINTS ARE DELETED — V-21 B2, 28 Aug. They existed for exactly one reader: the card-meta stock pill, pinned to the dark palette's values because it sat ON THE ARTWORK (V-18d's Critical — the theme-following amber measured 1.90:1 there). V-21 B2 moved the product card's words, pill included, onto the CARD SURFACE — which the theme paints — so the pill wears the ordinary theme-scoped `.got-pill--muted` treatment again and the pinned family would now be the ORIGINAL BUG IN REVERSE: a dark-palette amber fixed onto a light card. Deleted with their emitter lines (Brand.php) and their four component rules, not orphaned: a token nothing reads is indistinguishable from a token somebody forgot to wire up. StoreSectionsTest holds the absence. */ /* The signature gradient: accent → blue → cyan, at the diagonal the edge ring wants. (It used to say "the same three stops the site's own headline gradient uses"; that gradient was deleted in V-06 Batch 5 — see the note below — and a comment naming a caller goes stale the day one is removed just as surely as the day one is added.) Diagonal on purpose: a horizontal gradient does not mirror and needs a rule per caller (CLAUDE.md); a ring's diagonal reads the same in both directions and is checked rendered in both. */ --gt-gradient-brand: linear-gradient(125deg, var(--gt-accent-soft), var(--gt-blue) 45%, var(--gt-cyan)); /* 🔴 THE EDGE RAMP — V-40. `--gt-gradient-brand` above is the signature fill (accent-soft -> blue -> cyan at 125deg) and it carries no pink; the site header's own hairline draws blue -> cyan -> PINK and fades at both ends, and Study D asks for that ramp on the top-up card's top edge. It is a TOKEN rather than a second copy of the header's rule, because `site.css`'s `.site-header::after` writes that ramp as an inline literal and a third spelling of one gradient is how a palette becomes three. The header still carries its literal — converting it is a change to a guarded rule and is filed rather than smuggled in here. */ --gt-gradient-edge: linear-gradient(90deg, transparent, var(--gt-blue) 16%, var(--gt-accent) 40%, var(--gt-accent-secondary) 74%, transparent); --gt-gradient-edge-rtl: linear-gradient(270deg, transparent, var(--gt-blue) 16%, var(--gt-accent) 40%, var(--gt-accent-secondary) 74%, transparent); /* 🔴 `--gt-gradient-headline` WAS DEFINED HERE AND IN BOTH LIGHT BLOCKS, AND ALL THREE ARE GONE — V-06 Batch 5, 22 Aug. It had exactly one reader, `.hero h1 .grad`, and the hero's accent half is a flat `--accent` now: three lines of gradient survive a batch that deleted their only caller and nothing goes red, because no test names a token. Its argument — that a gradient painting TEXT needs different stops from one painting an EDGE, since `accent-soft → blue → cyan` measures 1.5:1 and 2.2:1 on a light page — was right, and the reason to keep it written down is that the next gradient somebody puts on type will need it again. `--gt-gradient-brand` below is untouched: it paints an edge and a placeholder, both over artwork, in both themes. */ /* 🔴 REST AND LIT — AND THE ARTWORK IS NO LONGER HELD BACK AT REST (V-05 Batch 1, 22 Aug, Omar's numbers). It used to be `--gt-media-dim: grayscale(38%) brightness(.62)`, on the argument written here for a week: hold the colour back so hover has somewhere to go. MEASURED ON THE RENDERED GRID, that argument buys one thing and costs another, and the trade is bad. What it costs is the page: seven posters at 62% brightness and 38% grey read as a page that has not finished loading, and the artwork — the thing this storefront is selling with — is the part being suppressed. What it buys is a hover reward on ONE tile at a time, on a pointer device, which nobody on a phone ever sees. So rest is now essentially the picture as shot: full saturation, a whisper under full brightness so the words on the card still win the page, and a touch of contrast. Hover is a RESTRAINED STEP UP from that rather than a reveal of something withheld. `--gt-media-dim` is GONE rather than retuned, and the rename is the point: the token said what it did, and what it does now is the opposite. A `--gt-media-dim` holding a value that dims nothing is how the next author writes a dimming rule and cannot find where it went. 🔴 AND `--gt-media-dim-touch` IS GONE WITH IT, WHICH IS A DELETION AND NOT AN OVERSIGHT. It existed to say "on a phone there is no hover, so hold the artwork back LESS than on a pointer" — a second, softer answer to a question that only had to be asked while rest was dark. Rest is the picture now, in every input mode, so the touch value would be a rule that makes a phone WORSE than a laptop for no reason anybody could state. The whole `@media (hover: none)` block in the component went with it; the direction is "no desaturation anywhere at rest, on any card, in any state except --soon", and a touch screen at rest is a rest state. (That block came BACK in V-06, with different content and for a different reason — see `--gt-media-touch` immediately below and the component's own touch block. This paragraph is left in the past tense rather than deleted: the deletion was right about the card it was describing, and the card changed.) 🔴 AND V-06 PUT `--gt-media-dim-touch`'S JOB BACK, UNDER A NEW NAME AND FOR THE OPPOSITE REASON. `--gt-media-touch` is NOT the deleted token returning: that one held the artwork BACK on a phone because rest was dark and there was no hover to give the colour back. It was born when V-06 hid the CTA until hover, so a hoverless screen needed the revealed state handed to it; V-13 Batch 5 then made the capsule rest-visible on EVERY pointer, and what this token hands a phone now is the COMPLETED state — full capsule opacity, because there is no hover to complete the reward with — with the artwork settled a whisper so the capsule reads over it. Reference's own value; the deletion argument in this comment stands for the state it was written about. */ --gt-media-rest: grayscale(0%) brightness(1) contrast(1.02); --gt-media-lit: grayscale(0%) brightness(1.06) contrast(1.06) saturate(1.04); --gt-media-touch: grayscale(0%) brightness(.94) contrast(1.03); /* Coming soon: dimmed HARDER than idle and it never lights — the tile is not a control, and the dim says so before the badge does. 🔴 IT IS NO LONGER A GREYSCALE (V-06). It was `grayscale(70%) brightness(.45)`, which was right while the tile was a poster with the words underneath: the picture could be drained without draining anything else. The words sit ON it now, so draining the picture drains the ground the title and the badge are read against, and .45 under a .74 veil is a black rectangle with an orange pill on it. The direction is unchanged — a soon tile is visibly not a control — and it is now carried by BRIGHTNESS ALONE at the reference's .80, which keeps the artwork recognisable and keeps the orange the thing that says why. */ --gt-media-dim-soon: grayscale(0%) brightness(.80) contrast(1.03) saturate(.92); /* The placeholder behind a tile with no artwork of its own: the system's gradient, nobody else's picture. GAP-095 covers the real art. 🔴 ITS BRIGHTNESS IS A MEASURED RULE NOW, NOT A TASTE CALL — Omar, 23 Aug: "the fallback's mean luminance must sit inside the range of the real tiles at rest, never outside it. A placeholder that reads brighter or darker than every real card breaks the row rhythm, which is the one thing a fallback must never do." IT WAS THE BRIGHTEST OBJECT ON THE PAGE. Measured on the rendered /games at 1536, dark, settled, dsf 1 — mean WCAG relative luminance over each tile's whole `__media` box, sampled from the SCREENSHOT so every alpha layer (veil, scanlines, sheen, the filter) is flattened by the compositor rather than by arithmetic: fc27 .02512 · call-of-duty .05887 · dota-2 .06189 · clash-royale .08136 · valorant .08681 <- the five live artwork tiles, min to max gta-vi .09151 <- artwork under the coming-soon brightness(.80) ROCKET LEAGUE .24456 <- the fallback: 2.82x the brightest real tile THE RANGE IS THE FIVE LIVE TILES, and the coming-soon tile is reported beside it rather than counted in it: its dim is a SIGNAL that the tile is not a control, so a fallback landed against it would read "unavailable". It makes no difference to the answer here — .09151 is the wider ceiling and the landing sits well inside both. 🔴 AND THE HEADLINE FIGURE IS MILDLY CIRCULAR — SAID HERE BECAUSE AN INSTRUMENT THAT REPORTS ITS OWN LIMIT IS WORTH MORE THAN ONE THAT IS NEVER WRONG. The fallback's `__media` box contains THE MARK, so .05538 is a reading of the material PLUS the ink this alpha is being used to justify. Re-run on this tree on 23 Aug, same box, same instrument, three arms: .05538 as it ships, with the light mark on it <- the headline figure .05234 the same box with the mark hidden <- material alone .05207 the same box with the mark forced dark So the ink moves the reading by .00331, which is 5% of the live range's own width (.02542 to .08681 in that run, .06139 wide), and ALL THREE ARMS LAND INSIDE THE RANGE. The circularity is real and it does not reach the conclusion — but a figure that includes its own subject should say so rather than be quoted as though it did not. (Those four numbers are from one run and are comparable to each other; they are not comparable to the table above, which is a different run — fc27 read .02542 there against .02512 here.) 🔴 AND THE ALPHA IS A FUNCTION OF TODAY'S CATALOGUE, WHICH NOTHING RE-MEASURES. The ceiling is valorant at .08681 and the floor is fc27; five live covers decide both. Bundle one brighter poster and the range widens upwards with the fallback standing still — the landing stops being central, and far enough it could re-open the dark-ink option this token's own arithmetic closed. `GameCardTest` pins the .6 so a change to the ALPHA asks who re-measured; NOTHING asks when the RANGE moves, because no PHP test can sample a pixel. Adding artwork to `public/brand/games` is therefore a re-measurement job, and this paragraph is the only thing that says so. THE NUMBER. The scrim is ONE alpha and it is derived, not picked: .60 puts the fallback at .05538 against a range midpoint of .05596 — 0.0006 out. Sampling only the top 55% instead (the artwork above the veil's .74 stop, the same window applied to all seven) says the same thing from a different window: .07633 against a midpoint of .07778. Two windows, one alpha, and the choice between them does not move it. A FLAT FILL AND NOT A SHAPE: two identical stops, so the angle is inert and there is no direction to mirror on /ar. It reads `--gt-scrim` — the dark ink, in both themes — for the same reason the veil does: this material sits where artwork would, and artwork does not lighten because the page did. 🔴 AND THE LIGHT THEME READS .05636, NOT .05538, WHICH IS NOT THIS TOKEN FOLLOWING THE PAGE. Every tile on the row moves by the same ~.00098 — call-of-duty .05887 -> .05981, fc27 .02512 -> .02607, valorant .08681 -> .08775 — including the six that are photographs and cannot be affected by this declaration at all. It is the card's own surface showing at the rounded corners of the sampled box, and the range moves with the fallback, so the verdict is INSIDE in both themes. Written down rather than rounded away: a comment claiming two numbers are identical when they differ in the fourth place is the kind of tidying that hides a real theme dependency the next time there is one. (The mark's contrast on this ground is in the type tile's own block; this alpha is what decides it.) */ --gt-media-placeholder: linear-gradient(180deg, rgba(var(--gt-scrim), .6), rgba(var(--gt-scrim), .6)), linear-gradient(160deg, var(--gt-accent-soft), var(--gt-blue) 45%, var(--gt-cyan)); /* The image's three sizes, and how far the card lifts — ALL RETUNED DOWN (V-05 Batch 1). The old set was a 6px lift and a 9% zoom, which is a large movement to put under a cursor on a grid where four tiles are within a few hundred pixels of each other; with the artwork already at full colour at rest, the hover no longer has to announce itself that loudly to be felt. REST IS EXACTLY 1 NOW, not a hair over. The 1.01 was there so the un-zoom back from hover never showed the frame's edge through a sub-pixel gap — a real problem at a 9% zoom, and one that a 3% zoom on an `object-fit: cover` image does not have. It also cost a permanent 1% crop of every poster for a defect that only ever appeared mid-transition. 🔴 PRESS IS DERIVED, NOT PICKED, AND IT HAD TO MOVE OR THE PRESS WOULD HAVE INVERTED. The old three were 1.01 / 1.09 / 1.05 — press sits EXACTLY halfway between rest and hover, so a pressed card eases back towards its resting size while the card itself shrinks. Left at 1.05 against a hover of 1.03, pressing a card would have zoomed the artwork FURTHER IN than hovering it, which is the opposite of a press. The midpoint of 1 and 1.03 is 1.015, and that is what this is. 🔴 V-06 RETUNED ALL FOUR BACK UP, AND THE PRESS IS STILL DERIVED. The card is the artwork now — there is no body under it competing for the eye — so a 3% zoom on a poster that fills the whole tile is a movement you have to look for. The reference's numbers are a 6px lift and a 6% zoom over a rest that sits a hair over 1 (1.005, which is `cover`'s own insurance against a sub-pixel gap at the frame's edge appearing while the zoom eases back — the defect the old 1.01 existed for, at a zoom large enough to have it again). PRESS IS THE MIDPOINT OF REST AND HOVER, as it has been since V-05, and it MOVED because they did: (1.005 + 1.06) / 2 = 1.0325. Leaving it at 1.015 would have put a pressed card BELOW its resting zoom, which is a press that pulls the picture away from the finger. The rule is the arithmetic, not the number. */ --gt-media-zoom-rest: 1.005; --gt-media-zoom: 1.06; --gt-media-zoom-press: 1.0325; --gt-media-lift: 6px; /* A LIST row lifts less than a poster: two pixels, the same idea. */ --gt-list-lift: 2px; /* 🔴 THE VEIL CARRIES CONTRAST AGAIN — V-06, 22 Aug, and this is the third time this token has changed job in a week, so both earlier states are kept rather than overwritten. Before V-02 it made TEXT LEGIBLE: the words were on the picture, so the ink reached .96 at the foot and started climbing at 30%. V-02 moved the words onto a card under the frame, the veil stopped carrying any contrast, and it shrank to "transparent to 58%, .48 at the foot" — a grounding, plus an accent wash that tied a photograph to the palette. V-06 PUT THE WORDS BACK ON THE PICTURE, so the contrast job is back and the small gradient cannot do it. These are the reference's stops: clear to 34%, .74 at 74%, .96 at the foot. What the reference does NOT have is the accent wash, and it is deleted here rather than kept: a coloured wash over text is a second variable in every contrast measurement taken on this card, and the veil is the one thing standing between a title and an arbitrary photograph. The wash SURVIVES on the soon tile below, where the colour is the message rather than a decoration. THE NUMBERS THIS BUYS, as arithmetic against the WORST CASE — a pure white frame under the veil, which is the brightest ground any artwork can put behind the words: veil .96 (the foot) title 14.22:1 meta 8.63:1 accent 10.81:1 veil .74 (the 74% stop) title 6.77:1 meta 4.71:1 accent 5.15:1 Every one clears AA, including the meta at its own worst point. This is ARITHMETIC on a flattened composite, not a pixel sample: the sample on the rendered grid is the verifier's, and it is the one that counts. Alpha needs channels, which is why it reads --gt-scrim rather than a hex token. */ /* 🔴 THE SCRIM IS THE DARK INK IN BOTH THEMES, AND IT HAD TO STOP READING THE PAGE'S. `--got-ink` is the rgb triple of the PAGE, and the veil used it because on a dark site those are the same colour. They are not the same colour on a light one: a light page would have painted a WHITE scrim over every poster, which is a fog, not a grounding. Artwork does not get lighter because the page did. `--got-ink` is emitted from `brand.ink` and the light block deliberately does not override it, so this is one value in one place and the light theme simply never touches it. */ --gt-scrim: var(--got-ink); --gt-media-veil: linear-gradient(180deg, rgba(var(--gt-scrim), 0) 34%, rgba(var(--gt-scrim), .74) 74%, rgba(var(--gt-scrim), .96) 100%); /* The soon tile's veil: the same three ink stops, and the wash that the live tile just lost — the soon orange (19 Aug). It stays here for the reason it was deleted there: on this tile the colour IS the message, and the only words it has to carry are a title and a badge that is itself that colour. */ --gt-media-veil-soon: linear-gradient(180deg, rgba(var(--gt-scrim), 0) 34%, rgba(var(--gt-scrim), .74) 74%, rgba(var(--gt-scrim), .96) 100%), linear-gradient(200deg, rgba(var(--soon-rgb), .26), transparent 50%); /* The soon tile's DECORATIVE hover: a soft orange edge glow, opacity only. INSET, because the tile clips its overflow (the artwork's frame) and an outer glow would never be seen — measured: only the 1px ring survived. */ --gt-media-glow-soon: inset 0 0 0 1px rgba(var(--soon-rgb), .70), inset 0 0 32px 4px rgba(var(--soon-rgb), .32); /* The scanline texture — the "gaming" garnish. The layer's OPACITY is folded into the gradient stop, so the component never dims itself with `opacity`, which SiteTokensTest forbids for a reason (BUG-241: opacity fades text and fill together, so a measured contrast stops being the figure on screen). The pitch — one line every 3px — is a fact about the texture and lives here with the other raw values. V-06 states its layer opacities as .14 at rest and .22 lit, so the fold is white .10 x .14 = .014 and white .10 x .22 = .022. The fold is arithmetic on the two numbers the reference writes, and it is written out here because the folded value is the one nobody can read back. */ --gt-media-scanline: repeating-linear-gradient(0deg, rgba(255, 255, 255, .014) 0 1px, transparent 1px 3px); --gt-media-scanline-lit: repeating-linear-gradient(0deg, rgba(255, 255, 255, .022) 0 1px, transparent 1px 3px); /* The one-shot light sweep. White then cyan, so it reads as light and not as a tint — and the cyan is the ON-ARTWORK accent, not the page's. It read `--accent-rgb` until V-06, which the light block DOES override: on a light page the sweep across a poster would have been the dark teal `accent_on_light`, over dark artwork. The same defect the veil's scrim was fixed for, one layer up. */ --gt-media-sheen: linear-gradient(90deg, transparent, rgba(255, 255, 255, .16) 45%, rgba(var(--on-accent-rgb), .30) 55%, transparent); /* 🔴 THERE IS NO HOVER-GLOW TOKEN, AND ITS ABSENCE IS A RULING RATHER THAN AN OMISSION. The V-06 study gives the hovered card a `0 22px 48px -18px` blue throw and a cyan hairline, and this block did carry a `--gt-media-glow` for about an hour. Omar's resolution #8 of 17 Aug, re-ruled on 22 Aug against V-06's own reference, is quoted in full at the hover rule in the component below and says in part: "the hairline border under it never changes; no lift shadow." So the token was DELETED rather than left defined and unused — a value nothing reads is indistinguishable from a value somebody forgot to wire up, and the next author would wire it up. The lift is `transform` alone; the reward is the edge, the sheen, the zoom and the capsule. */ /* 🔴 THE CALL TO ACTION, ON THE ARTWORK — V-06 Batch 3, the CAPSULE. A compact pill: the on-artwork accent on its own tint at rest, solid with ink words on hover and focus. The reference offers four treatments behind a `data-cta` switch on its wrapper; three of them are prototype comparisons and only the capsule ships, unconditionally, so there is no attribute selector here and no `bar`/`underline`/`glass` to inherit. Arithmetic on the worst case (white artwork, .96 veil): the accent on its own .13 tint is 8.14:1, and the ink on the solid fill is 11.53:1. The .42 border against that tint is 2.21:1 — it is a decoration inside a control whose real boundary is the fill, not the control's only boundary, so WCAG 1.4.11's 3:1 is not the figure that applies to it. */ --gt-media-cta-fill: rgba(var(--on-accent-rgb), .13); --gt-media-cta-line: rgba(var(--on-accent-rgb), .42); /* V-13 Batch 5 (Omar, 24 Aug): the capsule is PRESENT AT REST on every pointer — quieter on a hover-capable one, full on touch — so the rise token that revealed it is gone (deleted, not orphaned: zero readers, and its reduced-motion handling went with it). This is the capsule's resting weight; hover takes it to 1, which is what keeps hover a REWARD rather than a reveal. Measured at rest on the rendered /games grid at .72, label vs the capsule's own sampled ground, 24 Aug: CoD 5.44, FC27 5.09 (the worst), Valorant 5.50, Dota 5.44, Clash 5.28, Rocket League (type tile) 5.25 — identical in both themes, because the capsule sits on artwork and artwork does not follow the page. */ --gt-media-cta-rest: .72; /* The arrow's nudge. `translateX()` is physical and has no logical form, so like --gt-sweep-to it is a custom property the [dir] rule flips — and unlike --gt-sweep-to it needs a SECOND token to flip TO, because a component rule may not carry a raw `-3px` (SiteTokensTest's px ban reaches every property, and the sweep only escapes it by being a percentage). Both values live here, where raw values belong. */ --gt-media-arrow-nudge: 3px; --gt-media-arrow-nudge-rtl: -3px; /* 🔴 THE TILE TITLE IS ITS OWN SIZE NOW, AND IT IS A TOKEN BECAUSE A MEDIA QUERY MUST REWRITE IT RATHER THAN RESTATE THE RULE (V-06 Batch 3). Until V-06 the tile head and the card head were ONE ROLE at --gt-text-lg / --gt-weight-heavy, asserted by TypeRegisterTest, and that was right while both were words on a card's own surface. The tile head is now printed ON the artwork, uppercase, leaning, one line with an ellipsis, and it scales with the tile — because the text sits on the picture, a bigger title costs no card height at all, which is the whole reason the reference lets it move. The card head is untouched. Three steps, the reference's: 16/20 on a phone, 17/21 from 700px, 18/22 from 1200px. 17px is not a step of the type scale and is not being added to it — this is ONE component's own size, declared once, and the two breakpoints below rewrite the token rather than repeating the rule. That is the shape CLAUDE.md asks for after the reduced-motion list-of-classes lesson: put the value in a token and let the query move the token. */ --gt-text-tile: 1rem; --gt-leading-tile: 1.25; /* The meta line under the title: 12px, the micro-label's size but not its treatment, at .76 of the on-artwork ink. Its own token because a raw rgba() may not appear in a component rule. */ --gt-media-meta: rgba(var(--on-ink-rgb), .76); /* A ring mask: paints the padding box and cuts the content box out of it, so a gradient background becomes a gradient BORDER that can fade. The colour is irrelevant — a mask reads alpha — and is written as a keyword so no hex appears anywhere near it. */ --gt-mask-ring: linear-gradient(black 0 0) content-box, linear-gradient(black 0 0); /* Text over artwork needs a shadow to survive a bright frame; the two text-shadows in the system, and both are ink, not black. The first is the TYPE MARK's — a large soft halo behind a 36px letter form standing on an ungoverned gradient. The second is the CAPTION's, and V-06 is what needed it: a tight 1px offset under the title and the meta, which is a different job (an edge, not a halo) at a size where a 14px blur would smear. The reference writes .45 for the title and .40 for the meta; that is one value written twice — the two are 2.5% apart on an alpha that exists to break a tie against unknown pixels — so it is ONE token here and both read it. */ --gt-media-text-shadow: 0 2px 14px rgba(var(--gt-scrim), .7); --gt-media-caption-shadow: 0 1px 2px rgba(var(--gt-scrim), .45); } /* THE TILE TITLE'S TWO BREAKPOINTS. Plain media queries and not container queries: the reference is written inside a 1536px `.frame` that declares `container-type: inline-size`, and production has no such wrapper — the catalogue is the full width of the page, so the viewport IS the container and a media query is the honest instrument. (CLAUDE.md's warning about media queries is about a PANEL widget inside a sidebar, which this is not.) The token moves; the rule below never does. */ @media (min-width: 700px) { :root { --gt-text-tile: 1.0625rem; --gt-leading-tile: 1.235; } } @media (min-width: 1200px) { :root { --gt-text-tile: 1.125rem; --gt-leading-tile: 1.222; } } /* THE PRICE STEP'S ONE BREAKPOINT — V-27 B2. Same shape as the tile's two above; the argument for the pair (Omar's 40/32, verbatim) is on the token. 56.25em and not 700px/1200px because that is the band the gift page's own layout already turns on — the price and the two-column grid move together or the phone bar shows a desktop size for the last few pixels before the columns arrive. */ @media (min-width: 56.25em) { :root { --gt-text-price: 2.5rem; /* 40px */ } } /* 🔴 THE REDUCED-MOTION BRANCH — ONE BLOCK, WHOLE SYSTEM. It rewrites the DURATION TOKENS rather than setting `transition:none` on a list of classes, so it covers every component in this file and every one added to it later. That is the property a list cannot have. 1ms and not 0: a zero-duration transition never fires `transitionend`, and 0.01ms is the widely-copied value for exactly that reason. Nothing in this system listens for that event today — the animation-driven parts are the loading ring and the toast — but a duration of 1ms is indistinguishable to a human and leaves the event intact for whatever comes next. The loading ring's SPIN is stopped separately where it is defined, because a spinner is not a transition and shortening its duration would make it a strobe. This block rewrites the duration tokens, so it reaches whatever reads them; an `animation` with its own duration does not read them and is not reached here. */ @media (prefers-reduced-motion: reduce) { :root { --gt-duration-instant: 1ms; --gt-duration-fast: 1ms; --gt-duration-base: 1ms; --gt-duration-slow: 1ms; --gt-duration-sweep: 1ms; } } /* Below the header's breakpoint the row is one line — brand, ☰, basket, balance, account (Batch 2) — AND, SINCE V-30 B5, A SECOND LINE UNDER IT holding the pill navigation, because the first line was already full: decision #3's ladder (V-30_BLOCKED.md) was walked on the rendered page at 390×844 and stopped at its step 5. MEASURED, both languages, signed out and in, hover:none true (B5_nav/README.md): three text tabs on the first line overflow it by 192–264px; three 44px icon pills still overflow it by 24px for an English guest (39 with a 15px scrollbar) and 52–60px signed in; the balance off the row leaves the guest row as full and the signed-in row 9px clear (0.06 over with the scrollbar); the language pair is not on this row to compact. So this band's token is its own number, not the wide row's: two lines of 44px targets, the pill's hairline top and bottom, the row's 8px padding above and below and the 8px gap between the lines — 8 + 44 + 8 + 46 + 8 = 114 of content under a `min-block-size` of 7.25rem − 1px = 115, so the TOKEN binds by one pixel and the header's border-box is the token: MEASURED 116.00 at 390×844, both languages, signed out and in (the row 115.00; the first line's targets at y 9.5, the pill's line at 60.75). The offset derives exactly as it does above (it was the literal 5rem — 80 over a 61px bar — until V-30 B4) and is 136 on the phone now; the toast and the skip link's landing follow it. One consequence of the wrap, measured and accepted: a DESKTOP browser 320 wide with a 15px scrollbar and a signed-in row (273.7 of content in a 273 box) folds the account cluster onto a third line — 167px — where the brand used to give the 0.7px; a phone at 320 has 288 and does not wrap, and a desktop window cannot be made that narrow (INFERRED, not measured here). 52em is the header's own line, drawn in THE HEADER MENUS. */ @media (max-width: 52em) { :root { --gt-header-height: 7.25rem; --gt-scroll-offset: calc(var(--gt-header-height) + var(--gt-space-6)); } } /* V-33 B3 — the basket line's artwork steps down on a phone (see the token for why both axes are written). 32.5em = 520px, the band the header's `.container--shelf` already uses for its narrowest padding. */ @media (max-width: 32.5em) { :root { --gt-cart-art-inline: 4rem; --gt-cart-art-block: 6rem; } } /* The pill's tabs step down where three of them would not fit the row: at 320 the row's content box is 288 — 273 in a desktop browser with a 15px classic scrollbar — and three 7rem tabs are 338. 5.625rem × 3 + the pill's two hairlines = 272, under both. 24em (384px) is the line: above it the phone row keeps the 7rem tab — MEASURED at 390: 338 in 358, and 338 in 343 with the scrollbar. MEASURED below the line, both languages: 375, 360 and 320 (phone) render 90px tabs, a 272px pill, no document overflow; a desktop viewport 320 wide with the scrollbar holds 272 in 273. The 2px document overflow that viewport does show (307/305) is the home page's card grid, present with the pill hidden — not the header's. */ @media (max-width: 24em) { :root { --gt-tabs-tab-size: 5.625rem; } } /* 🔴 THE PHONE'S OWN VEIL IS DELETED HERE — V-06, and it is a DELETION rather than a retune because all three of its reasons had stopped being true and the last one was doing measurable harm. It read, at `@media (max-width: 40em)`: --gt-media-veil: linear-gradient(180deg, rgba(var(--got-ink), 0) 18%, rgba(var(--got-ink), .78) 62%, rgba(var(--got-ink), .96) 100%), linear-gradient(200deg, rgba(var(--accent-rgb), .20), transparent 46%); and its comment argued: "At 4:3 the body sits higher on the frame than at 3:4, on a part of the veil that has less ink under it." · THE PREMISE IS GONE TWICE OVER. V-02 made the tile 2:3 at EVERY width — there is no 4:3 phone tile for a body to sit high on — and V-06 moved the body ONTO the artwork, anchored to the foot in every viewport. The comment described a layout two rounds dead. · IT CARRIED THE ACCENT WASH V-06 DELETED, at a HEAVIER .20, and it read `--accent-rgb`, which the light block DOES override. So the wash the live veil dropped survived on phones only, in the one theme nobody tests, painting the light palette's dark teal over a poster. That is BUG-096's family exactly — an override that only fires where nobody looks — and it is the defect Batch 6 exists to close, still breathing behind a breakpoint. · IT SPELLED THE SCRIM `--got-ink` INSTEAD OF `--gt-scrim`, so the one decision "the scrim is the dark ink in both themes" had two spellings and only one was findable by grepping the token. AND IT WAS WHY NO SINGLE MARK COLOUR COULD WORK. Measured with the mark hidden, the ground under it: at 1536 rgb(33,142,217), luminance .2468; at 390 WITH this override, rgb(25,96,149), luminance .1074. The ground crossed the light/dark threshold between two widths of the SAME card, so no single mark colour could clear AA large at both — measured on the rendered glyph with the override in place, the light mark read 2.05 at 1536 and 1.80 at 390, and the dark mark read 5.43 and 2.86. With the override gone the phone reads the same veil as every other width, the crossover goes with it, and the dark mark reads 5.43 / 5.11. THE COST OF DELETING IT WAS MEASURED, NOT ASSUMED: this veil was buying the title 0.14 of contrast at 390 (15.14 → 15.00) and the meta 0.01 (9.16 → 9.15), and costing the mark 3.31. The full before/after for all four elements is beside `.got-gamecard__initials`. */ /* ========================================================================== 1b · LIGHT MODE — the four things a palette swap cannot fix (V-02, 22 Aug) ========================================================================== 🔴 DARK IS PRIMARY. Everything above is the dark theme and none of it moved. `config/brand.php` carries a `light` block and `Brand::cssVariables()` prints it into the page, so every one of the forty-odd `--gt-*` COLOUR tokens above follows the palette without a line here — that is what makes a second theme tractable at all, and it is the whole payoff of the alias rule (`SiteTokensTest::test_every_colour_token_reads_from_the_brand_source`). FOUR TOKENS ARE NOT COLOURS THOUGH. They are DARK-MODE ASSUMPTIONS written as values, and a palette swap leaves every one of them wrong: --gt-wash-soft / --gt-wash-strong WHITE at 4% and 7% — "the surface plus light". Light on light is invisible. --gt-lift a white INSET HIGHLIGHT along the top edge. White cannot be lit further. --gt-press black at 18% — far too heavy a bruise on a white control. --gt-shadow-1..4 black at 35-65%, tuned against a near-black ground where a shadow has to fight to be seen at all. THE LIGHT SOURCE IS STILL ABOVE and that is what keeps this a designed equivalent rather than an inversion. What changes is which half of the cue carries it: on a dark ground a raised surface is LIT along its top edge and the shadow is almost decorative; on a light ground it is the SHADOW that separates the card and there is no highlight to give. So `--gt-lift` becomes a whisper of a drop shadow rather than an inset — `--gt-level-base` stays meaningful, `.got-card--panel` still reads as an object, and no rule below had to change. The selectors are the emitter's, for the same two reasons: the media query carries `:not([data-theme="dark"])` so an explicit dark choice can beat the system, and the attribute block is (0,1,1) so an explicit light choice beats the dark defaults outright. WHAT IS DELIBERATELY NOT THEMED, and it is the same list either way: the media surfaces. `--gt-media-veil`, `--gt-media-scanline`, `--gt-media-sheen`, `--gt-media-placeholder` and `--gt-media-text-shadow` all sit ON ARTWORK, and artwork does not get lighter because the page did — which is why the veil now reads `--gt-scrim` (the dark ink, in both themes) instead of the page's own. 🔴 AND THAT SENTENCE WAS FALSE WHEN IT WAS FIRST WRITTEN, which the round's verifier proved rather than argued. `--gt-media-placeholder` and `--gt-gradient-brand` both read `--gt-accent-soft`, and the light block was overriding `--accent-2` underneath it — so the "not themed" gradients were being themed, and a game with no cover started its gradient at a dark teal on a light page. The fix is upstream of this list: `--gt-accent-soft` is an artwork colour and is no longer overridden, and the button hover that wanted a darker step got `--gt-accent-hover` of its own. A comment stating a mechanism it has not measured is the defect this file names most often. ========================================================================== */ @media (prefers-color-scheme: light) { :root:not([data-theme="dark"]) { --gt-accent-hover: var(--gt-accent-strong); /* The module surface: the light ladder's top step is `raised` (white) and `overlay` is the hover wash below the page — the argument is on the alias in the token block. */ --gt-surface-module: var(--gt-surface-raised); /* 🔴 ONLY THE ALPHAS AND THE LIFT'S SHAPE. The COLOURS come from the emitter — `--wash-rgb` and `--elev-rgb` are white and black on dark and the light palette's own ink on light — so there is ONE ramp with two sets of alphas rather than two ramps that can drift. The first version of this block wrote `rgba(20, 26, 38, …)` eight times, which is the light ink as a literal in a stylesheet: the exact thing this system forbids, added by the round that was building the theme. */ --gt-press: rgba(var(--elev-rgb), .08); --gt-shadow-1: 0 1px 2px rgba(var(--elev-rgb), .07); --gt-shadow-2: 0 4px 12px -2px rgba(var(--elev-rgb), .10); --gt-shadow-3: 0 12px 28px -6px rgba(var(--elev-rgb), .14); --gt-shadow-4: 0 24px 56px -12px rgba(var(--elev-rgb), .18); /* No highlight to give on white: the shadow is the whole cue, so the lift stops being an INSET and becomes the faintest drop. Same light source, same "above" — the other half of the cue carries it. */ --gt-lift: 0 1px 1px rgba(var(--elev-rgb), .05); } } :root[data-theme="light"] { --gt-accent-hover: var(--gt-accent-strong); --gt-surface-module: var(--gt-surface-raised); --gt-press: rgba(var(--elev-rgb), .08); --gt-shadow-1: 0 1px 2px rgba(var(--elev-rgb), .07); --gt-shadow-2: 0 4px 12px -2px rgba(var(--elev-rgb), .10); --gt-shadow-3: 0 12px 28px -6px rgba(var(--elev-rgb), .14); --gt-shadow-4: 0 24px 56px -12px rgba(var(--elev-rgb), .18); --gt-lift: 0 1px 1px rgba(var(--elev-rgb), .05); } /* ========================================================================== 2 · COMPONENTS Every rule below consumes tokens and nothing else. No hex, no px font size, no px spacing — `SiteTokensTest` asserts that by parsing this section. The permitted px exceptions are the token definitions above (radii, border weights, the tap minimum), and they are above the boundary the test uses. ========================================================================== */ /* --------------------------------------------------------------- BUTTONS --- FOUR KINDS, FIVE STATES EACH, and the states are real rather than a hover filter. `filter: brightness(1.06)` is what this site had on every button: one declaration standing in for four different hover treatments, which is why the quiet button's hover was invisible (brightening a transparent background brightens nothing). primary — the one action on the screen. Accent fill, dark text. secondary — a real alternative. Bordered, surface fill. quiet — a minor action beside a real one. No fill until hovered. destructive — it removes something. Danger edge, never a danger fill: a solid red button is the same weight as the primary and invites the press it should be discouraging. `.got-btn` and its modifiers are the names the site ALREADY uses in nine templates, so taking them over here restyles every existing button rather than leaving a second set beside them. That is also why the class names keep the `got-` prefix instead of taking a new one: a second prefix would be a second system, which is the thing this round exists to end. */ .got-btn { display: inline-flex; align-items: center; justify-content: center; gap: var(--gt-space-3); min-block-size: var(--gt-tap-min); padding-block: var(--gt-space-3); padding-inline: var(--gt-space-6); border: var(--gt-border-hair) solid transparent; border-radius: var(--gt-radius-md); font-family: var(--gt-family); font-size: var(--gt-text-sm); font-weight: var(--gt-weight-bold); line-height: var(--gt-leading-snug); text-align: center; cursor: pointer; user-select: none; transition: var(--gt-transition-control); } /* The lift is on the two FILLED kinds only. A quiet button has no body for the light to catch, and putting a highlight on a transparent box draws a 1px line across the page. */ .got-btn--primary { background: var(--gt-accent); color: var(--gt-ink-on-accent); /* 11.74:1 */ box-shadow: var(--gt-level-elevated); } .got-btn--primary:hover { background: var(--gt-accent-hover); box-shadow: var(--gt-level-hover); } .got-btn--primary:active { background: var(--gt-accent-strong); } .got-btn--secondary { background: var(--gt-surface-overlay); color: var(--gt-ink); /* 12.50:1 */ border-color: var(--gt-line-strong); box-shadow: var(--gt-level-elevated); } /* 🔴 THE WASH IS A `background-image`, NOT A `background-color`, and that is the only way this hover could be real. The first version re-declared `background: var(--gt-surface-overlay)` here — THE SAME VALUE THE REST STATE ALREADY HAS. It read as a change and was a no-op; the whole hover was carried by the border and a shadow step, which on a dark UI is close to nothing. Caught by reading the rule back, not by a test: a declaration that sets a property to what it already is cannot fail anything. A state layer fixes it without inventing a fifth surface. `background-image` paints OVER `background-color`, so one wash lightens whatever the kind happens to be sitting on and there is no "surface-overlay-but-hovered" token to keep in step with the ladder. Same technique, same one line, if a fifth button kind ever needs it. */ .got-btn--secondary:hover { background-image: linear-gradient(var(--gt-wash-soft), var(--gt-wash-soft)); border-color: var(--gt-accent); box-shadow: var(--gt-level-hover); } /* 🔴 THE PRESS GOES DOWN THE LADDER AND ON A LIGHT GROUND IT WENT UP — found by the round's verifier, 22 Aug. These were TWO `:active` rules: one took the hover wash off, the other set the background to `--gt-surface-raised`. On dark that is overlay #1E2434 → raised #171B28, which is darker, and the comment beside it said exactly what it was for: "the control is going into the page, so it must not also be getting lighter". On LIGHT the same two surfaces are #F4F7FC → #FFFFFF, and the button got BRIGHTER on press — the rule was written against the dark ladder's ORDER, and the light ladder's top is white. One rule now, and it reads the system's own press wash rather than a step of a ladder whose direction is not the same in both themes. `--gt-press` is black at 18% on dark and the light palette's own ink at 8% on light: BOTH darken, because "into the page" is the same idea either way. It is the same mechanism `.got-btn--secondary:hover` already uses one line up — a state layer over whatever the control is sitting on — which is why there is no "surface-overlay-but-pressed" token to keep in step. */ .got-btn--secondary:active { background-image: linear-gradient(var(--gt-press), var(--gt-press)); } /* Quiet is MUTED and not faint. 6.53:1 on raised — it is a real control that a person has to be able to read, and "quiet" is about visual weight, not about being hard to see. This is BUG-118's lesson as a rule. 🔴 ITS EDGE READS `--gt-edge-color` — V-35 B3 fix pass, 6 Sep 2026, and it is the same one-token idiom `.got-btn--destructive` above uses and the fields use. The ABSENCE of the token is the neutral state, so the fallback `--gt-line-strong` is the quiet edge everywhere no state supplies one and nothing on the site changes colour by this line alone. What it buys is the thing a state CANNOT get any other way: `.got-pay__copy.is-copied` and `.is-failed` say "accent" and "amber" by declaring the token, and the edge arrives here — at (0,1,0) and (0,2,0), BOTH of which `.got-btn:focus-visible` below out-specifies or beats on source order, so while the control is focused the border joins the band and the state colour is painted ONCE, by the ring. Written in the state's own stylesheet instead, that declaration was (0,2,0) in a sheet that loads later, it beat the focus rule, and the control drew an amber edge under an amber ring — BUG-247, measured. There is no per-state exception here and no second ring recipe (BUG-508); the only thing a sixth state on a quiet control has to do is declare the two tokens. THE HOVER RULE READS IT TOO, and that is not decoration either: without it `.got-btn--quiet:hover` (0,2,0) would repaint the neutral edge over a state colour that came from (0,1,0), and the accent or amber a copy button just earned would vanish under the pointer that earned it. */ .got-btn--quiet { background: transparent; color: var(--gt-ink-muted); border-color: var(--gt-edge-color, var(--gt-line-strong)); } .got-btn--quiet:hover { background: var(--gt-wash-soft); color: var(--gt-ink); border-color: var(--gt-edge-color, var(--gt-line-strong)); } .got-btn--quiet:active { background: var(--gt-press); } /* Destructive: the danger is in the EDGE and the TEXT, and the fill only arrives on hover — and even then as a tint, not a solid. Danger as text on raised is 4.56:1, which clears AA; on the tint it would be 4.07 and would not, so the hover state moves the text to --gt-ink. Both measured. */ .got-btn--destructive { background: transparent; color: var(--gt-danger); /* 4.56:1 on raised */ border-color: var(--gt-edge-color); } .got-btn--destructive:hover { background: var(--gt-tint-danger); color: var(--gt-ink); /* 12.36:1 on the tint */ border-color: var(--gt-edge-color); } .got-btn--destructive:active { background: var(--gt-tint-danger); color: var(--gt-ink); } /* ONE RING, EVERY BUTTON, EVERY BACKGROUND. See --gt-ring-* above for the measurement that makes the second tone necessary. `:focus-visible` and not `:focus`, so a mouse press does not leave a ring behind it. The border joins the band here for the same reason it does on a field (BUG-247): `.got-btn--destructive` paints its edge `--gt-danger` and now rings in it, so focused it drew the same doubled outline — a red 1px edge, the dark band, a red 2px ring. Written on `.got-btn` and not on the destructive variant on purpose: the invariant is "a focused control paints its state colour once", and a rule that named the one variant known to break it would be the list-of-selectors shape this file exists to end. On the other three kinds it moves an edge nobody can distinguish from the band behind it — transparent on primary, `--gt-line-strong` on secondary and quiet — and the moat goes from 2px to 3px, which is what a focused field does too. */ .got-btn:focus-visible { outline: var(--gt-ring-width) solid var(--gt-ring-color); outline-offset: var(--gt-ring-gap); border-color: var(--gt-ring-band); box-shadow: var(--gt-ring-shadow); } /* Disabled reads as OFF rather than as faded: no lift, no shadow, no pointer, and the cursor says so. `not-allowed` rather than `default` because a disabled control that looks pressable and does nothing is the complaint. 🔴 IT IS NOT A PROTECTION. `disabled()` is decoration in this project by standing rule, learned 7 Aug — the server refuses, always. This is what the refusal looks like, not the refusal. */ .got-btn:disabled, .got-btn[disabled], .got-btn[aria-disabled="true"] { background: var(--gt-surface-sunken); color: var(--gt-ink-muted); border-color: var(--gt-line); box-shadow: var(--gt-shadow-0); transform: none; cursor: not-allowed; /* Not `opacity`, which would drag the label under AA along with the box. --gt-ink-muted on --gt-surface-sunken is 6.74:1 and stays legible: a person has to be able to READ what they cannot press. */ } /* A button that fills its column. A modifier rather than a caller writing `inline-size:100%`, so the one-off does not become nine one-offs. */ .got-btn--block { inline-size: 100%; } /* ------------------------------------------- ICON-ONLY BUTTON — V-33 B3 --- A square at the tap minimum, worn BESIDE a kind (`got-btn--quiet got-btn--icon`), so the fill, the hover, the press, the ring and the disabled treatment are the kind's and cannot drift from the labelled buttons around it. It changes only the geometry: the width joins the `.got-btn` height at `--gt-tap-min` and the inline padding goes, because there is no label to pad. The accessible name is the button's `aria-label`, published from Blade through `__()` — an icon-only control with no name is announced as "button". The glyph is sized BY CLASS (`.got-btn__glyph`), never by a bare `svg` rule: sizing a bare element from a system rule is BUG-235's shape and `SiteTokensTest` names it. `--gt-space-6` (20px) inside 44 leaves the stroke breathing room the trash and the stepper's arithmetic signs both measured right at. Two callers today — the basket's trash and its two stepper buttons — which is one more than a one-off. */ .got-btn--icon { inline-size: var(--gt-tap-min); padding-inline: 0; flex: 0 0 auto; } .got-btn__glyph { inline-size: var(--gt-space-6); block-size: var(--gt-space-6); flex: 0 0 auto; } /* 🔴 BUG-241 — THE SUBMIT BUTTON, BROUGHT IN RATHER THAN PATCHED. `.got-submit` lived in site.css as three rules on top of a system button: full width, `cursor: progress` while submitting, `filter: saturate(.6)` when busy — and `opacity: .75` on `:disabled`. THE OPACITY WAS THE DEFECT. `public/js/form-validation.js` sets `button.disabled = true` and adds `.is-busy` on submit, so this state is on screen for every registration. Opacity fades the text AND the background together, so the figure on screen is not the figure the declarations suggest: MEASURED at 4.33:1, below the 4.5:1 floor, where the system's own disabled button is 6.74:1. That is the third time this project has been caught by opacity on a control — BUG-118, then the pager step at 3.52:1 under a comment quoting 6.5:1, now this. It is fixed by DELETION, not by choosing a lighter grey. The system's disabled state was already measured and already legible; the opacity was the only thing dragging it under, and nothing is lost by removing it — the button already reads as unavailable from its fill, its border and its cursor. `cursor: progress` stays and is deliberately NOT the system's `not-allowed`: a submitting button is working, not refusing, and those are different sentences to the person waiting. */ .got-submit { inline-size: 100%; } .got-submit:disabled { cursor: progress; } /* ---------------------------------------------------------------- INPUTS --- The field is the wrapper; the control, the label, the help and the error are its parts. Help and error are SEPARATE ELEMENTS with separate rules, because they are different sentences with different jobs and the pattern of using one grey box for both is how an error ends up looking like advice. */ .got-field { display: block; } .got-field__label { display: block; font-size: var(--gt-text-2xs); font-weight: var(--gt-weight-semibold); line-height: var(--gt-leading-snug); color: var(--gt-ink); margin-block-end: var(--gt-space-2); } /* 🔴 BUG-235 — THE REACH OF THIS RULE, AND THE RULE ABOUT REACH. ============================================================================ This rule used to say `.got-field input, .got-field select, .got-field textarea, .got-input`. The merge base styled `.got-field input` and nothing else. Adding `select` and `textarea` BY POSITION reached two legacy components that had never been sized by anything: · `.got-combo__select` — the contact channel picker, `flex: 0 0 content`. `inline-size: 100%` made its flex base the whole row, so the handle input beside it collapsed to its 26px min-content and hung off the card. MEASURED, same markup, branch vs merge base: select 105.2px -> 374px, input 268.8px -> 26px, 26px of spill. /register in both languages and /account/profile, at 1280 and at 390. · `.got-order__select` and `.got-order__textarea` on the order page, which sit inside `