/* Element defaults and the rules that must exist exactly once: the tap-target * floor, the focus ring, the visually-hidden helper, the skip link, the shell * grid and the archetype frames. Reads tokens.css and adds no values of its own — * test/ui.base.test.mjs fails on any hex or literal font-size in this file. */ /* Hanken Grotesk, variable 400-900, self-hosted. Two subsets: latin for the app, * latin-ext because the pseudo-locale generates accented forms in U+0100-024B and * U+1E00-1E9F and they must render in the real face or Task 14's long-string * layout check would be measuring a fallback. */ @font-face { font-family: 'Hanken Grotesk'; font-style: normal; font-weight: 400 900; font-display: swap; src: url('/vendor/fonts/HankenGrotesk-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Hanken Grotesk'; font-style: normal; font-weight: 400 900; font-display: swap; src: url('/vendor/fonts/HankenGrotesk-latin-ext.woff2') format('woff2'); unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF; } /* --- element defaults ---------------------------------------------------- */ /* Every rule below exists to take a colour AWAY from the user agent. That is a * different job from the component rules further down, and it is the one that is * invisible in source: a user-agent colour is not written anywhere, so nothing can * grep for it — the bug is a rule that is ABSENT. Four were measured in the Browser * pane and are fixed here (the anchor colour, the SVG fill, a form control's own * pair, and the selection highlight); accent-color is the fifth and is declared * before anything renders a check box. test/ui.base.test.mjs enumerates the elements * the client actually renders and refuses to let a new one join the tree * unclassified, so the guard is on the class of bug rather than on the five. */ *, *::before, *::after { box-sizing: border-box; } html { background: var(--canvas); color: var(--ink); /* No font-size override. The browser's 16 px default IS the §9.2 floor, and * overriding it in a percentage is how a user's own text-size setting gets * quietly discarded. */ -webkit-text-size-adjust: 100%; /* The tint a check box, a radio, a range slider and a paint * themselves. Its initial value is `auto`, which means the USER AGENT's accent — * a blue in Chrome, the OS accent elsewhere — and measured on the demo screen it * computed `auto` on in BOTH themes, so data-theme could never reach it. * Nothing in 0c renders a check box, and that is exactly why it is declared now: * phase 1's questionnaire does, and by then the leak would already be shipping on * every item. Declared here rather than on the form-control selector below because * accent-color is inherited, so one declaration also covers , which that * selector does not name. */ accent-color: var(--role); } body { margin: 0; font-family: var(--font-body); font-size: var(--type-body); font-weight: var(--weight-body); line-height: var(--leading-body); /* A NAME A PERSON TYPED CAN BE ONE UNBROKEN RUN (loop 18, browser pass): a team * called by an 80-character word — team.create's own limit — widened host.live * from 1280 to 1709 px. break-word here breaks only a word that would overflow * its line; measured, the layout of every host screen with ordinary names is * unchanged at 1280 and at 375. */ overflow-wrap: break-word; } /* And in a row's identity cell — archetype E's , where the team, * game or person name sits — where break-word does not lower the column's * minimum, so the cell grew to the whole word instead: anywhere does. ONLY there * (loop 19, measured): on every cell it let the table squeeze the other columns * below their own words, and host.live's Open broke into "Op" and "en". */ th[scope="row"] { overflow-wrap: anywhere; } h1, h2, p, ul, ol, figure { margin: 0; } ul, ol { padding: 0; list-style: none; } img, svg { max-width: 100%; } /* `fill` is an INHERITED property whose initial value is the keyword black, not * currentColor — so an SVG shape with no fill of its own paints pure black, which is * all but invisible on the dark canvas and is not a palette value in either theme. Measured * on the demo screen: every element in the tree computed `fill: rgb(0,0,0)`. Nothing * broke, because components.js writes fill="none" on both of the gate ring's circles * — the leak is latent, and §12 puts four SVG charts in later phases. currentColor * makes the default --ink and makes it swap. */ svg { fill: currentColor; } /* A form control's colour AND its fill. `color: buttontext` and * `background-color: buttonface` are user-agent values that no token can reach and * no data-theme can swap: under index.html's `color-scheme: dark light` the browser * picks its own dark-scheme pair, and under the light theme it keeps picking, so the * control would be the one box on the page that does not follow the palette. Every * button the client renders today carries .btn, .card or .pill and so is painted by * its own rule; transparent here is the floor under the one that gets forgotten. */ button, input, select, textarea { font: inherit; color: inherit; background-color: transparent; } /* The selection highlight. With no rule the pair is entirely the browser's — and it * is worse than the link colour was, because getComputedStyle does not even expose * it: measured on the demo screen, ::selection reported background-color * rgba(0, 0, 0, 0) in both themes while the browser painted its own highlight, so * neither a token nor a test nor a theme swap could see or reach it. --canvas on a * role fill is the same pair .btn-primary uses, which ui.base.test.mjs already * recomputes at >= 4.5:1 for all three roles in both themes. */ ::selection { background: var(--role); color: var(--canvas); } /* Anchors too, and this one is not tidiness. With no rule here the user agent * painted the shell's Settings and Help and the skip link rgb(158,158,255) — its * own dark-scheme link colour, picked because of index.html's `color-scheme: dark * light` — and measured in the Browser pane it stayed that value in BOTH themes: * 8.17:1 on the dark canvas, but 2.2:1 on the light one, against SC 1.4.3's 4.5:1, * on all sixty screens. A user-agent colour is not a token, so data-theme="light" * cannot reach it, and §9.1's "the light theme is a token swap" was quietly untrue * for every link in the app. --ink is 16.48:1 dark and 16.51:1 light. * * The underline is declared rather than inherited from the UA for the same reason, * and it is what says "link" — the hue never was. */ a { color: inherit; text-decoration: underline; } /*
joined with player.questionnaire's scale choices (finding 283(a)). * The UA sheet draws it a 2px groove border in ThreeDFace — a system colour no * token reaches. Taken away here; .choices (ChoiceField) then drops the border. */ fieldset { border-color: var(--line); } /* --- type roles ------------------------------------------------------------ */ .t-display { font-size: var(--type-display); font-weight: var(--weight-display); letter-spacing: var(--tracking-display); line-height: var(--leading-display); } .t-h1 { font-size: var(--type-h1); font-weight: var(--weight-h1); } .t-h2 { font-size: var(--type-h2); font-weight: var(--weight-h2); } .t-body { font-size: var(--type-body); font-weight: var(--weight-body); } /* Chrome only, and only at >= 4.5:1 — --mute clears that on both surfaces. */ .t-meta { font-size: var(--type-meta); font-weight: var(--weight-meta); color: var(--mute); } .t-micro { font-size: var(--type-micro); font-weight: var(--weight-micro); letter-spacing: var(--tracking-micro); text-transform: uppercase; color: var(--mute); } /* --- the 44 px floor ------------------------------------------------------- */ /* One rule, one token. §7.3 asks for a shared mixin rather than per-component * judgement, and the selector list is the "rather than judgement" part: an * interactive element gets the floor whether or not its author remembered the * class — which is also why the class name must not appear in this comment, or * the test's block extraction would start here instead of at the selector. */ .tap, button, [role="button"], a[href], summary, input:not([type="hidden"]), select, textarea { min-width: var(--tap); min-height: var(--tap); } /* A control inside a line of prose must not be 44 px wide, so opt out * explicitly and only where the target is genuinely a word in a sentence. * * The doubled class is not a typo and not a style: the floor above matches * `a[href]`, whose specificity (0,1,1) BEATS a single class, so `.tap-inline` * alone loses the cascade on exactly the elements it exists for — the shell's * Settings and Help links, measured in the Browser pane at the full floor width * before this selector was doubled. Keeping the class twice makes it (0,2,0) for * every element rather than special-casing the anchor. */ .tap.tap-inline { min-width: 0; min-height: var(--tap); } /* --- no double-tap zoom on a control -------------------------------------- */ /* Loop 10: two quick taps on a card or a button zoom the page on a phone, in the * middle of a round. `manipulation` drops only the double-tap gesture on these * elements; pinch zoom is the reader's and stays (SC 1.4.4). */ button, [role="button"], a[href], summary, label, select, input:not([type="hidden"]) { touch-action: manipulation; } /* --- focus ---------------------------------------------------------------- */ /* Keyboard only. A mouse user clicking a card should not get a ring; a keyboard * user tabbing to it must. §9.1 asks for 2 px in the role colour at >= 3:1 * against its neighbour, which tokens.css's test verifies for all three roles. * * NO GLOW HERE, on purpose. §7.7 rules that focus stays a solid outline and * nothing else: a halo on every focusable element would be paint work on all 21 * activity cards for no information, and a soft ring beside a hard one is exactly * how a user learns to read the soft one as focus when it means selection. The * outline is painted after box-shadow, so where a selected card is also focused * the solid ring lands on top of the halo and stays crisp. */ :focus-visible { outline: var(--focus-width) solid var(--role); outline-offset: var(--hairline); } /* The ONLY permitted `outline: none`. Stripping the default ring in a rule that * does not immediately hand the job to :focus-visible is how a codebase loses * keyboard operability, so base.css's test rejects any other form. */ :focus:not(:focus-visible) { outline: none; } /* --- helpers -------------------------------------------------------------- */ /* Available to a screen reader, not to the eye. Used for chart data tables, for * the word that accompanies a state glyph when the glyph is decorative, and for * the live-region text §9.1 requires on the timer and notifications. */ .vh { position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0; overflow: hidden; clip-path: inset(50%); white-space: nowrap; border: 0; } .skip-link { position: absolute; left: var(--space-1); top: calc(var(--space-1) * -8); z-index: 10; padding: var(--space-1) var(--space-2); background: var(--surface); border: var(--focus-width) solid var(--role); border-radius: var(--radius); transition: top var(--motion-fast) var(--easing); } .skip-link:focus { top: var(--space-1); } /* --- the shell ------------------------------------------------------------ */ /* One implementation, three themes. Header, content, footer; the footer is the * action slot and sticks, because the primary action must be reachable without * scrolling past a list of 21 activities. */ /* The page wash is the depth layer's only gradient: a radial lift at the top of * the page in the role colour, from the approved mockup. It is on the shell and * not on html, so it scales with the document rather than needing * background-attachment: fixed — a fixed attachment forces a full-page repaint on * every scroll frame, which is the single worst thing to hand a low-end Android * phone. Cards and fields are opaque, so the wash reaches only text drawn * directly on the page; §7.7 records what that costs in contrast. */ /* FOUR ROWS, EACH CHILD PLACED (loop 7, browser pass at 375 px). The template was * `auto 1fr auto` from before .shell-notice sat between the head and
: with * a notice on screen the NOTICE took the 1fr, and on a short screen one toast * grew to 372 px of empty box above the content. Placed by row, so a hidden * (empty) notice leaves its auto row at 0 and
always takes the rest. */ .shell { display: grid; grid-template-rows: auto auto 1fr auto; min-height: 100vh; min-height: 100dvh; background-image: var(--wash-page); background-repeat: no-repeat; } /* The header WRAPS, and that is Task 14's ruling rather than a default. Measured * in the Browser pane on /player/round/activities — the longest player title in * en.json — with the pseudo-locale's 40 % inflation: * * nowrap, 360 px: scrollWidth 395 against a 360 px viewport. 35 px of * horizontal overflow, which is an SC 1.4.10 (Reflow) failure, * and the h1 crushed to 79 x 114 px: four lines of eight * characters between the chip and the Settings link. * nowrap, 360 px, ENGLISH: no overflow, but the same title is 78 x 86 px — * three narrow lines. The cramped title is not a long-string * problem; the overflow is only where it stops being survivable. * wrap, 360 px: no overflow, h1 328 x 29 px. One readable line. The header * grows from 118 to 166 px, and that is the whole cost. * wrap, 600 px, ENGLISH: 76.67 px, byte-identical to nowrap — wrap costs * nothing where the row already fits, which is every English * screen above the phone breakpoint. * * A header cannot shrink past its own tap targets, so at some string length the * only alternatives are to overflow sideways or to grow downward, and growing * downward is the one that is not a conformance failure. The flex-basis below is * the second half: flex decides where to wrap from an item's UNSHRUNK width, so * without it a title one pixel too wide takes a whole row anyway and the wrap * point would be luck. Giving the h1 the full line under 600 makes the phone * layout deliberate — chip, then title, then the chrome row — and handing it back * to `0 1 auto` from 600 restores the single row wherever there is room for one. */ .shell-head { grid-row: 1; display: flex; flex-wrap: wrap; align-items: center; gap: var(--space-2); padding: var(--space-2); border-bottom: 1px solid var(--line); } .shell-head > h1 { flex: 1 1 100%; } .shell-head-spacer { flex: 1; } /* The header's chrome controls never shrink. They are flex items, so the tap * floor's min-width was the only thing holding them open and a label wider than * the floor spilled out of its own box — measured at the reference width, where * the settings link shrank to the floor while its word stayed 13 px wider, so the * visible target and the visible word disagreed. Every string in a long-string * language does the same. The h1 is what gives instead, because a heading may wrap * and a target may not. */ .shell-head > .tap { flex: none; } /* A stack of Toasts, ruling 7's mechanism: unseen persist until seen, so more * than one can be showing at once. Grid, not flex — a stack reads top to * bottom regardless of how many are showing. Empty by default, like the * timer slot in the header beside it — :empty is what keeps an unused stack * from reserving space no screen without a notice needs. */ .shell-notice { grid-row: 2; display: grid; gap: var(--space-1); } .shell-notice:empty { display: none; } /* Finding 110: a grid item's automatic min-width is its content's min-content * size, so O1's 900px row list forced this whole track wide and the page * scrolled instead of .arch-o1's own overflow-x container. min-width: 0 lets * this track shrink to the viewport; the overflow is caught below it. */ .shell-main { grid-row: 3; padding: var(--space-2); min-width: 0; } /* Outlier 2 (Task 17) — ruling 6: not an archetype, its own width * assumption, host green. No .tap anywhere in this section: nothing here is * tappable, the one screen CLAUDE.md's >= 44 px floor exempts by name. * * THE ROW HEIGHT IS A MEASURED BUDGET, and the plan's own arithmetic was out * by 600 px. Ten rows of --type-jumbo at the BODY leading (1.5) make a * 132 px row and a 1,464 px list; measured in Chrome at 1920x1080 the * document scrolled to 1,680 px inside a 1,080 px frame, and nobody scrolls a * projector. The rows therefore carry .t-display in markup — the display * leading is 0.86, which is the right treatment for a number this size anyway * — and the list gap is --space-1. The frame then budgets: * * 1,080 the projected frame * -61 .shell-head AT THE WALL'S OWN WIDTH. It was 77 until the spacing * pass hid the header's two chrome links from 1920 up — see the * 1920 block below. They are 44 px tap targets and were therefore * the tallest things in a header whose next tallest item is a * 28.5 px

, so removing them gives the list 16 px back. * -48 .shell-main's own --space-3 padding, top and bottom * -63 this block's --space-3 gap (24) plus the foot AT ITS TALLEST (39) * = 908 for the list, against 10 x 76 + 9 x 8 = 832. 76 px spare, and 74 for * the fifteen-row band. Measured after the change: the board's bottom * edge sits at 972.34 in the 1,080 frame with the foot showing "Live". * * THE FOOT IS BUDGETED AT ITS TALLEST, and the first draft of this comment was * not: measured, it is 29 px showing "Live" and 39 px once the connection * badge appears, because the badge adds its own padding and border to the * 19 px line. Budgeting the 29 claims 10 px of spare that is not there. The * conclusion survives either way, but a comment that presents an estimate as a * measurement is the thing this project keeps having to go back and fix. * * The board itself adds NO padding of its own: .shell-main already pads it, * and a second --space-3 inside the first was 48 px of the budget above spent * twice. * * ONE THING SITS OUTSIDE THIS BUDGET ENTIRELY: .shell-notice, between the head * and .shell-main. A toast is unbounded in height and nothing here reserves * room for it, so a notice addressed to the host while the wall is up would * push the last row off the bottom PERMANENTLY — nobody is standing at a * projector to dismiss one. Safe today only because all three producers of a * notification target teams (pb_hooks/lib/sync.js), which is a property of * today's intents and not of this screen. A host-directed notification is * where someone has to come back to this. * * THIS BUDGET IS SINGLE-LINE ROWS ONLY, and only holds from 900px up — * apps/host/leaderboard.js's own projection boundary, the same one * .leaderboard-exit uses. The 900px minimum-width breakpoint block, a few * thousand lines below this one, reverts Ruling 24's wrap to that single * line at every width that could be the wall for exactly this reason * (findings 169/N1/N4 — a wrapped row is taller than 76px and this budget * has no spare for one). Below 900 the row may wrap and the budget does not * apply; nothing below that width claims the fifteen-row band fits in one * frame. */ .leaderboard { display: grid; gap: var(--space-3); } .leaderboard-list { display: grid; gap: var(--space-1); } /* THE LAYOUT IS A FUNCTION OF TEAM COUNT — three bands, declared in * apps/host/leaderboard.js and selected here by attribute. The first draft of * this screen rotated ten-row pages at every size, which meant that at the * product's own stated scale of thirty teams a team was off the wall for 16 of * every 24 seconds — and "is my team above yours right now" is the entire job * of a display wall. It also left 1,872 px of frame carrying one column of * names. Two columns of fifteen hold all thirty permanently. Rotation stays, * as the honest answer for the case it was actually needed for: past thirty. * * Filled DOWN the left column and then down the right, which is how a ranked * list is read. grid-auto-flow: column with an explicit row count is what * produces that; the row count is not optional, because without it the browser * makes one row per item and the columns come out as pairs. */ .leaderboard-list[data-columns="2"] { grid-auto-flow: column; grid-template-columns: 1fr 1fr; column-gap: var(--space-5); } .leaderboard-list[data-rows="10"] { grid-template-rows: repeat(10, auto); } .leaderboard-list[data-rows="15"] { grid-template-rows: repeat(15, auto); } /* THE TYPE ROLE IS ON THE ROW, not on the three spans inside it, and that is * load-bearing rather than tidy: an em unit resolves against the font-size of * the element it is written on, so the name's own 4em flex-basis below (and, * before Ruling 24, the rank column's `2ch`) scale with the row's own size — * at the 16 px body size a rank of 88 px type ran 4 px into the team's own * name, measured at 1920 with a two-digit rank, before this rule moved. */ /* Ruling 24: FLEX, not grid, and flex-wrap is the mechanism — a grid track * either fits on the row or forces the row wider; a flex line drops an item * that does not fit onto a new line inside the SAME element, with no media * query naming a width. Rank and name stay on one line (name shrinks first, * down to its own min-width: 0). The score — plain number, or a corrected * team's badge beside it — moves to its own line only when it does not fit * beside them, via margin-inline-start: auto so it still reads flush right. * min-width: 0 on the row itself is still needed: it is a grid item of the * two-column list above, and the same min-width:auto propagation as 110 and * 168 would force that outer column wide rather than wrapping in here. */ .leaderboard-row { display: flex; flex-wrap: wrap; align-items: baseline; gap: 0 var(--space-3); min-width: 0; } .leaderboard-rank { flex: 0 0 2ch; } /* min-width: 0 lets the flex item shrink at all; overflow-wrap: anywhere is * what makes that a WRAP rather than the old truncate-to-nothing — a name * this narrows still reads, across two or three lines, instead of losing * itself to an ellipsis at 0 px. flex-basis 4em is Ruling 24's floor — a name * does not surrender the row to the score before it has to. */ .leaderboard-name { flex: 1 1 4em; min-width: 0; overflow-wrap: anywhere; white-space: normal; } /* flex: 0 1 auto (not 0 0 auto): the score's own hypothetical width can still * shrink on the line it shares with rank and name, so a short plain score * stays put; a badge wide enough that shrinking would crush it below its own * min-content is what pushes it to wrap onto its own line instead — the flex * algorithm's ordinary behaviour, not a rule naming a breakpoint. */ .leaderboard-score { flex: 0 1 auto; margin-inline-start: auto; text-align: end; overflow-wrap: anywhere; } /* The correction mark rides beside the number it applies to. Sized up from * chrome, because a 13 px badge next to an 88 px number is not a mark anybody * in the room can read, and given its tracking back because the display type * it sits inside carries -4.2 %. It borrows no colour (.badge-corrected keeps * --ink), so this introduces no pair the token audit has not already checked. */ .leaderboard-score .badge { font-size: var(--type-h1); letter-spacing: normal; } /* Small, in the corner, never competing with the jumbo numbers — but sized so * the host standing at the laptop can read it, which is the whole reason it * exists. --mute is 5.40:1 on the canvas, so growing it costs no contrast. */ /* THREE CHILDREN SINCE FINDING 16, AND THEY WRAP BETWEEN THEMSELVES RATHER THAN * INSIDE THEMSELVES. Measured in a real browser at 375 px with the longest * content this row can hold — "Page 12 of 12", "Last update 120 min ago", the * warn badge and "Backup connection", which is the venue case and not a corner * one: without `flex-wrap` the row cannot break, so flex shrank all three and * each one wrapped internally to 114 / 86 / 67 px of ragged text — a 114 px foot * and a 20 px HORIZONTAL PAGE SCROLL (scrollWidth 395 against clientWidth 375). * With it: two rows, every child on one line, 83 px, scrollWidth 375. A column * at this width was measured too and is 128 px for the same content. * * It is in the base rule and not in a `max-width` query because it is a no-op * wherever the row fits: at 768 px and at 1920 px the three children measure * 607 px of a 768+ px row, so nothing wraps and the wall is byte-identical to * what ruling 6 approved. 375 px is in scope for this screen by the same * reasoning .leaderboard-exit below is: host.live opens this screen one tap away * on whatever the facilitator is holding, which §7.5 says may be a phone. */ .leaderboard-foot { display: flex; flex-wrap: wrap; justify-content: space-between; align-items: center; gap: var(--space-2); font-size: var(--type-h2); color: var(--mute); } .leaderboard-foot .badge { font-size: var(--type-h2); } .leaderboard-mode { display: flex; align-items: center; gap: var(--space-1); } /* Freshness, beside the mode and deliberately looking nothing like it: label * then value, no badge and no state colour, because finding 16's measurement * supports a FACT and not a verdict (core/transport.js's health() answers * `stale: null`). Same flex row shape as .leaderboard-mode so the three feet * items sit on one baseline. */ .leaderboard-fresh { display: flex; align-items: baseline; gap: var(--space-1); } /* Loading, empty and error. §11's four states on the one screen with nobody * standing at it, so they are set at display size like everything else here. */ .leaderboard-state { display: grid; gap: var(--space-2); } /* THE ONLY INTERACTIVE THING ON THIS SCREEN, and it exists only where the * screen is not a wall. Ruling 6's "no interaction, exempt from the tap floor" * rests on nobody standing at a projector; Task 19b put this screen one tap from * host.live on a phone, where Settings and Help are viewless and the browser's * own control was the only way back. Hidden from 900 px in the responsive block * below, so at the wall's width it generates no box and cannot take focus — * measured, .focus() on it leaves activeElement on
. It stays in the DOM; * "not rendered" would overstate it. Not focusable is the property the ruling * rests on, and it holds where the ruling applies. * It keeps the tap floor, because below 900 px it is a phone control like any * other and the exemption does not reach it. */ .leaderboard-exit { display: flex; margin-top: var(--space-3); } /* THE EIGHTH FLEX ROW THAT HOLDS BUTTONS, AND THE ONLY ONE THAT WAS NOT PINNED. * Ledger finding 4 is the same defect closed three times — once for * .arch-a/b/c-actions, once for .arch-d/e/f-actions, once for .hostlive-hub — * and this row inherited flex's `stretch` right through all three, because * nothing rendered it: app.js passed no `actions`, so no screen could show the * failure. Latent is not fixed — and it stopped being latent in phase 5 Task 8, * which filled this slot with the host's during-event hub (ledger 37: "the * principled home is ui/shell.js's own .shell-foot slot"). Had this line not * already been here, that one change would have reproduced finding 4 for a * fourth time on all sixty screens at once. * * MEASURED with this line absent, one plain primary Button beside one held * Button — the mixed-height pair a .btn-reason span produces, which is exactly * host.games's first-run state: * * .shell-foot plain button 44 -> 67.5 px at 375, 599, 700, 899, 900, * 1280 and 1920 — every width * .arch-a-actions plain button 44 px the same two children * .arch-d-actions plain button 44 px * .arch-e-actions plain button 44 px * * Not a band: two flex items in a sticky bar do not care how wide the bar is, * which is the same argument .arch-b > .btn-wrap records. */ .shell-foot { grid-row: 4; position: sticky; bottom: 0; display: flex; align-items: flex-start; gap: var(--space-2); padding: var(--space-2); background: var(--canvas); border-top: 1px solid var(--line); } /* --- shared.mediaGallery (Task 19) ----------------------------------------- */ /* The one place this client renders an . The element default at the top of * this file already caps max-width, so what is load-bearing here is `display: * block`, which removes the inline baseline gap under every thumbnail, and * `height: auto`, which keeps the ratio once the width is capped. No shadow and * no glow: this is an item a list repeats on a low-end Android phone, which * §7.7 rules out by name. * * THE BOX IS RESERVED BY THE width AND height ATTRIBUTES, not by an * aspect-ratio here — every thumbnail is exactly 640x480 because the server * crops it (see pb_migrations/1785802800), so the markup can state the real * size and the UA derives `aspect-ratio: auto 640 / 480` from it. Measured in a * 328 px column: 328x16 reserved without them, 328x246 with. Without that the * page collapses to nothing until the images decode, the scroll jumps as each * one lands, and — because a collapsed page puts every image inside the * lazy-load threshold — loading="lazy" stops loading on demand and becomes a * cascade, which is the low-end-Android case CLAUDE.md names by hand. * * object-fit is the belt on the one silent failure this design can still meet: * if the declared thumb size ever falls out of the field's `thumbs` list, * PocketBase answers the FULL-SIZE ORIGINAL with a 200, and the two attributes * above would squash it to 4:3. Cropping is the better wrong answer than * distorting. */ .mediagallery-item { display: grid; gap: var(--space-1); margin: 0; } .mediagallery-thumb { display: block; max-width: 100%; height: auto; object-fit: cover; border-radius: var(--radius); } /* Label-plus-value on one line, the same shape as .arch-d-fact and never a * sentence. It wraps rather than truncating, because it is the item's only * accessible name. overflow-wrap: a host-typed caption can hold an unbroken run * (a URL); measured, 298 such characters widened the page to 2,859 px. */ .mediagallery-caption { display: flex; flex-wrap: wrap; align-items: baseline; gap: var(--space-1); overflow-wrap: anywhere; } /* A grid and not a flex row. The file input, two checkboxes and the button are * four controls of different heights, and .arch-e-actions' inherited * `align-items: stretch` was on record as stretching a button to 72 px beside a * field — fixed for that row in phase 2.5 Task 6, and this block stays a grid * regardless: one column, one gap, nothing to stretch. * * No margin-top: as of Task 19b this block is a flex item of .arch-a-actions, * which carries that margin for the whole row. Both applied and the gap above * the upload block measured 48 px against every other action row's 24. */ .mediagallery-upload { display: grid; gap: var(--space-2); } /* The host's per-photo caption and sharing control (phase 5 Task 10): the upload * block's grid, set off from the figure above it. */ .mediagallery-edit { display: grid; gap: var(--space-2); margin-top: var(--space-2); } /* host.gameReview's add-an-expert control. It sits in .arch-d-actions, which is * a flex row, so the field and its button are ONE flex item — and two block * children with no margin stack flush at 0 px, which is a 44 px field sharing an * edge with a 44 px button and is the exact defect test/client.classes.test.mjs * exists to sweep for. A min width so it does not collapse to the button's own * width when it shares a line with Print, Back and Publish. */ .gamereview-invite { display: grid; gap: var(--space-2); min-inline-size: 14rem; } /* Finding 138: the named researchers, then the email field and its button, in the same strip. */ .gamereview-researchers { display: grid; gap: var(--space-2); min-inline-size: 14rem; } .gamereview-researchers ul { display: grid; gap: var(--space-2); margin: 0; padding: 0; list-style: none; } /* host.invitations' add-an-invitation control, and it is .gamereview-invite's * rule for .gamereview-invite's reason one archetype over: it sits inside * .arch-o1-actions, which is a flex row, so the name field, the kind picker and * the button are ONE flex item — and three block children with no margin stack * flush at 0 px, which is two 44 px controls sharing an edge. * * NOT MERGED WITH .gamereview-invite into one shared class, deliberately. Their * numbers agree today by coincidence rather than by a shared decision: one is a * two-control row inside archetype D's action strip, this is a three-control * row inside outlier 1's, and the first screen to measure either at the 360 px * reference width should be free to move one without moving the other. A * duplicated one-line rule is cheaper than a shared name that hides that. * * PHASE 4 ADDS TWO CSS CLASSES, WHICH THE PLAN'S GLOBAL CONSTRAINTS SAID IT * WOULD ADD NONE OF. That claim was already known false when this task was * dispatched; this rule and .invitations-disclosure below are the two, and * each has its own measured-shape reason above it. */ .invitations-compose { display: grid; gap: var(--space-2); min-inline-size: 14rem; } /* host.checkIn's two whole-roster controls — the draw and the auto-form — and it * is .invitations-compose's rule for .invitations-compose's reason, on the same * archetype: both sit inside .arch-o1-actions, which is a flex row, so each * group's field(s) and its button are ONE flex item, and block children with no * margin stack flush at 0 px, which is two 44 px controls sharing an edge. TWO * elements carry it on this screen rather than one, which is what keeps "how * many to admit / Draw" from running into "prefix / size / Form teams" when the * row wraps. * * NOT MERGED WITH .invitations-compose, for the reason that rule already gives * against merging with .gamereview-invite: the numbers agree today by * coincidence rather than by a shared decision, and the first screen to measure * one at the 360 px reference width should be free to move it without moving * the others. */ .checkin-compose { display: grid; gap: var(--space-2); min-inline-size: 14rem; } /* host.checkIn's team-and-code cell, drawn through outlier 1's `render` seat. * .invitations-link's rule for .invitations-link's reason, which ui/print.css * records: .arch-b-field is hidden on paper — right for an input, wrong for a * credential — and an auto-formed team's code is the one thing on this screen * paper is for, because team.autoForm mints teams no student was handed a code * for. */ .checkin-team { display: grid; gap: var(--space-1); } /* host.checkIn's personal-link cell (finding 181): .checkin-team's rule for its * reason — not .arch-b-field, which paper hides. */ .checkin-link { display: grid; gap: var(--space-1); } /* Finding 282(g): a row's hint is for the printed card (print.css shows it); * on screen .checkin-legend says the two sentences once above the roster. */ .checkin-card-hint { display: none; } .checkin-legend { display: grid; gap: var(--space-1); } /* The standing no-delete / no-revocation disclosure, above the rows in every * state that has them. Flex with a gap and NOT two bare block siblings, for * .arch-o1-status's own recorded reason: htm strips the whitespace-only text * between two tags, so a badge and a sentence sitting inline would fuse into * one string that reads as neither. Wrapping because a long-string language * plus a two-sentence disclosure does not fit on one line, and sideways * overflow is an SC 1.4.10 failure. * * NO box-shadow and no rim. This is not a repeated row, so the venue argument * does not apply — but it is also not a WARNING about a state the screen is in: * it is a standing fact about what the product cannot do, and giving it * .arch-o1-narrow's dashed --warn rim would make the ordinary case look broken * every single time the screen loads. The StateBadge beside it carries the * glyph and the word, so nothing here rests on colour. */ /* host.invitations' personal-link cell, drawn through outlier 1's `render` seat. * It is .arch-b-field's rule and deliberately NOT .arch-b-field: ui/print.css * hides every field wrapper in the client — right for an input, which prints as * an empty box with a label, and wrong for a credential, which is the reason * the page is being printed at all. Same grid, same gap, so a link cell and the * four fields beside it line up in .arch-o1-row-fields' own column grid. */ .invitations-link { display: grid; gap: var(--space-1); } .invitations-disclosure { display: flex; align-items: baseline; flex-wrap: wrap; gap: var(--space-1); margin-bottom: var(--space-3); } /* The checkbox and its word travel together, and the whole label is the target * — which is what gets a 16 px box to the >= 44 px floor without growing the * box itself. `align-items: center` and not baseline: a checkbox has none. */ .mediagallery-check { display: flex; align-items: center; gap: var(--space-2); min-height: var(--tap); } /* --- archetype frames ----------------------------------------------------- */ /* A · status -> list -> action. The stats header, then a scrollable list of * selectable cards, then one primary action in the shell footer. */ /* 140px is the largest minimum that still fits TWO tiles on a 320 px phone — * see .arch-e-kpis below, which carries the arithmetic and the sweep. The two * rules are the same tile grid and deliberately share the number. */ .arch-a-stats { display: grid; grid-template-columns: repeat(auto-fit, minmax(140px, 1fr)); gap: var(--space-1); margin-bottom: var(--space-3); } .arch-a-list { display: grid; gap: var(--space-1); } /* A's action row and C's — the two missing members of a set of five. * .arch-d-actions, .arch-e-actions and .arch-f-actions are three identical * rules. A never had one because until Task 19b every archetype A screen passed * a single Button; C has never had one at all, even though * apps/expert/briefing.js has emitted the class since Task 9. Two .btn-wrap * children are two block grids with no margin and there is no owl rule in this * file, so a pair stacks flush at 0 px — measured, briefing's Skip and Next * buttons at the 360 px reference width, two 44 px tap targets sharing an edge, * which is a mis-tap. The same defect was measured in apps/host/live.js, where * an input's bottom edge and a button's top edge both sat at 506 px. * * align-items: flex-start AND NOT THE FLEX DEFAULT. `stretch` grows a short item * to the height of the tallest on its line, and .arch-e-actions was on record * for it — .mediagallery-upload's own comment below cites the 72 px button it * produced beside a field. Phase 2.5 Task 6 gave the declaration to * .arch-d/e/f-actions too, so all six action rows now carry it and ledger * finding 4 is closed for every archetype rather than for the three that had * been reached first. * * MEASURED ON shared.mediaGallery, the one screen putting mixed heights in this * slot (an upload grid, a notice, a Back link). With this line deleted: * * viewport 700 Back 44 -> 77.3 px notice and Back share a line * viewport 800 Back 44 -> 77.3 px * viewport 880 notice 114 -> 263.5 px upload and notice share a line; * Back is alone and unaffected * viewport >= 900 nothing: .arch-a becomes a 300 px grid column, so all three * wrap and no two items ever share a line * viewport <= 600 nothing: each item is already alone on its line * * AN EARLIER VERSION OF THIS COMMENT SAID THE DEFECT WAS NOT REPRODUCIBLE, on * three samples — 375, 465 and 1400 — that all miss the band. It is bounded by a * grid column above and by wrapping below, so neither edge is a width anybody * would think to sample, and three points are not a sweep. test/ui.base.test.mjs * pins this declaration with those numbers, because deleting it failed nothing. * * .arch-b-actions is the sixth member. Archetype B has no action slot on * purpose — a form's way FORWARD is its submit — but a form has no way BACK * either. It sits outside
for that reason: whatever it holds is a * navigation control, or a second act of its own, and must never be mistaken * for a second submit. * * THE "BELONGS TO ONE SCREEN, player.round.funding" THIS REPLACES WAS STALE and * had been for two phases: counted at Task 14, the class has SEVEN consumers — * player.round.funding, player.join, player.register, expert.deal.compose, * expert.feedback, expert.vote and now host.builder.publish, whose Export and * builder nav sit here because Publish is the submit. A comment naming a count * is a comment somebody has to recount; this one names the rule instead. */ .arch-a-actions, .arch-b-actions, .arch-c-actions { display: flex; flex-wrap: wrap; align-items: flex-start; gap: var(--space-2); margin-top: var(--space-3); } /* Finding 115: who a personal-slot screen answers as, and "Not you?" beside it. */ .personal-who { display: flex; flex-wrap: wrap; align-items: center; gap: var(--space-2); margin-bottom: var(--space-3); } /* B · form. One column at the reference width; labels above fields, never * beside them, because a placeholder-as-label disappears the moment it is * typed into and a beside-label wraps badly in a long-string language. */ .arch-b-form { display: grid; gap: var(--space-3); max-width: 560px; } .arch-b-field { display: grid; gap: var(--space-1); } /* THE SUBMIT, WHICH SAT FLUSH AGAINST THE LAST FIELD ON ALL FOURTEEN ARCHETYPE B * SCREENS FROM 0c UNTIL PHASE 2.5. ui/archetypes/b.js renders the submit OUTSIDE * the — deliberately, so a form's own gap is the field rhythm and nothing * else — and .arch-b is a bare
with no layout, so the two are block * siblings with no margin between them. Identical in kind to * .arch-b-summary-stats below, whose comment already says it: the form's gap * never reaches a sibling. * * MEASURED, five screens at 375 px, before this rule existed. On player.join, * player.register, host.signIn and shared.settings the form's bottom edge and * the button's top edge were BOTH at 349.00; on expert.invite both at 253.50. * The number that matters is the one below it: the last INPUT's bottom edge and * the submit's top edge were the same pixel on all five, so two 44 px tap * targets shared an edge — and on player.join, the door every student at the * event walks through on a venue phone, aiming low at the code field submits it. * * NOT A BAND, AND THAT WAS CHECKED RATHER THAN ASSUMED. Ledger finding 4's * lesson is that a layout defect can hide between the widths anybody samples, so * player.join was swept at 320, 360, 375, 414, 599, 600, 700, 768, 899, 900, * 1024, 1279, 1280, 1440 and 1920 — every breakpoint and both sides of each. The * gap was 0 at all fifteen, because two block siblings do not care how wide they * are. That is the argument for one declaration rather than a media query. * * --space-3 and not --space-2: it is the form's OWN field rhythm, so the submit * sits one field-gap below the last field rather than inventing a spacing. */ /* FINDING 46 — AND THE max-width IS THE SECOND HALF OF THE SAME STRUCTURAL * CAUSE. `.arch-b-form` caps itself at 560 px and the submit is rendered OUTSIDE * the , so nothing the form declares reaches it: the button tracked the * whole content column, 2.2x the width of the fields it submits. Measured on * player.join at 1280 px, before and after: * * before after * .shell-main 1280 1280 * .arch-b-form 560 560 * its 560 560 * .arch-b > .btn-wrap 1232 560 * the submit