:root { --bg-primary: #ffffff; --bg-secondary: #f5f5f7; --bg-tertiary: #e3e3e6; /* The pressed fill for the dev card at both sizes: one step darker than the hover fill (zinc-50) on the same ramp, so a press reads as more of the same gesture rather than as a new colour. */ --dev-press: #eaeaea; --bg-code: #f5f5f7; --bg-code-header: #e3e3e6; --bg-card: rgba(10, 124, 255, 0.06); --bg-card-alt: rgba(16, 185, 129, 0.04); --bg-input: #f5f5f7; --border: #d1d1d6; --border-light: #e3e3e6; --text-primary: #0a0a0a; --text-secondary: #3a3a3c; /* #68686c, not the #6c6c70 eyedropped with the rest (QA 2026-09-24 Q20): the same four-step correction tailwind.config.js made to zinc-500, and for the same reason. #6c6c70 is 4.34:1 on the zinc-100 track the theme toggle's idle segments sit in; #68686c clears 4.61. */ --text-muted: #68686c; --text-faint: #8e8e93; --text-code: #3a3a3c; /* #0a6ee0, not the #0a7cff eyedropped from the design screenshots. White on that blue is 3.93:1 — below AA for normal text, which made EVERY primary button in the product (Send, Open, Publish profile, Improve, New conversation) a control you could see and a label you could not quite read. It failed the same way as ink: `text-violet-600` on white was the identical 3.93. One step darker clears both at 4.86, and the hue is unchanged to two decimal places of what the deck shows. The DARK accent below is untouched: it is a lighter blue on purpose, because against a near-black page it has to be, and it is used mostly as ink rather than as a fill. Where it IS a fill, --accent-ink supplies the near-black text that goes on it. */ --accent: #0a6ee0; --accent-light: #1f86ff; --accent-tint: rgba(10, 110, 224, 0.08); /* The accent as a FILL you can put dark ink on — violet-100, the pale end of the same ramp. `--accent-tint` is a translucent overlay for hovers and stripes; this is an opaque surface, which is what the dev composer's send circle needs so its halo reads against it. */ --accent-wash: #d6e9ff; --accent-wash-ink: #0062cc; /* Accent-coloured TEXT sitting on --accent-tint (QA 2026-09-24 Q20). The tint is translucent accent, so it pulls the accent's own contrast down: #0a6ee0 on the 8% tint over white is 4.34:1, under AA for the card band's 12px labels ("Start work", "Claim this issue"). One step down the ramp (violet-700) reads at 5.19 and is the same hue. Dark keeps the accent itself, which already clears 5.4 on its tint. */ --accent-tint-ink: #0062cc; /* Text ON the accent, wherever the shell puts type on a saturated fill. It must not follow the page. The outgoing chat bubble used to be the headline case and no longer is a fill at all; .messages-state button still is. */ --accent-ink: #ffffff; /* ── The dev chat's surface ladder ─────────────────────── Three steps, and the ONLY thing they guarantee is that each one is nearer the reader than the last: the strip sits on the page wallpaper, the session sheet sits on the strip, and a card (your message, a coding run) sits on the sheet. They exist because --bg-secondary / --bg-primary could not express that in both themes. In light those two ascend (#f5f5f7 → #ffffff), which is what the lift was built on. In DARK they descend — --bg-primary is #0b0b0c and --bg-secondary is #1c1c1e — so the stack inverted: the sheet came out as the darkest thing on the screen, a near-black hole punched into the #0b0d1b wallpaper, with the strip ABOVE it lighter than both. Measured: wallpaper (11,13,27) → strip (28,28,30) → sheet (11,11,12). Nothing here changes light mode. --dc-strip and --dc-raised are --bg-secondary's value, --dc-sheet is --bg-primary's, so the light stack is byte-identical to what shipped. Dark is where the values are new, and they climb: (11,13,27) → (19,19,22) → (28,28,30) → (44,44,46). */ --dc-strip: #f5f5f7; --dc-sheet: #ffffff; /* A CARD SITTING ON A SHEET, which is a different job from the sheet. The category cards took `--dc-sheet-fill` — the same value as the pane they sit on — so in DARK MODE they were rgba(28,28,30,.72) on rgba(28,28,30, .72) and the only thing separating them was a 12%-white hairline. Light mode got away with it because its hairline is 10% BLACK on near-white, which reads far harder than 12% white on near-black does. Opaque in both themes, because a raised surface that is see-through is not raised. */ --dc-sheet-raise: #ffffff; --dc-raised: #f5f5f7; /* ── …and the two PLANES, which are not the same thing ─── The three tokens above are SURFACE VALUES: what a card, an inset or a chip paints. The two below are what the strip and the session sheet — the ladder's two full-screen planes — actually fill with, and they are translucent so the page wallpaper reads THROUGH the session rather than being covered by it. They are separate tokens on purpose. --dc-sheet is read by nineteen rules as an opaque inset inside a card; making THAT translucent would have let every chip and every code block see the card behind it, which is a different change and a wrong one. Only the plane is glass. NO BLUR, ON ANY PLATFORM. `--dc-frost` was `blur(24px) saturate(1.6)`, and WebKit re-ran that filter over every frosted surface on every frame that content scrolled behind it or a spring moved it: the phone stutter #787 and #3104 measured. It is `none` everywhere now, so every platform draws the same colours: a plane that only ever sits on the fixed wallpaper keeps its translucent fill (the washes are soft shapes already, and measured against the glass the fill alone lands within a few points of it), and a surface that content scrolls or slides behind, or that floats over other UI, is opaque in the `-solid` colour below. The token stays so every `backdrop-filter: var(--dc-frost)` keeps resolving. */ --dc-strip-fill: rgba(244, 242, 228, 0.38); --dc-sheet-fill: rgba(255, 255, 255, 0.50); --dc-frost: none; /* THE PLANE COLOURS, OPAQUE: each fill composited over the wallpaper's base (244, 242, 228), which is what the glass showed wherever nothing but the wallpaper was behind it. Used by the bars, sheets, panels and heads that content passes behind, so they read as the same material as the planes without letting that content show through. Not --dc-sheet / --dc-strip: those are the neutral #ffffff / #f5f5f7 surface values, and a bar in them came out whiter and greyer than the glass it replaced. */ --dc-sheet-solid: #faf9f2; --dc-strip-solid: #f4f2e4; /* FLOATING surfaces are denser (#2887). A pane is glass over the wallpaper, which the platform draws and keeps soft; a dialog or a menu floats over WHATEVER is under it — an app's dark UI, a code block, a photo — and at the pane's alpha that showed through as shapes behind the form's own text. Mostly opaque, still frosted: the blur stays, so the surface keeps its material, and the words stay legible over dark content in both themes. Used by the kit's modal (Send Feedback and every other dialog) and the platform mark's menu. */ --dc-float-fill: rgba(255, 255, 255, 0.95); /* ── Safe-area tokens ──────────────────────────────────── THE single source of truth for the shell's own safe-area arithmetic. Every rule in this file that needs an inset reads one of these two — never bare env() — so there is exactly one place to change if the source ever moves. Written as `var(--un-safe-inset-X, env(safe-area-inset-X, 0px))`, the kit's convention (see the "Safe areas" block in public/usernode-native/v1/native.css). The shell is a top-level document, so nothing sets the custom property and env() supplies the real value; writing it this way means the shell would also honour a forwarded inset if it were ever framed, and it is what lets `?shot=safe-bottom` (public/js/app.js) paint the whole shell — kit `.un-safe-*` classes included — as if it were on a notched phone. */ --platform-safe-bottom: var(--un-safe-inset-bottom, env(safe-area-inset-bottom, 0px)); /* HOW MUCH OF THAT INSET THE PHONE TAB BAR SPENDS (#2766). Everywhere but iOS, all of it — see `html.un-ios` further down for the one exception and `.platform-tabs` for where it is spent. Declared here, beside the inset it reads, so the Android standalone override of the inset (#2755) flows through it on the same element. */ --platform-tabs-inset: var(--platform-safe-bottom); /* THE AIR BETWEEN THE WORKSHOP'S LANDER AND THE FOOT OF ITS SCROLLER. `.dev-ws`'s `--ws-area` and `--ws-fit` both read it. Root-scoped since the tab bar was portalled out of `.dev-ws`; the bar is back in flow at the head of the page (#2767) and the token simply stayed where every reader can see it. */ --ws-gap: 8px; --platform-safe-top: var(--un-safe-inset-top, env(safe-area-inset-top, 0px)); /* Content-row height of the mobile install strip (#1372). Declared here, unconditionally, rather than on either element that reads it: `body` reserves this much padding and the strip itself is sized to it, and a custom property set on the strip could not be read by its own ancestor. One declaration, so the reserved space and the drawn height cannot drift into a gap or into covered content. */ --install-strip-h: 3rem; /* The authored top bar's height, WITHOUT the status-bar inset it extends into (that is --platform-safe-top, added by whoever needs the total). Not a new fact: it is what the "Header height invariant" block near #header-title.is-centered derives from the markup — pt-3/pb-5 around a 28px content row — restated once so a surface that hangs off the bottom of the bar can say so rather than hard-code a number that quietly stops matching. #apps-switcher-sheet's desktop popover reads it as its fallback position, for a frame where the mark cannot be measured; tests/app-switcher-dropdown.test.js pins this against the header's own classes so the two cannot drift. 52px UNTIL THE BOTTOM PADDING GREW. The bar was py-3 — 12px above and below a 28px row — and it also carries `-mb-2`, which pulls whatever follows 8px UP into it to cut the notch every platform surface reads as its rounded top. Those two facts together left FOUR pixels between the controls and the next thing on the screen. On most routes that next thing is transparent and nobody could tell. On an app route and in a proposal session it is a raised sheet — a 28px radius, a hairline and a shadow reaching up into the bar — and the chip, the bell and Improve sat on its lip. `pb-5` spends 8px buying that clearance back, so the notch costs the controls nothing. */ --platform-header-h: 3.25rem; /* ── Semantic state tokens (dev board) ─────────────────── ONE meaning per hue, so the same lifecycle stage never reads two ways depending on which helper drew it. Every dev-card status badge / pill / composite-pill tone routes through these; nothing in the board's status vocabulary should hard-code a hex again. neutral — not started, skipped, draft, paused, archived progress — actively happening: merging, resolving, checks running, in vote. Violet, NOT amber: amber used to do this job as well as three others. attention — non-blocking heads-up: behind main, console errors, advisory votes, explicit approval. Amber now means ONLY this. blocked — blocks the merge: checks failing, checks couldn't run, preview won't boot, conflict. Red. ("Checks failing" used to be amber, reading like a warning when it actually blocks.) ok — done and good: merged, checks passing, passed — merging shortly, a Yes tally. Green. ("✓ Checks passing" used to inherit the violet Merged colour.) admin — an admin bypass. Same amber family as attention but distinguished by an OUTLINE (see .gc-vote-btn-admin) so hue alone isn't the signal. `-bg` companions are the faint fills; `-fill` the stronger proportional-fill wash used inside the tally pill. */ --state-neutral: #6b7280; --state-neutral-bg: rgba(107, 114, 128, 0.12); --state-progress: #7c3aed; --state-progress-bg: rgba(124, 58, 237, 0.12); --state-attention: #b45309; --state-attention-bg: rgba(245, 158, 11, 0.14); /* THE BRAND PERIWINKLE — the homescreen design's second accent, distinct from --accent (the blue that fills buttons and links across the product). It is the ink of the header's controls (the app chip, the bell, the back disc) and of the section links on the home screen, with a tint for their fill and a hairline one step darker than the tint. Sampled from the design's render (#37477b / #e4e9f7); the hairline is interpolated. Read through Tailwind arbitrary values (`text-[color:var(--brand-ink)]`) so the classes stay complete literals for the extractor. */ --brand-ink: #37477b; --brand-tint: #e4e9f7; --brand-line: #c9d2f2; /* WHERE YOU ARE: the lit tab on the phone's bar and the lit row on the rail, in the product's one accent (AGENTS.md, "Type and colour"). It was the periwinkle above, which beside the action blue made two blues that meant nearly the same thing; the periwinkle stays the header's own ink (the chip, the bell, the back disc) and "you are here" is the accent, one step darker as ink so the 11px label clears 4.5:1 on the tint. */ --lit-ink: #0062cc; --lit-tint: #eaf4ff; --lit-line: rgba(10, 110, 224, 0.25); /* The running app's sheet edge (#1571) — see "THE APP SHEET" below for which element wears it and why. Straight off the design's render (node 736:4306): a black-at-10% hairline, and a two-layer shadow in the deck's blue-black rather than neutral grey, which is what keeps it from reading as dirt over the cream ground. */ --app-sheet-line: rgba(0, 0, 0, 0.1); --app-sheet-shadow-near: rgba(24, 39, 75, 0.12); --app-sheet-shadow-far: rgba(24, 39, 75, 0.08); /* The lift's two layers as one value — see `.dc-lift`. */ --dc-lift-shadow: 0 6px 12px -6px var(--app-sheet-shadow-near), 0 8px 24px -4px var(--app-sheet-shadow-far); /* The modal dim, cast BY the pane rather than painted behind it. Same 40% black the overlays used to carry as `bg-black/40`; see `.dc-lift-panel`. Ink and alpha are split out so the kit's sheet and side panel can scale the alpha by `--un-presence` and ride the slide (see "THE KIT'S SURFACES TAKE THE PANE GLASS"); the composed token is what everything else reads. */ --pane-scrim-ink: 0 0 0; --pane-scrim-alpha: 0.4; --pane-scrim: rgb(var(--pane-scrim-ink) / var(--pane-scrim-alpha)); --state-blocked: #dc2626; --state-blocked-bg: rgba(239, 68, 68, 0.12); --state-blocked-fill: rgba(239, 68, 68, 0.32); --state-ok: #15803d; --state-ok-bg: rgba(34, 197, 94, 0.12); --state-ok-fill: rgba(34, 197, 94, 0.32); --state-admin: #b45309; --state-admin-bg: rgba(245, 158, 11, 0.10); } /* ── Safe-area utilities ───────────────────────────────── The platform's half of "backgrounds extend into the bottom inset, interactive content insets itself": .platform-safe-scroll — a scroll container whose content ends at the bottom of the screen. Block-end padding is part of a scroller's scrollable overflow, so the last row becomes reachable AND the scroller's own background still paints through the strip. .platform-safe-bar — a pinned bottom bar (every composer block) that already carries Tailwind `p-2`. The 8px base gap is preserved and the inset is added below it. `!important` is load-bearing, not laziness: /css/tailwind.css is linked AFTER /css/app.css (index.html — and the inline probe there enforces that order), so a plain class here loses the specificity tie against `p-2` / `p-4` on the same element purely on source order. The kit's own `.un-safe-*` helpers carry `!important` for exactly this reason. Deliberately NOT the kit's `.un-safe-bottom`: that one REPLACES the element's own bottom padding with the bare inset (a composer would lose its 8px gap) and has no keyboard-up suppression. These wrap the kit's token rather than forking its CSS. */ .platform-safe-scroll { /* `max()` because the two things this clears are stacked, not added: when #platform-tabs is up, `--platform-tabs-h` is the bar's FULL outer height and the bar's own lower padding already covers the home-indicator strip, so taking the larger of the two reserves each exactly once. When the bar is down the token is 0px and this is the bare inset it has always been. See the #platform-tabs section at the end of this file. */ padding-bottom: max(var(--platform-tabs-h, 0px), var(--platform-safe-bottom)) !important; } .platform-safe-bar { /* Same `max()` as the scroller above, inside this rule's own base gap: a composer row is the bottom of a column that reaches the viewport, so what it has to clear is whichever of the tab bar and the home-indicator strip is taller — never both stacked. Every surface that wears this class sits on a screen where the bar is EITHER up (#messages-screen, #global-chat-screen) or hidden (everything inside #app-view), and in the hidden case `--platform-tabs-h` is 0px and this is exactly the declaration it has always been. */ padding-bottom: calc(0.5rem + max(var(--platform-tabs-h, 0px), var(--platform-safe-bottom))) !important; } /* .platform-safe-sheet — a sheet's own FOOTER row (the Apps sheet's Home | Explore pair). Same additive rule as .platform-safe-bar, with the sheet's larger base gap: a sheet has rounded top corners and sits on the ground rather than against the screen edge, so its last row needs real padding under it whether or not the device reports an inset. This exists because .platform-safe-scroll REPLACES the element's bottom padding with the bare inset — correct for a scroller whose content runs to the bottom of the screen, wrong for a button row, which on every 0-inset device (desktop, most Android, the in-app preview) then sat flush on the sheet's rounded edge. */ .platform-safe-sheet { padding-bottom: calc(1.25rem + var(--platform-safe-bottom)) !important; } /* Keyboard up: the home-indicator strip sits BEHIND the on-screen keyboard, so reserving it there is pure dead space above the keyboard. Same suppression the kit applies to its own surfaces (`html.un-kb .un-panel-body` / `.un-action-sheet` / `.un-kb-avoid` in native.css). The bar keeps its 8px base gap; a scroller that also carries the kit's `.un-kb-avoid` gets the keyboard inset from the kit instead. */ html.un-kb .platform-safe-scroll { padding-bottom: 0 !important; } html.un-kb .platform-safe-bar { padding-bottom: 0.5rem !important; } html.un-kb .platform-safe-sheet { padding-bottom: 1.25rem !important; } /* Keyboard up: reserve its height on a COMPOSER COLUMN (#1937, #1491). Four screens are built the same way — the topic thread, the general chat, the dev chat and Messages. Each is a flex column holding a `flex-1` scroller with the typing slot and composer pinned BELOW it as `shrink-0` siblings, OUTSIDE the scroller. That shape is deliberate (thread-shell.tsx explains it), and it is exactly what the kit's keyboard avoidance cannot help with: `attachKeyboardAvoidance` gates every path on `scrollEl.contains(field)`, and `html.un-kb .un-kb-avoid`'s padding lands INSIDE the scroller. So nothing lifted the composer and you typed blind. On iOS there was a second symptom on top of that. Safari pans the document to reveal the focused field, and `settledPin()` — which runs on EVERY settled viewport event, not only on focus — reset that pan with `window.scrollTo(0, 0)`. Typing resizes the visual viewport (QuickType), so the page snapped back once per keypress and took the transcript with it. Android never had that half: Chrome does not pan (measured: scrollY stays 0), though its composer was covered just the same. Reserving the inset on the column fixes both, and is what native does — iOS Messages and Android Messages both shrink the content area by the keyboard's height and pin the composer above it rather than covering or panning. The scroller loses that height instead of being covered, so the transcript stays visible, the composer sits above the keys, and the settled pin is no longer destructive. It is NOT inert, and a column needs it (#3571). iOS pans the page on the tap, before this padding exists, by the most it can: the keyboard's height. The padding then lifts the composer by that height again inside the panned page, so it ends near the top edge, above the screen. The pin (attachKeyboardAvoidance, via attachScreenFx on the legacy-mounted chats) puts the pan back once the keyboard settles. A React column that no controller mounts attaches it itself: lib/composer-keyboard.ts. Transition shape copied from the kit's own `.un-kb-avoid`: none while the keyboard is up so the bar tracks it exactly, eased on the way out so the browser's scrollTop clamp rides the ease instead of snapping. A column that takes this must NOT also carry `.un-kb-avoid` on its scroller — that would reserve the inset twice and leave dead space under the transcript. */ .platform-kb-column { transition: padding-bottom 150ms ease-out; } html.un-kb .platform-kb-column { padding-bottom: var(--un-kb-inset, 0px); transition: none; } /* …and the scroller inside it must NOT reserve it a second time. `attachKeyboardAvoidance` ADDS `un-kb-avoid` to whatever scroller `attachScreenFx` hands it — the general chat's `#gc-messages`, the topic thread's `#gc-thread-scroll`, the dev chat's `#dc-messages` — so on those screens the class is there at runtime whether or not any source file writes it. With the column reserving as well, the inset is counted twice, and the second one is the damaging one: a scroll container cannot shrink below its own padding, so `#gc-messages` bottomed out at 368px (its `py-2` 8px plus a 360px keyboard inset) and floored the whole column. Measured on a Pixel emulator against the live general chat: the composer rose 163px of the 360 it needed and stayed behind the keys. The topic thread escaped only because its column had enough slack to absorb the floor. Suppressing it here restores the single reservation: general chat's composer moved from 647 to 450 — exactly the keyboard line — while the topic thread stayed at 450, unchanged. Specificity (0,3,1) beats the kit's (0,2,1) and app.css loads after native.css, so no !important is needed. */ html.un-kb .platform-kb-column .un-kb-avoid { padding-bottom: 0; } /* ── Platform Messages screen ───────────────────────────── Fully React-owned (frontend/src/features/messages). Every rule is scoped to messages-* so the app group chat keeps its own contract. DRAWN ON THE DEV SESSION'S LIFT LADDER — see `.dc-lift` and its two plane classes further down. The wallpaper is the ground (this route is in the body:has(…) wallpaper list). `.messages-layout` is the frosted STRIP, carrying the screen's title, the New disc and the conversation rows drawn straight on it. The open conversation is the frosted SHEET rising on the strip — `.messages-thread-pane` — with its title row, transcript, typing line and composer inside. Both planes wear `.dc-lift` plus `.dc-lift-strip` / `.dc-lift-session` from index.tsx, so the fills, the frost, the no-backdrop-filter fallback and both themes come from one place rather than being restated here. The same construction at both widths: on a phone the list screen IS the strip and a thread is the strip's shoulder showing above the sheet; from 768px up both panes sit on one strip with the sheet beside the list. */ /* The tokens are the project page's Discussion tab's too (#3653): an app channel's reply thread opens there, in the same pane as here, with no `.messages-layout` around it (project-discussion.tsx). */ .messages-layout, .dev-ws-discussion { /* The OPAQUE surfaces drawn on the two planes: a bubble from the other side, a shared-item card, a floating disc, the composer. White on the light sheet. In dark it is the ladder's own raised step (--dc-raised), so a card is one step lighter than the sheet rather than a hole in it — --bg-primary is near-black there and would be exactly that hole. */ --messages-surface: #ffffff; /* The step off a surface: a glyph tile on a card, a disc's hover. */ --messages-surface-2: var(--bg-secondary); --messages-hair: var(--border-light); /* The open conversation's row on the strip, and a row under the pointer. A translucent white so it reads as the row the sheet came out of. */ --messages-selected: rgba(255, 255, 255, 0.55); --messages-disc-shadow: 0 1px 2px rgba(0, 0, 0, 0.06); } .messages-layout { display: flex; width: 100%; height: 100%; min-height: 0; } .dark .messages-layout, .dark .dev-ws-discussion { --messages-surface: var(--dc-raised); --messages-surface-2: #3a3a3c; --messages-hair: rgba(255, 255, 255, 0.08); --messages-selected: rgba(255, 255, 255, 0.06); --messages-disc-shadow: 0 1px 2px rgba(0, 0, 0, 0.4); } .messages-list-pane { flex-direction: column; width: 100%; min-width: 0; min-height: 0; } /* The sheet. Its top margin is what shows the strip's shoulder above it on a phone — the same reading the dev session gives, where the session sheet sits ON the strip rather than abutting it. */ .messages-thread-pane { flex-direction: column; width: 100%; min-width: 0; min-height: 0; margin-top: 12px; } /* The list's head: the screen's name at Home's heading size, and New as a floating disc. The header bar's chip already names the screen, so there is no subtitle under it. */ .messages-list-toolbar { display: flex; align-items: center; flex: 0 0 auto; gap: 12px; padding: 18px 16px 8px; } .messages-list-title { min-width: 0; flex: 1 1 auto; } /* Preflight resets headings to inherit, so the size is this rule's to give. */ .messages-list-title h2, .platform-screen-title { color: var(--text-primary); font-size: 28px; font-weight: 700; line-height: 1.15; letter-spacing: -0.01em; } /* ONE SIZE FOR A PLATFORM SCREEN'S NAME (#2718). Messages named itself at 28px and the Workshop named itself with the grouped list's SECTION LABEL — 15px, regular weight, muted — so two screens one tab apart disagreed about what a screen title is. The section label is for a group WITHIN a screen; a screen's own name is the biggest thing on it. The selector above is a second spelling of the Messages rule rather than a replacement of it: that one is reached as `.messages-list-title h2` from a flex toolbar that also held the New disc, and rewriting its markup to take a class is a change to a screen this issue is not otherwise touching. Home is deliberately NOT a caller. The bar above it carries the Homeroom wordmark, and a screen called Home under a wordmark is the same word twice; the wordmark IS Home's title. Every other platform screen is named by the tab that opened it, so it says its own name. */ .platform-screen-title { padding: 18px 16px 8px; } /* THE DISCS: New, the thread's actions, and the per-message tray's buttons. The language's floating circular control — a white disc on the plane, with the same hairline of shadow the header's discs carry. */ .messages-new-button, .messages-thread-action { display: inline-flex; align-items: center; justify-content: center; flex: 0 0 auto; width: 40px; height: 40px; border-radius: 9999px; color: var(--text-primary); background: var(--messages-surface); box-shadow: var(--messages-disc-shadow); transition: background 150ms; } .messages-new-button { width: 44px; height: 44px; color: var(--accent); } .messages-new-button:hover, .messages-thread-action:hover { background: var(--messages-surface-2); } .messages-new-button svg, .messages-thread-action svg, .messages-composer-action svg, .messages-send svg { width: 22px; height: 22px; fill: none; stroke: currentColor; stroke-width: 2; stroke-linecap: round; stroke-linejoin: round; } .messages-new-button svg { stroke-width: 2.5; } .messages-list-scroll, .messages-thread-scroll { min-height: 0; flex: 1 1 auto; overflow-y: auto; overscroll-behavior: contain; } /* THE LIST, AND NOT THE THREAD. Both scrollers reach the bottom of the screen, but the thread has the composer below it and the composer clears the tab bar itself (`.platform-safe-bar`), so padding here as well would reserve the band twice. The list has nothing under it — on a phone it IS the screen, and from 768px up it is the left column beside the sheet — so its last conversation row would otherwise sit behind the bar. The bare token rather than the `max()` the others take: this scroller reserves NOTHING today, so the inset is not part of what it is correcting and pulling it in here would be a second change riding along. 0px with no bar keeps that exactly as it was. */ .messages-list-scroll { padding-bottom: var(--platform-tabs-h, 0px); } /* THE HISTORY ABOVE A COMPOSER RESERVES NOTHING AT ITS FOOT (iPhone app, 19 October 2026). The note above is the rule, but the scroller carries `.platform-safe-scroll` too, and that class won: on a phone the history kept a band of the tab bar's full height (56px in a browser, about 90 in the app, with the home-indicator strip) empty above the composer, which clears the bar again itself. So the band goes wherever a composer (`.platform-safe-bar`: Send, the request awaiting acceptance, "you can't send here") follows the history in its pane, the reply thread's included. Where none does (an invitation before it is accepted), the history reaches the foot of the screen and keeps the band. 0 rather than the 6px below: `.platform-safe-scroll` already made it 0 wherever the bar is down, so a desktop is exactly as it was. */ .messages-thread-scroll.platform-safe-scroll:has(~ .platform-safe-bar) { padding-bottom: 0 !important; } /* THE BOT'S CHAT, OPENING (features/messages/open-hold.ts). Its rows are laid out, so the transcript can tell whether they fill the screen, and not seen until they are what it will stay as; the spinner stays at the top of the scroller over them, however far down it is scrolled. */ .messages-thread-pane[data-opening] > .messages-thread-scroll > :not(.messages-state), .messages-thread-pane[data-opening] > [data-transcript-overlay] { visibility: hidden; } .messages-thread-pane[data-opening] > .messages-thread-scroll > .messages-state { position: sticky; top: 0; } /* A conversation row, drawn straight on the strip: the square swatch avatar, then two lines — the name with the time on its trailing edge, the preview with the unread count on its. 15/13px, the grouped list's scale (AGENTS.md, "Type and colour"): 17px bold made every name a heading. */ .messages-conversation-row { position: relative; display: flex; align-items: center; gap: 14px; min-height: 66px; padding: 13px 16px; color: inherit; text-decoration: none; transition: background 150ms; } /* The row separator, INSET past the avatar to where the name starts: 16px of padding + the 44px `lg` UserAvatar + the 14px gap. A pseudo-element rather than `border-bottom` because a border cannot be inset, and because the row is a fixed-height box whose 66px the border would eat into. Same treatment, same reason, as the drawer's nav rows, the home panels and @/components/ui/grouped-list.tsx: the widget language starts a row separator at the content, and the last row has none. */ .messages-conversation-row::after { content: ''; position: absolute; bottom: 0; left: 74px; right: 0; height: 1px; background: var(--messages-hair); pointer-events: none; } .messages-conversation-row:last-child::after { display: none; } .messages-conversation-active { background: var(--messages-selected); } /* A pointer that can actually hover only (the #2892 rule for app tiles). On a touch screen WebKit keeps :hover on the last row tapped, so the row you opened, or merely scrolled from, stayed tinted like the active one after you came back to the list. */ @media (hover: hover) { .messages-conversation-row:hover { background: var(--messages-selected); } } .messages-row-line { display: flex; align-items: center; gap: 8px; min-width: 0; } /* A group row's tile (#5393): the faces of two of its other members, stacked in the same 44px box the `lg` square takes, so the 74px separator inset (16 + 44 + 14) holds. The last face's ring is the card the rows sit on (.messages-section-card paints `--dc-sheet-solid`), so the pair reads as two faces and not one melted one. */ .messages-group-faces { position: relative; flex: 0 0 44px; width: 44px; height: 44px; } .messages-group-faces > * { position: absolute; } .messages-group-faces > :first-child { left: 0; top: 0; } .messages-group-faces > :last-child { right: 0; bottom: 0; box-shadow: 0 0 0 2px var(--dc-sheet-solid, var(--app-bg)); } .messages-row-name, .messages-row-preview { flex: 1 1 auto; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .messages-row-name { color: var(--text-primary); font-size: 15px; font-weight: 650; line-height: 20px; } .messages-row-preview { margin-top: 2px; color: var(--text-muted); font-size: 13px; line-height: 18px; } /* An invitation's preview is the ACTION the row offers, so it takes the accent — the language's "actionable / yours". */ .messages-row-preview-invited { color: var(--accent); font-weight: 500; } .messages-row-time { flex: 0 0 auto; color: var(--text-muted); font-size: 13px; font-variant-numeric: tabular-nums; } /* #18 of the 19 Oct polish board, ONE MEANING PER BADGE: the accent is "waiting on you" (a vote, an answer), and an unread message is new to read, which is grey everywhere. So an unread row's time is the ink, and its count is said, "2 new", in grey (.messages-unread below). */ .messages-row-time-unread { color: var(--text-primary); font-weight: 600; } .messages-group-tag { display: inline-flex; align-items: center; gap: 3px; height: 22px; margin-left: 6px; padding: 0 8px; border-radius: 9999px; color: var(--text-muted); background: var(--bg-tertiary); font-size: 12px; font-weight: 600; vertical-align: 2px; } /* NEW TO READ, SAID ON THE ROW (#18): "2 new" in grey at the preview's end, where a blue bubble with a bare number was. A full row says its count in words (the shell's rule); bare numbers are for tabs and the sidebar's compact rows, and grey there too. */ .messages-unread { flex: 0 0 auto; margin-left: 8px; color: var(--text-muted); font-size: 13px; font-weight: 650; line-height: 18px; white-space: nowrap; } .messages-network-banner { flex: 0 0 auto; margin: 0 16px 8px; padding: 8px 12px; border-radius: 12px; color: #92400e; background: #fef3c7; font-size: 13px; text-align: center; } .dark .messages-network-banner { color: #fde68a; background: #451a03; } /* The empty and loading states, at the language's type scale. The list's empty state is a white card on the strip with a filled pill; "Choose a conversation" (desktop only — below 768px the list IS the screen until you pick a row) is the same words standing on the strip where the sheet would be, because a card there would read as a conversation with nothing in it. */ .messages-state, .messages-empty, .messages-thread-empty, .messages-no-selection { display: flex; align-items: center; justify-content: center; flex-direction: column; gap: 8px; padding: 24px; color: var(--text-muted); font-size: 15px; text-align: center; } .messages-state, .messages-thread-empty { min-height: 180px; } .messages-empty { margin: 8px 16px 0; padding: 36px 24px; border-radius: 20px; background: var(--messages-surface); } .messages-empty h3, .messages-no-selection h2 { color: var(--text-primary); font-size: 20px; font-weight: 700; } .messages-empty p, .messages-no-selection p { max-width: 22rem; } .messages-thread-empty > span { font-size: 32px; } .messages-empty button, .messages-state button { display: inline-flex; align-items: center; height: 44px; margin-top: 8px; padding: 0 20px; border-radius: 9999px; background: var(--accent); color: var(--accent-ink); font-size: 17px; font-weight: 600; } .messages-empty button:hover, .messages-state button:hover { background: var(--accent-light); } .messages-state-error { color: #dc2626; } .messages-spinner { width: 20px; height: 20px; border: 2px solid var(--border); border-top-color: var(--accent); border-radius: 9999px; animation: messages-spin .7s linear infinite; } @keyframes messages-spin { to { transform: rotate(360deg); } } /* The sheet's title row: who the conversation is with, its context line, and the actions as discs. No hairline under it — the transcript's first day label is what separates it, the way the dev session's header sits over its transcript. */ .messages-thread-header { display: flex; align-items: center; flex: 0 0 auto; gap: 12px; padding: 14px 16px 8px; } .messages-thread-name, .messages-thread-sub { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .messages-thread-name { color: var(--text-primary); font-size: 17px; font-weight: 700; } /* #5329: a change title that opens the Details sheet — a reset button that reads as the heading it sits in, underlined only on hover. */ .messages-thread-name-link { appearance: none; border: 0; background: none; padding: 0; margin: 0; font: inherit; color: inherit; cursor: pointer; max-width: 100%; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .messages-thread-name-link:hover { text-decoration: underline; text-underline-offset: 3px; } .messages-thread-name-link:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; } .messages-thread-sub { color: var(--text-muted); font-size: 15px; } .messages-thread-menu { position: absolute; z-index: 30; top: calc(100% + 6px); right: 0; width: 220px; padding: 6px; border-radius: 16px; background: var(--messages-surface); box-shadow: 0 12px 30px rgba(0, 0, 0, .18); } .messages-thread-menu button { display: block; width: 100%; padding: 10px 12px; border-radius: 10px; color: var(--text-primary); font-size: 15px; text-align: left; } .messages-thread-menu button:hover { background: var(--messages-surface-2); } /* A pending invitation, inside the sheet above the (empty) transcript: a tinted card with the language's filled pills — Accept in the accent, Decline neutral, the block action in the danger tint. */ .messages-invitation { display: flex; align-items: center; gap: 12px; flex: 0 0 auto; margin: 0 16px 8px; padding: 12px 16px; border-radius: 16px; background: var(--accent-tint); font-size: 15px; } .messages-invitation strong { display: block; color: var(--accent); font-size: 17px; } /* #3228: the invited group's name and member count, the card's one bold line. */ .messages-invitation .messages-invitation-group { font-weight: 600; color: var(--text-primary); } .messages-invitation p { margin-top: 2px; color: var(--text-muted); } .messages-invitation [role="alert"] { display: block; margin-top: 4px; color: #dc2626; } .messages-invite-actions { display: flex; flex-wrap: wrap; justify-content: flex-end; gap: 8px; } .messages-invite-decline, .messages-invite-block, .messages-invite-accept { display: inline-flex; align-items: center; justify-content: center; height: 40px; padding: 0 16px; border-radius: 9999px; font-size: 15px; font-weight: 600; transition: background 150ms; } .messages-invite-decline { color: var(--text-primary); background: var(--bg-tertiary); } .messages-invite-block { color: #dc2626; background: rgba(220, 38, 38, .1); } .messages-invite-accept { color: var(--accent-ink); background: var(--accent); } .messages-invite-accept:hover { background: var(--accent-light); } .messages-invite-decline:disabled, .messages-invite-block:disabled, .messages-invite-accept:disabled { opacity: .55; } .messages-thread-scroll { padding: 4px 0 6px; } .messages-day { padding: 10px 0 6px; color: var(--text-muted); font-size: 15px; text-align: center; } .messages-load-older { display: inline-flex; align-items: center; height: 32px; padding: 0 14px; border-radius: 9999px; color: var(--text-primary); background: var(--bg-tertiary); font-size: 13px; font-weight: 500; } /* ── The named-row transcript (a group) ────────────────────────────────── The app chat's shape: square avatar, bold name, muted time, flat text. */ .messages-message { position: relative; display: flex; align-items: flex-start; gap: 12px; padding: 8px 16px; } /* A message in flight is drawn at once, faded, and changes nothing else (#2907): no spinner, no "sending…" line, so confirming it moves no row. The fade lifts when the server has it. */ .messages-message { transition: opacity .15s ease-out; } .messages-message-pending { opacity: .55; } .messages-message-failed { background: rgba(239, 68, 68, .06); } .messages-message-meta.messages-message-failed-note { display: flex; align-items: baseline; gap: 12px; padding: 2px 0 0; } .messages-message-failed-note button { color: var(--accent); font-weight: 600; text-decoration: underline; text-underline-offset: 2px; } .messages-message-failed-note button.messages-discard { color: var(--text-muted); font-weight: 400; } .messages-message-head { display: flex; flex-wrap: wrap; align-items: baseline; gap: 0 8px; min-width: 0; min-height: 22px; color: var(--text-primary); font-size: 17px; font-weight: 700; } .messages-message-head time, .messages-message-head time ~ span { color: var(--text-muted); font-size: 15px; font-weight: 400; white-space: nowrap; } /* QA 2026-09-24 Q22: a long name gives way before the time does. The name takes what the line has left, up to its own width, and ends in an ellipsis rather than breaking at a hyphen; the time never wraps inside itself. The 6em basis is the point at which they stop sharing a line — below it the time drops to a second line of the head instead of squeezing the name to a stub. */ .messages-message-author { flex: 1 1 6em; min-width: 0; max-width: max-content; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } /* A platform event in #general (a proposal up for a vote, a merge): the platform's own line, so it reads as a notice rather than a person — the words muted, the author plain, and the proposal's card under it. */ .messages-message-system .messages-message-author { color: var(--text-muted); } .messages-message-system .messages-markdown.gc-msg-content { color: var(--text-secondary); } /* The body at the language's reading size. Doubled up with .gc-msg-content because format.tsx puts both classes on the node — that one is the markdown vocabulary (its list, code and table rules), and it sets 13px later in this file, which a bare .messages-markdown would lose to. */ .messages-markdown.gc-msg-content { color: var(--text-primary); font-size: 17px; line-height: 1.3; overflow-wrap: anywhere; } .messages-markdown a { color: var(--accent); text-decoration: underline; } /* #3770: `#N` and `PR#N` chips in a message (channels.ts decorateRefs). Here no drawer opens from them as in the app chat, so a chip is a link only when the message names its project (the Homeroom bot's), and then it is a real one, opening that request. Any other is drawn as text: no pointer, no underline under it. The issue ink is --state-ok, which in dark is the chip's own emerald; in light the emerald read at 1.6:1 on the sheet, and on a lighter wash the green reads at 4.5:1. */ .messages-markdown .gc-ref-issue { color: var(--state-ok); } html:not(.dark) .messages-markdown .gc-ref-issue { background: rgba(16, 185, 129, 0.05); } /* One request, one story: in the bot's own words a request's number wears its tag's hue (frontend/src/features/messages/bot-request.ts), the same as in the activity drawer, the chat's rows and its thread's header. The `html` prefix outranks the light wash above. */ html .messages-markdown .gc-ref-issue.gc-ref-request { color: hsl(var(--req-h) 70% 26%); background: hsl(var(--req-h) 80% 92%); font-weight: 600; } html.dark .messages-markdown .gc-ref-issue.gc-ref-request { color: hsl(var(--req-h) 80% 82%); background: hsl(var(--req-h) 35% 25%); } .messages-markdown a.gc-ref { text-decoration: none; } .messages-markdown span.gc-ref { cursor: auto; } @media (hover: hover) { .messages-markdown a.gc-ref:hover { text-decoration: underline; } .messages-markdown span.gc-ref:hover { filter: none; text-decoration: none; } } /* A CONTINUATION LINE (#2783): the same person again, close behind their last message. No avatar and no name — the time of day sits in the 36px column the avatar would, muted, and only on hover (always on touch), which is Discord's arrangement. */ .messages-message-grouped { padding-top: 1px; padding-bottom: 1px; } .messages-message-gutter { flex: 0 0 36px; width: 36px; padding-top: 4px; text-align: right; font-size: 11px; line-height: 1.4; color: var(--text-muted); visibility: hidden; } .messages-message-grouped:hover .messages-message-gutter { visibility: visible; } @media (hover: none) { .messages-message-gutter { visibility: visible; } } /* ── The bot's change blocks (#4564) ──────────────────────────────────── In the chat with Homeroom bot, everything it says about one change is one outlined block led by that change's card: the same hairline and rounding the cards already wear (20px, one hairline, no fill, so the cards inside keep their own surface), drawn around them. The rows keep every part of a row they had — their id, their data, their action bar — and only the outline and the vertical padding between them change, so the line runs unbroken where one row continues into the next. The part classes sit on the row (message-row.tsx); the box they draw is its content column, which is where the cards already stop (`.messages- object-list`'s 480px, plus this padding). The phone's row padding (the @media rule above for .messages-message) stays: a narrow column keeps the same 12px inside the line. */ .messages-bot-block-body { max-width: 506px; padding: 0 12px; border-left: 1px solid var(--app-sheet-line); border-right: 1px solid var(--app-sheet-line); } .messages-bot-block-first .messages-bot-block-body, .messages-bot-block-only .messages-bot-block-body { border-top: 1px solid var(--app-sheet-line); border-radius: 20px 20px 0 0; padding-top: 10px; } .messages-bot-block-last .messages-bot-block-body, .messages-bot-block-only .messages-bot-block-body { border-bottom: 1px solid var(--app-sheet-line); border-radius: 0 0 20px 20px; padding-bottom: 10px; } .messages-bot-block-only .messages-bot-block-body { border-radius: 20px; } .messages-bot-block-first, .messages-bot-block-only { margin-top: 6px; } /* The row's own vertical padding gives way where the block continues, so the outline is unbroken from the top of its first row to the foot of its last. */ .messages-bot-block-first, .messages-bot-block-middle { padding-bottom: 0; } .messages-bot-block-middle, .messages-bot-block-last { padding-top: 0; } /* ── The bubble transcript (a direct conversation) ─────────────────────── Two participants, one of them you, so side and surface say who is speaking and no name is drawn. Theirs is an opaque white bubble on the left; yours is on the right in the accent as a TINT — the same 8% the dev chat gives your turns, with the page's own ink, so a quoted reply or a link inside it keeps its normal colours and no inverted token is needed. The gutter is the cue; the tint confirms it. */ .messages-message-bubble { flex-direction: column; align-items: flex-start; gap: 6px; padding: 4px 16px; } .messages-message-bubble.messages-message-self { align-items: flex-end; } .messages-bubble-wrap { position: relative; display: flex; flex-direction: column; align-items: inherit; max-width: 78%; min-width: 0; } .messages-bubble { min-width: 0; border-radius: 20px; padding: 10px 16px; color: var(--text-primary); background: var(--messages-surface); font-size: 17px; line-height: 1.3; overflow-wrap: anywhere; } .messages-message-self .messages-bubble { background: var(--accent-tint); } .messages-message-bubble .messages-attachments, .messages-message-bubble .messages-object-list { width: 100%; max-width: 78%; } .messages-message-meta { padding: 0 6px; color: var(--text-muted); font-size: 13px; } /* ── The hover bar (#2387) ────────────────────────────────────────────── Every chat row's controls in one floating pill, Discord's shape: the three recent reactions, a divider, then the picker, Reply, Save and ⋯. It sits on the row's top edge at the trailing side, half over the row above, so it never covers the text it acts on. Hover-revealed on a pointer (and on focus-within, for the keyboard); on a touch screen it is not drawn at all and a long press opens the sheet (.msgx-sheet) instead. The shared parts are the `.msgx-*` rules in the next section; this is where the Messages row places it. */ .messages-message-actions { position: absolute; z-index: 6; top: -16px; right: 16px; display: none; } .messages-message:hover .messages-message-actions, .messages-message:focus-within .messages-message-actions, .messages-message-actions.msgx-bar-open { display: flex; } /* The tray of a message still in flight keeps its place but draws nothing (#2907) — on touch it is a line of the row, and growing it only once the send confirmed moved every row under it. */ .messages-message-actions.messages-message-actions-reserved { visibility: hidden; } /* A saved message carries the accent as an inset bar down its row (#1280), so it reads as saved without being hovered; the bar's bookmark is solid and accented while the pill is up. */ .messages-message-saved:not(.messages-message-bubble) { box-shadow: inset 3px 0 0 var(--accent); } /* The app chat's rows place the same bar (#2387): on the row's top edge, trailing side, over the row above, revealed on hover and focus-within. The row's own actions slot is in the header's flow, so the host takes no width and the bar floats out of it. */ .gc-msg { position: relative; } .gc-msg-bar-host { display: contents; } .gc-msg-actions { position: absolute; z-index: 6; top: -16px; right: 16px; display: none; } .gc-msg:hover .gc-msg-actions, .gc-msg:focus-within .gc-msg-actions, .gc-msg-actions.msgx-bar-open { display: flex; } .gc-msg-deleted-text { color: var(--text-muted); font-size: 15px; font-style: italic; } .gc-reply-count { display: flex; align-items: center; gap: 10px; padding: 4px 16px 8px; color: var(--text-muted); font-size: 13px; } .gc-reply-count::after { content: ''; flex: 1 1 auto; height: 1px; background: var(--border-light); } /* ── The message actions, shared (#2387) ───────────────────────────────── The pill, the ⋯ menu, the emoji picker and the phone's long-press sheet, drawn identically on the Messages screen and in an app's chat (frontend/src/features/message-actions/). Floating surfaces take the dense float fill (#2887), so what is under them never shows through. */ .msgx-bar { align-items: center; gap: 2px; padding: 3px; border: 1px solid var(--border-light); border-radius: 12px; background: var(--dc-float-fill); -webkit-backdrop-filter: var(--dc-frost); backdrop-filter: var(--dc-frost); box-shadow: 0 4px 14px rgba(0, 0, 0, 0.1); } .dark .msgx-bar { box-shadow: 0 4px 14px rgba(0, 0, 0, 0.45); } .msgx-bar > button { display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 32px; padding: 0; border: 0; border-radius: 8px; color: var(--text-secondary); background: transparent; cursor: pointer; transition: background 120ms, color 120ms; } .msgx-bar > button:hover, .msgx-bar > button:focus-visible { color: var(--text-primary); background: var(--msgx-hover, rgba(10, 10, 10, 0.06)); outline: none; } .dark .msgx-bar > button:hover, .dark .msgx-bar > button:focus-visible { background: rgba(255, 255, 255, 0.1); } .msgx-bar > button svg { display: block; width: 18px; height: 18px; } .msgx-bar-emoji { font-size: 18px; line-height: 1; } .msgx-bar-emoji:hover { transform: scale(1.12); } .msgx-bar > .msgx-bar-emoji-on { background: var(--accent-wash); } .msgx-bar > .msgx-bar-icon-on { color: var(--text-primary); background: rgba(10, 10, 10, 0.06); } .dark .msgx-bar > .msgx-bar-icon-on { background: rgba(255, 255, 255, 0.1); } .msgx-bar > .msgx-bar-icon-accent, .msgx-bar > .msgx-bar-icon-accent:hover { color: var(--accent); } .msgx-bar-divider { width: 1px; height: 20px; margin: 0 3px; background: var(--border-light); } @media (prefers-reduced-motion: reduce) { .msgx-bar-emoji:hover { transform: none; } } /* The ⋯ menu and the picker hang off the pill: below it, or above when the row is near the foot of the transcript (placementFor). */ .msgx-menu, .msgx-picker { position: absolute; z-index: 30; right: 0; border-radius: 14px; background: var(--dc-float-fill); -webkit-backdrop-filter: var(--dc-frost); backdrop-filter: var(--dc-frost); box-shadow: 0 10px 28px rgba(0, 0, 0, 0.18), 0 0 0 1px var(--border-light); } .msgx-menu-below, .msgx-picker-below { top: calc(100% + 6px); } .msgx-menu-above, .msgx-picker-above { bottom: calc(100% + 6px); } .msgx-menu { display: flex; flex-direction: column; min-width: 14rem; padding: 4px; } .msgx-menu-item { display: flex; align-items: center; gap: 10px; width: 100%; padding: 8px 10px; border: 0; border-radius: 10px; color: var(--text-primary); background: transparent; font: inherit; font-size: 14px; text-align: left; white-space: nowrap; cursor: pointer; } .msgx-menu-item:hover, .msgx-menu-item:focus-visible { background: rgba(10, 10, 10, 0.06); outline: none; } .dark .msgx-menu-item:hover, .dark .msgx-menu-item:focus-visible { background: rgba(255, 255, 255, 0.1); } .msgx-menu-item:disabled { opacity: 0.45; cursor: default; } .msgx-menu-glyph { flex: 0 0 auto; width: 17px; height: 17px; color: var(--text-muted); } .msgx-menu-danger, .msgx-menu-danger .msgx-menu-glyph { color: #c81e1e; } .dark .msgx-menu-danger, .dark .msgx-menu-danger .msgx-menu-glyph { color: #f87171; } .msgx-menu-rule { height: 1px; margin: 4px 8px; background: var(--border-light); } .msgx-picker { display: flex; flex-direction: column; gap: 8px; width: 344px; max-width: calc(100vw - 24px); padding: 10px; box-sizing: border-box; } .msgx-picker-inline { position: static; width: 100%; max-width: none; padding: 0; background: transparent; box-shadow: none; -webkit-backdrop-filter: none; backdrop-filter: none; } .msgx-picker-search { display: flex; align-items: center; gap: 8px; height: 36px; padding: 0 10px; border-radius: 10px; color: var(--text-faint); background: var(--bg-secondary); } .msgx-picker-search input { flex: 1 1 auto; min-width: 0; border: 0; outline: none; color: var(--text-primary); background: transparent; font: inherit; font-size: 14px; } .msgx-picker-tabs { display: flex; justify-content: space-between; } .msgx-picker-tab { display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 30px; border: 0; border-radius: 8px; color: var(--text-muted); background: transparent; cursor: pointer; } .msgx-picker-tab:hover { color: var(--text-primary); } .msgx-picker-tab-active { color: var(--accent-wash-ink); background: var(--accent-wash); } .msgx-picker-scroll { height: 264px; overflow-y: auto; overscroll-behavior: contain; } .msgx-picker-inline .msgx-picker-scroll { height: min(46vh, 340px); } .msgx-picker-head { margin: 6px 2px 4px; color: var(--text-muted); font-size: 11px; font-weight: 700; letter-spacing: 0.04em; text-transform: uppercase; } .msgx-picker-grid { display: grid; grid-template-columns: repeat(8, minmax(0, 1fr)); gap: 2px; } .msgx-picker-emoji { height: 36px; padding: 0; border: 0; border-radius: 8px; background: transparent; font-size: 22px; line-height: 1; cursor: pointer; } .msgx-picker-emoji:hover, .msgx-picker-emoji:focus-visible { background: var(--bg-secondary); outline: none; } .msgx-picker-empty { padding: 24px 8px; color: var(--text-muted); font-size: 14px; text-align: center; } .msgx-picker-foot { display: flex; align-items: center; gap: 8px; min-height: 24px; padding: 2px 2px 0; border-top: 1px solid var(--border-light); color: var(--text-muted); font-size: 13px; } .msgx-picker-foot-emoji { font-size: 20px; } /* The phone's sheet: a scrim, and a sheet rising from the bottom edge. */ .msgx-sheet-layer { position: fixed; z-index: 2100; inset: 0; } .msgx-sheet-scrim { position: absolute; inset: 0; border: 0; background: rgba(0, 0, 0, 0.32); } .msgx-sheet { position: absolute; left: 0; right: 0; bottom: 0; display: flex; flex-direction: column; gap: 12px; max-height: 88vh; padding: 8px 16px calc(16px + var(--platform-safe-bottom, 0px)); overflow-y: auto; border-radius: 20px 20px 0 0; background: var(--dc-sheet-raise); box-shadow: 0 -8px 30px rgba(0, 0, 0, 0.2); outline: none; animation: msgx-sheet-in 180ms ease-out; } @keyframes msgx-sheet-in { from { transform: translateY(24px); opacity: 0.6; } to { transform: none; opacity: 1; } } @media (prefers-reduced-motion: reduce) { .msgx-sheet { animation: none; } } .msgx-sheet-grabber { align-self: center; width: 36px; height: 5px; border-radius: 3px; background: var(--border); } .msgx-sheet-preview { overflow: hidden; color: var(--text-muted); font-size: 15px; text-overflow: ellipsis; white-space: nowrap; } .msgx-sheet-preview strong { color: var(--text-primary); } .msgx-sheet-reactions { display: flex; gap: 10px; } .msgx-sheet-emoji { display: inline-flex; align-items: center; justify-content: center; width: 52px; height: 52px; border: 0; border-radius: 9999px; color: var(--text-secondary); background: var(--bg-secondary); font-size: 26px; line-height: 1; } .msgx-sheet-emoji-on { background: var(--accent-wash); } .msgx-sheet-list { display: flex; flex-direction: column; overflow: hidden; border-radius: 14px; background: var(--bg-secondary); } .msgx-sheet-item { display: flex; align-items: center; gap: 14px; min-height: 48px; padding: 0 16px; border: 0; box-shadow: inset 0 -1px 0 var(--border-light); color: var(--text-primary); background: transparent; font: inherit; font-size: 17px; text-align: left; } .msgx-sheet-item:last-child { box-shadow: none; } .msgx-sheet-item-separated { margin-top: 10px; border-top: 10px solid var(--dc-sheet-raise); } .msgx-sheet-glyph { flex: 0 0 auto; width: 20px; height: 20px; color: var(--text-muted); } .msgx-sheet-danger, .msgx-sheet-danger .msgx-sheet-glyph { color: #c81e1e; } .dark .msgx-sheet-danger, .dark .msgx-sheet-danger .msgx-sheet-glyph { color: #f87171; } /* No hover, no bar: a long press opens the sheet. */ @media (hover: none) { .msgx-bar { display: none !important; } } /* The quoted reply above a message, and the composer's staged-reply chip: one border, one author line, one snippet line, drawn twice on purpose so staging a reply looks like what it is about to produce. */ .messages-quote, .messages-reply-draft { width: 100%; min-width: 0; border-left: 3px solid var(--accent); padding: 2px 10px; color: var(--text-muted); font-size: 15px; text-align: left; } .messages-quote { margin: 0 0 6px; } .messages-quote span, .messages-reply-draft span { display: block; color: var(--accent); font-weight: 700; } .messages-quote p, .messages-reply-draft p { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } /* #3624: the Homeroom bot's messages. Its name carries a small "Bot" badge; a question it asks carries its suggested answers as pills in the suggestion language Global Chat uses (the default first, marked), a "Something else" pill in the neutral fill, and one muted line saying the answer is posted publicly on the request. */ .messages-bot-badge { display: inline-flex; align-items: center; height: 18px; padding: 0 6px; border-radius: 6px; color: var(--text-secondary); background: var(--dc-raised); font-size: 11px; font-weight: 700; letter-spacing: .02em; } .messages-bot-question { margin-top: 8px; } .messages-bot-answers { display: flex; flex-wrap: wrap; align-items: center; gap: 7px; } .messages-bot-answers button { display: inline-flex; align-items: center; gap: 6px; min-height: 36px; max-width: 100%; padding: 6px 13px; border-radius: 9999px; color: var(--brand-ink); background: var(--brand-tint); font-size: 13px; font-weight: 650; line-height: 1.2; text-align: left; } .messages-bot-answers button:hover { filter: brightness(.97); } .messages-bot-answers .messages-bot-other, .messages-bot-answers .messages-bot-secondary { color: var(--text-secondary); background: var(--dc-raised); } /* #3770: an offer's File it is the act, filled in the accent as Accept is; its Not now takes the neutral fill above. */ .messages-bot-answers .messages-bot-primary { color: var(--accent-ink); background: var(--accent); } .messages-bot-answers .messages-bot-primary:hover { filter: none; background: var(--accent-light); } /* #4046: "Notify me when it's ready" under the plan: an action in the accent's tint, quieter than the plan's Build it. */ .messages-bot-answers .messages-bot-tint { color: var(--accent-tint-ink); background: var(--accent-tint); } /* Tapped, it turns grey and says so, with a check: settled, not pressable. */ .messages-bot-answers .messages-bot-done { color: var(--text-muted); background: var(--dc-raised); cursor: default; filter: none; } /* Run six: a first version's "We'll tell you when it's live", on. Settled, so grey with a check as Done is; but a switch, so a tap turns it off. */ .messages-bot-answers .messages-bot-on { color: var(--text-muted); background: var(--dc-raised); } /* B6: an answer tapped as a choice (a plan's, or one of two questions) takes the same accent fill. Nothing is sent until Build it. */ .messages-bot-answers button[aria-pressed="true"] { color: var(--accent-ink); background: var(--accent); } .messages-bot-answers button[aria-pressed="true"]:hover { filter: none; background: var(--accent-light); } .messages-bot-default { font-size: 11px; font-weight: 600; opacity: .7; } .messages-bot-answered { margin-top: 4px; color: var(--text-muted); font-size: 13px; } /* #4197: a question once answered: its words as a small label, the answer under it as the tapped answer's accent pill, drawn as a chip (it is not a button any more). Only the answer chosen; the other options go. */ .messages-bot-choices { display: flex; flex-direction: column; gap: 8px; margin: 0; } .messages-bot-choices dd { margin: 0; } .messages-bot-choice-label { margin-bottom: 4px; color: var(--text-muted); font-size: 12px; font-weight: 600; line-height: 1.3; } .messages-bot-chosen { display: inline-flex; align-items: center; max-width: 100%; min-height: 32px; padding: 6px 13px; border-radius: 9999px; color: var(--accent-ink); background: var(--accent); font-size: 13px; font-weight: 650; line-height: 1.2; overflow-wrap: anywhere; } /* #4197: Build it pressed: a check, then "Building it". */ .messages-bot-done { display: flex; align-items: center; gap: 5px; } /* B5: the bot's hello, above the first card it sends somebody. */ .messages-bot-hello { margin: 0 0 6px; } .messages-bot-note { display: flex; align-items: flex-start; gap: 5px; margin-top: 6px; color: var(--text-muted); font-size: 12px; line-height: 1.35; } .messages-bot-note svg { margin-top: 1px; } .messages-reply-draft .messages-bot-note { display: block; white-space: normal; } /* Reaction pills, the language's own: a filled neutral chip, and the one that is YOURS on a tinted accent ground with accent ink — a fill, not an outline, because a bordered pill among filled ones reads as a different component rather than a different state. */ .messages-reactions { display: flex; flex-wrap: wrap; gap: 6px; } .messages-message:not(.messages-message-bubble) .messages-reactions { margin-top: 8px; } .messages-reactions button { display: inline-flex; align-items: center; gap: 6px; height: 32px; padding: 0 12px; border-radius: 9999px; color: var(--text-primary); background: var(--bg-tertiary); font-size: 15px; font-weight: 500; transition: background 150ms; } .messages-reactions button:hover { background: var(--border); } .messages-reactions .messages-reaction-mine { color: var(--accent-wash-ink); background: var(--accent-wash); } .messages-edit textarea { width: 100%; min-height: 56px; /* #1408: the ceiling lib/use-auto-grow.ts grows into. Taller than the composer's because an edit box holds a message that already exists — it starts full rather than empty, so stopping it at the composer's height would put most edits behind a scrollbar immediately. */ max-height: 260px; margin-top: 3px; border: 1px solid var(--accent-light); border-radius: 14px; padding: 9px 12px; color: var(--text-primary); background: var(--messages-surface); font-size: 17px; line-height: 1.3; /* `resize: vertical` stays: the grow is a floor on convenience, not a ceiling on choice, and a hand-dragged height is a deliberate act the next keystroke should not undo. */ resize: vertical; overflow-y: auto; } .messages-edit > div { display: flex; gap: 12px; margin-top: 6px; } .messages-edit button { color: var(--accent); font-size: 15px; font-weight: 600; } .messages-report { display: grid; gap: 8px; width: 100%; max-width: 26rem; border-radius: 16px; padding: 12px; background: var(--messages-surface); } .messages-message:not(.messages-message-bubble) .messages-report { margin-top: 8px; } .messages-report label { display: grid; gap: 4px; color: var(--text-secondary); font-size: 13px; font-weight: 600; } .messages-report select, .messages-report textarea { width: 100%; border: 1px solid var(--border-light); border-radius: 10px; padding: 8px 10px; color: var(--text-primary); background: var(--bg-input); font-size: 15px; } .messages-report textarea { resize: vertical; } .messages-report > div { display: flex; gap: 12px; } .messages-report button { color: var(--accent); font-size: 15px; font-weight: 600; } .messages-report button:disabled { opacity: .55; } /* Files and shared items: the language's cards — white, rounded, no border, a neutral glyph tile leading. */ .messages-attachments, .messages-object-list { display: grid; gap: 6px; max-width: 480px; } .messages-message:not(.messages-message-bubble) .messages-attachments, .messages-message:not(.messages-message-bubble) .messages-object-list { margin-top: 8px; } .messages-attachment, .messages-object-card, .messages-pending-object { display: flex; align-items: center; gap: 12px; min-width: 0; border-radius: 16px; padding: 10px 12px; color: var(--text-primary); background: var(--messages-surface); font-size: 15px; text-decoration: none; transition: background 150ms; } .messages-attachment img { width: 160px; max-height: 120px; border-radius: 10px; object-fit: cover; } .messages-attachment span { color: var(--text-muted); font-size: 13px; } .messages-file-icon, .messages-object-icon { display: inline-flex; align-items: center; justify-content: center; flex: 0 0 auto; width: 40px; height: 40px; border-radius: 12px; color: var(--text-primary); background: var(--messages-surface-2); font-size: 17px; font-weight: 700; } .messages-attachment-view { color: var(--accent); font-size: 13px; font-weight: 600; } .messages-object-card:hover { background: var(--messages-surface-2); } .messages-object-unavailable { opacity: .6; } /* #3660: a Homeroom link's card under a message in an app's discussion (features/messages/link-cards.tsx). That transcript is drawn on the app's own pages as well as in this inbox — outside .messages-layout, where the card's two surfaces are not defined — so there it wears the surface the discussion's own boxes do (.gc-event-box): the frosted sheet fill and its hairline. */ .gc-msg .messages-link-embeds { margin-top: 6px; } .gc-msg .messages-link-embeds .messages-object-card { background-color: var(--dc-sheet-fill); box-shadow: 0 0 0 1px var(--app-sheet-line) inset; } .gc-msg .messages-link-embeds .messages-object-card:hover { background-color: var(--bg-tertiary); } .gc-msg .messages-link-embeds .messages-object-icon { background: var(--bg-tertiary); } /* #2884: under the first card of a folded run, in the column the message writes in (16px inset + 36px avatar + 12px gap). */ .messages-card-run { padding: 0 16px 6px 64px; } .messages-typing { flex: 0 0 auto; min-height: 18px; padding: 2px 20px; color: var(--text-muted); font-size: 13px; } /* ── The composer ──────────────────────────────────────────────────────── One white card at the foot of the sheet: bare glyphs, a borderless field at reading size, and the round accent send disc the dev chat draws. The BAR around the card is what carries the home-indicator inset (`platform-safe-bar`), so on a notched phone the gap under the card grows and the card itself does not. */ .messages-composer, .messages-composer-disabled { position: relative; flex: 0 0 auto; padding: 6px 12px 8px; } .messages-composer-card { border-radius: 22px; padding: 8px 8px 8px 12px; background: var(--messages-surface); box-shadow: var(--messages-disc-shadow); transition: box-shadow 150ms; } /* #1954: FOCUS LIVES ON THE CARD, as it does on the dev chat's `.dc-card`. The textarea draws no box of its own (`outline: none`, transparent), so a caret was the only sign the field was live; the ring goes around the whole input box instead. `:focus-within` because the card is one control group — the attach and share buttons are still "in the composer". */ .messages-composer-card:focus-within { box-shadow: var(--messages-disc-shadow), 0 0 0 2px var(--accent); } @media (prefers-reduced-motion: reduce) { .messages-composer-card { transition: none; } } .messages-composer-disabled { padding: 14px 16px; color: var(--text-muted); font-size: 15px; text-align: center; } /* QA 2026-09-24 Q2: a direct request the other person has not accepted yet. Before the opening message, one muted line over the card says what it will be; after it, the card itself gives way to the invitation banner's tinted panel, which names who the thread is waiting for. */ .messages-composer-hint { margin: 0 4px 6px; color: var(--text-muted); font-size: 13px; line-height: 1.35; } .messages-awaiting { padding: 12px 16px; border-radius: 16px; background: var(--accent-tint); font-size: 15px; line-height: 1.35; } .messages-awaiting strong { display: block; color: var(--accent); font-size: 15px; font-weight: 600; } .messages-awaiting p { margin-top: 2px; color: var(--text-muted); } .messages-composer-input { flex: 1 1 auto; min-width: 0; max-height: 140px; min-height: 40px; border: 0; border-radius: 0; padding: 9px 4px; color: var(--text-primary); background: transparent; font-size: 17px; line-height: 22px; outline: none; resize: none; /* #1408: lib/use-auto-grow.ts sets `height` to the content height, and `max-height` above is what stops it. Past that ceiling the extra lines have to be reachable, so the box scrolls rather than clipping them. */ overflow-y: auto; /* #2882: ONE OUTLINE, THE CARD'S. The ring above goes around the whole composer; the field inside it must draw no edge of its own in any engine. `outline: none` covers the focus ring, but WebKit on iOS also paints a native textarea box (a hairline and an inset shade) until the appearance is reset, and a tap flashes its highlight over the field — both read as a second, inner outline around just the text area. */ -webkit-appearance: none; appearance: none; box-shadow: none; -webkit-tap-highlight-color: transparent; } /* #2387: FIREFOX'S RING. Tailwind's preflight ships `:-moz-focusring { outline: auto }`, and tailwind.css loads AFTER this file (the order head.html pins) at the same specificity as `outline: none` above — so in Gecko the later rule won and the field drew its own focus ring, a second rectangle inside the card's. Chromium and WebKit drop the `-moz-` selector, which is why only Firefox showed it. One more class outranks preflight without touching the stylesheet order. */ .messages-composer-card .messages-composer-input { outline: none; } .messages-composer-input::placeholder { color: var(--text-faint); } /* ── The agent session's composer (#2779 follow-up) ────────────────────── The same rule as the card above, for features/agent-session's form: the outline goes around the WHOLE composer card while anything in it has focus (the field, the model pickers, the button), and the field inside draws none of its own. The card keeps its 1px border, so the ring is that border turned accent plus one more pixel outside it: two pixels, as on Messages, with no shift in layout. */ .agent-session-composer { transition: border-color 150ms, box-shadow 150ms; } /* `form.` outranks the card's own `dark:border-zinc-700` (two classes, and tailwind.css loads last), so the dark theme turns accent too. */ form.agent-session-composer:focus-within { border-color: var(--accent); box-shadow: 0 1px 2px rgba(0, 0, 0, 0.05), 0 0 0 1px var(--accent); } @media (prefers-reduced-motion: reduce) { .agent-session-composer { transition: none; } } /* #2882's reset (WebKit's native textarea box and tap flash) and #2387's Firefox fix: preflight's `:-moz-focusring { outline: auto }` loads later at one class's specificity, so the second class here is what keeps Gecko from drawing a ring around the field inside the card's. */ .agent-session-composer .agent-session-composer-input { outline: none; -webkit-appearance: none; appearance: none; box-shadow: none; -webkit-tap-highlight-color: transparent; } /* The Mayor at work (features/agent-session LiveTurn): three dots where its reply will appear, rising in turn. Still dots under reduced motion. */ .agent-session-typing-dot { animation: agent-session-typing 1.2s ease-in-out infinite; } .agent-session-typing-dot:nth-child(2) { animation-delay: 0.15s; } .agent-session-typing-dot:nth-child(3) { animation-delay: 0.3s; } @keyframes agent-session-typing { 0%, 80%, 100% { opacity: 0.35; transform: translateY(0); } 40% { opacity: 1; transform: translateY(-3px); } } @media (prefers-reduced-motion: reduce) { .agent-session-typing-dot { animation: none; opacity: 0.6; } } .messages-composer-action { display: inline-flex; align-items: center; justify-content: center; flex: 0 0 auto; width: 36px; height: 36px; border-radius: 9999px; color: var(--text-secondary); transition: background 150ms; } .messages-composer-action svg { stroke-width: 1.8; } .messages-composer-action:hover { background: var(--messages-surface-2); } .messages-composer-action:disabled { opacity: .35; } /* #1955 — the one "+" and the two named rows it opens. The wrapper is the positioning context AND the outside-press boundary, so the menu has to live inside it rather than beside the button. */ .messages-composer-add { position: relative; flex: 0 0 auto; } .messages-composer-menu { position: absolute; z-index: 25; bottom: calc(100% + 6px); left: 0; min-width: 176px; padding: 6px; border-radius: 16px; background: var(--messages-surface); box-shadow: 0 -7px 20px rgba(0, 0, 0, .12); } .messages-composer-menu button { display: flex; align-items: center; gap: 10px; width: 100%; /* 40px tall: this is a phone target, and the control it replaced was two 36px circles the width of a fingertip apart. */ padding: 9px 12px; border-radius: 10px; color: var(--text-primary); font-size: 15px; text-align: left; white-space: nowrap; } .messages-composer-menu button svg { width: 18px; height: 18px; stroke-width: 1.8; flex: 0 0 auto; } .messages-composer-menu button:hover:not(:disabled) { background: var(--messages-surface-2); } .messages-composer-menu button:disabled { opacity: .35; } .messages-send { display: inline-flex; align-items: center; justify-content: center; flex: 0 0 auto; width: 40px; height: 40px; border-radius: 9999px; color: var(--accent-ink); background: var(--accent); transition: background 150ms; } .messages-send svg { width: 20px; height: 20px; stroke-width: 2.4; } .messages-send:hover { background: var(--accent-light); } .messages-send:disabled { opacity: .35; } /* #3735: ONE COMPACT LINE ON A PHONE. Below 768px the card is the "+", the field and the send disc on a single 44px row, and it grows only with what is typed, up to the field's 140px ceiling as everywhere. It was about 75px: 8px of padding round a 40px row, plus the character count's line, which is laid out even while empty (composer.tsx says why) and so drew a blank band under the field. On a phone: - the card pads 4px above and below a 36px row, 4 + 36 + 4 = 44, so with its 22px radius it is a pill whose send disc sits concentric in the right-hand cap; - the field is 36px tall (7 + 22 + 7) and keeps its 17px type; - the count's line is not laid out until the text nears the limit, where it appears in amber (`data-near-limit`); #4202 made that true at every width (the rule after this block); - the "+" and the disc are drawn at 36px and stay 44px tap targets, the platform's minimum: a pseudo-element overhangs each by 4px, into the card's padding and the row's 6px gap, and so never over the field. The bar round the card is not touched: the tab bar, home-indicator and keyboard clearances (`.platform-safe-bar`, `.platform-kb-column`) are as they were. From 768px up nothing here applies. */ @media (max-width: 767px) { .messages-composer-card { padding: 4px 4px 4px 8px; } /* A reply, a shared item or files staged above the row keep the 8px the card always had over them: at 4px the reply's square left edge would cross the card's rounded corner. */ .messages-composer-card > .messages-reply-draft:first-child, .messages-composer-card > .messages-pending-object:first-child, .messages-composer-card > .dc-attach-strip:first-child { margin-top: 4px; } .messages-composer-input { min-height: 36px; padding: 7px 4px; } .messages-send { width: 36px; height: 36px; } /* The "+" sits in its menu's wrapper, which as a block would hold it on a text line whose strut can add a few pixels under it: a flex box is exactly the button's height, so the row is the field's 36px. */ .messages-composer-add { display: flex; } .messages-composer-action, .messages-send { position: relative; } .messages-composer-action::after, .messages-send::after { content: ''; position: absolute; inset: -4px; } } /* #4202: THE SAME CARD ON DESKTOP AS AN APP CHANNEL'S. The count's line was laid out on desktop even while empty, a 4px gap and a 15px blank band under the row, so every Messages composer (the Homeroom bot's thread, a DM, a group, #general, a reply thread) stood about 75px against the app channel's 56px (`.gc-composer-card`: 8 + 40 + 8). It is now laid out at every width only once the text nears the limit, where it appears in amber, so the card is that same 8 + 40 + 8. The element stays in the DOM (a declared check selects it). Two selectors' worth of specificity, so it outranks the element's own `flex` although tailwind.css loads later. */ .messages-composer-count:not([data-near-limit]) { display: none; } .messages-reply-draft, .messages-pending-object { margin-bottom: 6px; } .messages-reply-draft { display: flex; align-items: center; border-radius: 0 12px 12px 0; padding: 6px 10px; background: var(--accent-tint); } .messages-pending-object { padding: 8px 12px; background: var(--messages-surface-2); } /* #1927: the dismiss × is a 44px tap target, the platform's minimum. The negative block/inline margins let it overhang the strip's own 6–8px padding, so the bigger button does not make the strip any taller. */ .messages-reply-draft button, .messages-pending-object button { flex: 0 0 auto; display: inline-flex; align-items: center; justify-content: center; margin: -6px -8px -6px auto; width: 44px; height: 44px; border-radius: 9999px; color: var(--text-muted); font-size: 20px; } .messages-mention-menu { position: absolute; z-index: 25; right: 12px; bottom: calc(100% - 3px); left: 12px; max-height: 180px; overflow-y: auto; padding: 6px; border-radius: 16px; background: var(--messages-surface); box-shadow: 0 -7px 20px rgba(0, 0, 0, .12); } .messages-mention-menu button { display: block; width: 100%; padding: 9px 12px; border-radius: 10px; color: var(--text-primary); font-size: 15px; text-align: left; } .messages-mention-menu button:hover { background: var(--messages-surface-2); } /* QA 2026-09-24 Q13: the row the arrow keys have highlighted, which Enter or Tab will pick. A tint of the accent rather than the hover grey, so the keyboard's choice still reads when the pointer is resting on another row. */ .messages-mention-menu button[aria-selected="true"] { background: var(--accent-tint); box-shadow: inset 3px 0 0 var(--accent); } .messages-mention-menu .messages-channel-option-name { color: var(--text-muted); font-size: 13px; } /* `:th` — the emoji shortcode menu (features/messages/composer.tsx). The mention menu's box; the heading stays put while the rows scroll, a row is the glyph beside its `:code:`, and the keyboard's row wears the hover. */ .messages-emoji-menu { max-height: none; overflow: visible; } .messages-emoji-menu-heading { padding: 4px 12px 6px; color: var(--text-muted); font-size: 12px; font-weight: 600; } .messages-emoji-menu-query { color: var(--text-primary); } .messages-emoji-menu-list { max-height: min(288px, 38vh); overflow-y: auto; overscroll-behavior: contain; } .messages-emoji-menu .messages-emoji-menu-list button { display: flex; align-items: center; gap: 10px; padding: 6px 12px; } .messages-emoji-menu .messages-emoji-menu-list button[aria-selected="true"] { background: var(--messages-surface-2); } .messages-emoji-option-glyph { flex: none; width: 24px; font-size: 20px; line-height: 24px; text-align: center; } .messages-emoji-option-code { min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .messages-composer-dragging .messages-composer-card { outline: 2px solid var(--accent); outline-offset: -2px; } .messages-drop-overlay, .attach-drop-overlay { position: absolute; z-index: 30; inset: 4px 12px; display: flex; align-items: center; justify-content: center; border: 2px dashed var(--accent-light); border-radius: 22px; color: var(--accent); background: color-mix(in srgb, var(--messages-surface) 94%, transparent); font-size: 15px; font-weight: 700; pointer-events: none; } /* #4065: the same outline over the other composers. It lies over the card itself rather than the bar around it, so it takes the card's own edges; the card is the positioned parent. `#feedback-form` is "Suggest an improvement", where the whole form is the drop zone. */ .attach-drop-overlay { inset: 0; border-radius: inherit; background: color-mix(in srgb, var(--bg-primary) 94%, transparent); } .gc-composer-card, #gc-form, #gc-thread-form, .dc-card, .agent-session-composer, #feedback-form { position: relative; } #feedback-form > .attach-drop-overlay { inset: -6px; border-radius: 16px; } /* The boxed thread composer inside a board card has no card radius of its own. */ #gc-form:not(.gc-composer-card) > .attach-drop-overlay, #gc-thread-form:not(.gc-composer-card) > .attach-drop-overlay { border-radius: 12px; } /* ── The two panes, and the width they are actually drawn at ──────────── From 768px up both panes sit on the one strip: the list column fixed at 22rem, the sheet rising beside it with its own margin so the strip shows around its shoulders. Below that exactly one pane is rendered at a time (the list until a row is picked, the thread after, the header bar's back arrow between them) and both stay full width. */ @media (min-width: 768px) { .messages-list-pane { flex: 0 0 22rem; width: 22rem; padding-right: 8px; } .messages-thread-pane { flex: 1 1 auto; margin: 14px 12px 0 8px; } .messages-thread-pane.messages-no-selection { margin: 0; } } /* ── Full width (#2387) ───────────────────────────────────────────────── The list folds away on a desktop so the open discussion — and a thread beside it — has the whole strip. The toggle ends every discussion pane's header, just before ⋯ where there is one, and is not drawn below 768px, where one pane is shown at a time anyway. Its glyph says the state (arrows out, arrows in), so it keeps the disc's ink rather than turning accent. */ .messages-list-toggle { display: none; } @media (min-width: 768px) { .messages-list-toggle { display: inline-flex; } .messages-layout.messages-list-collapsed > .messages-list-pane { display: none; } .messages-layout.messages-list-collapsed > .messages-thread-pane { margin-left: 12px; } } /* ── A reply thread beside its chat (#2387) ───────────────────────────── A second sheet on the strip, to the right of the chat, Slack's layout. Below 1600px the list steps aside while a thread is open, so the chat between them keeps a readable measure (a 1360px laptop with the rail open left the chat under 300px wide); on a phone the thread covers the chat entirely and the header bar's back arrow returns to it. */ .messages-reply-pane { position: relative; display: flex; flex-direction: column; min-width: 0; min-height: 0; } .messages-reply-host { display: flex; flex-direction: column; } .messages-reply-host > * { flex: 1 1 auto; min-height: 0; } @media (max-width: 767px) { .messages-layout.messages-has-reply-thread > .messages-thread-pane { display: none; } .messages-reply-pane { flex: 1 1 auto; width: 100%; margin-top: 12px; } /* One way back (polish N16): the header bar's arrow. The thread's own ✕ beside it said the same thing a second time. A community page's copy (`.messages-layout-embedded`) keeps its ✕. */ .messages-layout:not(.messages-layout-embedded) > .messages-reply-pane [data-reply-close] { display: none; } } /* #5691: the divider between a chat and its open thread, dragged to trade room between them. It sits in the 8px the thread pane's own margin leaves (`.messages-reply-pane` is positioned), so the layout never shifts. At rest it is the sheet's hairline; under the pointer or the keyboard it is the accent, as a change session's side pane divider is. Drawn from 768px only, where the two panes are side by side; on a phone the thread covers the chat. */ .messages-reply-resizer { display: none; } @media (min-width: 768px) { .messages-reply-pane { flex: 0 0 var(--messages-reply-width, min(420px, 42%)); margin: 14px 12px 0 0; } /* A community page's embedded copy of a thread (#3653) keeps its own width: the divider is Messages' alone. */ .messages-layout-embedded > .messages-reply-pane { flex-basis: min(420px, 42%); } .messages-layout-embedded > .messages-reply-pane > .messages-reply-resizer { display: none; } .messages-reply-resizer { display: block; position: absolute; left: -7px; top: 0; bottom: 0; width: 6px; z-index: 1; border-radius: 3px; cursor: col-resize; touch-action: none; background: linear-gradient(var(--app-sheet-line), var(--app-sheet-line)) center / 1px 100% no-repeat; } .messages-reply-resizer:hover, .messages-reply-resizer:focus-visible { background: var(--accent, #2563eb); outline: none; } .messages-reply-resizer:focus-visible { outline: 2px solid var(--accent, #2563eb); outline-offset: 1px; } .messages-layout.messages-has-reply-thread > .messages-thread-pane { margin-right: 8px; } } @media (min-width: 768px) and (max-width: 1599px) { .messages-layout.messages-has-reply-thread > .messages-list-pane { display: none; } /* The list is already out of the way; its toggle would do nothing. */ .messages-layout.messages-has-reply-thread .messages-list-toggle { display: none; } .messages-layout.messages-has-reply-thread > .messages-thread-pane { margin-left: 12px; } } .messages-reply-count { display: flex; align-items: center; gap: 10px; padding: 2px 16px 8px; color: var(--text-muted); font-size: 13px; } .messages-reply-count::after { content: ''; flex: 1 1 auto; height: 1px; background: var(--border-light); } .messages-composer-thread .messages-composer-card { box-shadow: var(--messages-disc-shadow); } /* The "N replies · last reply" chip under a message a thread hangs off. */ .msgx-thread-chip { display: inline-flex; align-items: center; gap: 8px; max-width: 100%; margin-top: 6px; padding: 3px 8px 3px 4px; border: 1px solid transparent; border-radius: 10px; color: var(--text-muted); background: transparent; font: inherit; font-size: 13px; cursor: pointer; transition: background 120ms, border-color 120ms; } .msgx-thread-chip:hover, .msgx-thread-chip:focus-visible { border-color: var(--border-light); background: var(--dc-sheet-raise); outline: none; } .msgx-thread-chip-active { border-color: var(--accent-wash); background: var(--accent-wash); } .msgx-thread-faces { display: inline-flex; } .msgx-thread-faces > * { width: 22px !important; height: 22px !important; border-radius: 6px !important; box-shadow: 0 0 0 2px var(--dc-sheet-raise); font-size: 10px !important; } .msgx-thread-faces > * + * { margin-left: -6px; } .msgx-thread-count { color: var(--accent); font-weight: 700; white-space: nowrap; } .msgx-thread-last { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .msgx-thread-chevron { flex: 0 0 auto; width: 14px; height: 14px; opacity: 0; transition: opacity 120ms; } .msgx-thread-chip:hover .msgx-thread-chevron, .msgx-thread-chip:focus-visible .msgx-thread-chevron { opacity: 1; } /* The thread card (#2387 follow-up, Discord's layout): "3 replies ›" over the newest reply, in a white box under the message. `.msgx-thread-chip` stays on it for the selectors that find a thread by it; this block restyles it as the card. */ .msgx-thread-chip.msgx-thread-card, .msgx-thread-activity-card { display: flex; flex-direction: column; align-items: stretch; gap: 6px; width: 100%; max-width: 460px; min-width: 0; box-sizing: border-box; margin-top: 8px; padding: 9px 12px 10px; border: 1px solid var(--border-light); border-radius: 14px; background: var(--dc-sheet-raise); color: var(--text-primary); font: inherit; text-align: left; cursor: pointer; transition: border-color 120ms, box-shadow 120ms; } .msgx-thread-chip.msgx-thread-card:hover, .msgx-thread-chip.msgx-thread-card:focus-visible, .msgx-thread-activity-card:hover, .msgx-thread-activity-card:focus-visible { border-color: var(--accent-wash); background: var(--dc-sheet-raise); box-shadow: 0 1px 3px rgba(0, 0, 0, 0.06); outline: none; } .msgx-thread-activity-card:focus-visible, .msgx-thread-chip.msgx-thread-card:focus-visible { box-shadow: 0 0 0 2px var(--accent); } .msgx-thread-chip.msgx-thread-card.msgx-thread-chip-active { border-color: var(--accent); } .msgx-thread-card-head { display: flex; align-items: center; gap: 6px; font-size: 14px; } .msgx-thread-card-glyph { flex: 0 0 auto; width: 16px; height: 16px; color: var(--accent); } .msgx-thread-card-chevron { flex: 0 0 auto; width: 14px; height: 14px; color: var(--text-muted); } .msgx-thread-line { display: flex; align-items: center; gap: 8px; min-width: 0; font-size: 14px; } .msgx-thread-line > :first-child { flex: 0 0 auto; } .msgx-thread-line-name { flex: 0 0 auto; font-weight: 700; } .msgx-thread-line-text { flex: 1 1 auto; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; color: var(--text-secondary); } .msgx-thread-line-time { flex: 0 0 auto; color: var(--text-muted); font-size: 13px; } /* A thread's replies where they landed in the main transcript (#2387 follow-up): the thread glyph in the column the faces use, then the card. */ .msgx-thread-activity { display: flex; align-items: flex-start; gap: 12px; padding: 2px 16px 6px; } .msgx-thread-activity-glyph { flex: 0 0 36px; display: inline-flex; justify-content: center; padding-top: 18px; color: var(--text-muted); } .msgx-thread-activity-glyph svg { width: 18px; height: 18px; } .msgx-thread-activity-card { margin-top: 0; max-width: 520px; } /* The app chat's faces are 44px wide: the glyph takes the same column, so the card lines up with the messages' text. */ #gc-messages .msgx-thread-activity-glyph { flex-basis: 44px; } .msgx-thread-activity-head { display: flex; align-items: center; gap: 6px; min-width: 0; font-size: 13px; color: var(--text-muted); white-space: nowrap; } .msgx-thread-activity-what { flex: 0 0 auto; } .msgx-thread-activity-root { min-width: 0; overflow: hidden; text-overflow: ellipsis; color: var(--accent); font-weight: 600; } .msgx-thread-activity-root-deleted { color: var(--text-muted); font-style: italic; font-weight: 400; } .msgx-thread-activity-time { flex: 0 0 auto; } .msgx-thread-activity-head .msgx-thread-card-chevron { margin-left: auto; } /* A reply line's face, whichever surface drew it, at the card's 22px. */ .msgx-thread-face { display: inline-flex; flex: 0 0 auto; } .msgx-thread-face > * { width: 22px !important; height: 22px !important; border-radius: 6px !important; font-size: 10px !important; } /* A deleted message keeps its place and says so (#2387). */ .messages-deleted { color: var(--text-muted); font-size: 15px; font-style: italic; } /* A message a link pointed at flashes once (#2387). */ .messages-message-focus { animation: messages-focus-flash 2.4s ease-out; } @keyframes messages-focus-flash { 0%, 30% { background: var(--accent-wash); } 100% { background: transparent; } } @media (prefers-reduced-motion: reduce) { .messages-message-focus { animation: none; background: var(--accent-tint); } } /* A linked page stops short of the present: two ways back to it. */ .messages-newer { display: flex; justify-content: center; gap: 8px; padding: 8px 0; } /* 16 Oct 2026: the agent chats nobody used this week, and the archived ones, behind a quiet link at the foot of Agents. Muted words in the titles' column (16px of padding + the 44px avatar + the 14px gap), and no chevron: a chevron there matched the sections' own folds and read as a third heading. */ .messages-inbox-older { display: block; width: 100%; min-height: 44px; padding: 12px 16px 12px 74px; border: 0; color: var(--text-muted); background: transparent; font: inherit; font-size: 14px; font-weight: 500; text-align: left; cursor: pointer; } .messages-inbox-older:hover, .messages-inbox-older:focus-visible { color: var(--text-primary); text-decoration: underline; outline: none; } /* #2883: THE TRANSCRIPT READS ONE STEP DOWN ON A DESKTOP. 17px is the phone's reading size, and the phone keeps it; beside a 22rem list whose previews and cards are already at 15px, a 17px body and a 17px bold name were the largest text on the screen. So from 768px up a message reads at the size the list's preview line and the shared-item cards use — 15px, with the header's name at 15 and its time at 13, the next step on the same scale — and the composer and the inline editor come down with it, so what you type is the size it will be drawn at. Nothing new on the scale: 17 → 15 → 13. */ @media (min-width: 768px) { .messages-message-head { min-height: 20px; font-size: 15px; } .messages-message-head time, .messages-message-head time ~ span { font-size: 13px; } .messages-markdown.gc-msg-content { font-size: 15px; line-height: 1.4; } .messages-composer-input { font-size: 15px; } .messages-edit textarea { font-size: 15px; } } /* A READABLE MEASURE (N14 of the 19 Oct polish board). A message's text ran the pane's whole width on a desktop: about 1,100px beside the sidebar and 1,380px without it, a hundred and fifty characters a line. From 768px its lines stop at 72 characters; the face, the name line and the cards keep their own widths. A phone is narrower than this already. */ @media (min-width: 768px) { .messages-markdown.gc-msg-content { max-width: 72ch; } } /* ── An app's discussion, as a thread of this inbox (#2718 review) ────── The section is the BOX and features/group-chat draws the sheet inside it, so this adds no fill, no frost and no radius — see the note in the component. All it does is let the host fill the pane, because the sheet inside is `h-full` and a host that collapsed would give it nothing to be the height of. */ /* The agent row's delete, and the confirm that replaces the row (#2718 review). Both came from the Improve panel's own list of these chats, which was the only surface that offered the delete — so it moved here with them rather than retiring with the panel. */ .messages-row-delete { flex: 0 0 auto; display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 32px; border-radius: 9999px; color: var(--text-muted); opacity: 0; transition: opacity 120ms ease, background-color 120ms ease, color 120ms ease; } .messages-conversation-row:hover .messages-row-delete, .messages-row-delete:focus-visible { opacity: 1; } .messages-row-delete:hover { background: var(--messages-surface-2); color: var(--text-primary); } /* Touch has no hover to reveal it with, so it is simply there. */ @media (hover: none) { .messages-row-delete { opacity: 1; } } .messages-row-confirm { gap: 8px; font-size: 14px; color: var(--text-primary); } .messages-row-confirm-cancel, .messages-row-confirm-delete { flex: 0 0 auto; min-height: 36px; padding: 0 10px; border-radius: 8px; font-weight: 600; } .messages-row-confirm-cancel { color: var(--text-muted); } .messages-row-confirm-delete { color: #dc2626; } .dark .messages-row-confirm-delete { color: #f87171; } .messages-discussion-host { display: flex; flex-direction: column; min-height: 0; } .messages-discussion-host > * { flex: 1 1 auto; min-height: 0; } /* ── An agent thread, as a thread of this inbox (#2813) ───────────────── A global agent chat is the chat's own panel drawn on the conversation pane's sheet, so the panel adds no plane of its own. A dev session is DevChat's whole session view in a host, which draws its own sheet — the same arrangement as a discussion above, so the host only has to fill the pane. The bar above it carries what the pane adds: the session's own full-window address, for the spec and preview at full width, and the full-width toggle every discussion pane ends its header with. */ .messages-thread-agent { overflow: hidden; } .global-chat-embedded { flex: 1 1 auto; } /* In the pane the toolbar spans the sheet, as every discussion's header does, and only the transcript and composer keep their reading column — so the full-width toggle at its end stays under the pointer when the pane widens, rather than moving in with a centred column. */ .global-chat-embedded > .global-chat-toolbar { width: 100%; } .messages-session-host { display: flex; flex-direction: column; min-height: 0; } .messages-session-host > * { flex: 1 1 auto; min-height: 0; } .messages-session-host[hidden] { display: none; } .messages-session-bar { display: flex; align-items: center; justify-content: flex-end; gap: 12px; flex: 0 0 auto; padding: 0 4px 6px; } .messages-session-full { font-size: 12px; font-weight: 600; color: var(--text-muted); } .messages-session-full:hover { color: var(--text-primary); } .messages-inbox-session-active > a { background: var(--messages-selected); } /* #5378: A CHANGE IN FLIGHT TAKES THE INBOX'S OWN ROW GEOMETRY on the cards: a conversation row's 16px of padding and 14px gap around the 44px tile, so its tile shares the avatars' left edge and its title their 74px column (where the separators and "N older chats" already sit), in the rows' 15 over 13 (AGENTS.md). ../improve/session-row.tsx is the bell's row too, with Tailwind's own spacing, so this is scoped to the wrapper Messages puts round it; the desktop's one-line column overrides it below. */ .messages-inbox-session > a { min-height: 66px; gap: 14px; padding: 13px 16px; } .messages-inbox-session > a > .min-w-0 > :first-child { font-size: 15px; font-weight: 650; line-height: 20px; } .messages-inbox-session > a > .min-w-0 > :first-child + * { margin-top: 2px; font-size: 13px; line-height: 18px; } /* Phone-width only. Each of these exists because a narrow column cannot lay the row out sideways; the thread pane on a desktop is up to ~59rem and can. */ @media (max-width: 767px) { .messages-invitation { align-items: flex-start; flex-direction: column; } .messages-invitation > div:last-child { align-self: stretch; } .messages-invite-actions { justify-content: stretch; } .messages-invite-decline, .messages-invite-block, .messages-invite-accept { flex: 1 1 auto; } .messages-message { padding-right: 12px; padding-left: 12px; } .messages-attachment img { width: 112px; } } /* ── Global Chat (experimental) ──────────────────────────────────────── A normal hash-routed, React-owned sibling screen. App._showOnlyScreen owns mutual exclusion with the other roots, so this surface needs no body mode or cross-screen inert writes. Each durable session has a #chat/ URL. */ #global-chat-screen { position: relative; z-index: 8; width: 100%; } .global-chat-shell { display: flex; flex: 1 1 auto; flex-direction: column; min-width: 0; min-height: 0; width: 100%; overflow: hidden; } /* THE EXPERIMENTAL CHAT ENTRY IS THE INBOX'S NOW (#2718 review). * `.global-chat-new-chat-btn` styled a pill at the head of the Improve * panel's Chats section — first a header toggle flipping `Chat` / `Classic`, * then an entry point in the panel. The panel retired, and the control had * already been superseded: `#messages-new-agent` under the Messages inbox's * Agents filter starts a chat, gated on the same two flags, beside the rows * that resume one. One list, one way in. */ .global-chat-toolbar { display: flex; align-items: center; gap: 10px; flex: 0 0 auto; width: min(100%, 54rem); margin: 0 auto; padding: 16px 16px 8px; } .global-chat-toolbar h2 { color: var(--text-primary); font-size: 22px; font-weight: 750; line-height: 1.15; } .global-chat-toolbar h2 span { color: var(--text-muted); font-size: 13px; font-weight: 500; } .global-chat-toolbar p { margin-top: 2px; color: var(--text-muted); font-size: 12px; } .global-chat-budget { margin-left: auto; color: var(--text-muted); font-size: 11px; white-space: nowrap; } .global-chat-new { display: inline-flex; align-items: center; justify-content: center; gap: 4px; flex: 0 0 auto; min-height: 36px; padding: 0 12px; border-radius: 9999px; color: var(--text-primary); background: var(--dc-raised); font-size: 13px; font-weight: 650; } .global-chat-new:disabled { opacity: .45; } .global-chat-transcript { flex: 1 1 auto; min-height: 0; width: min(100%, 54rem); margin: 0 auto; overflow-y: auto; overscroll-behavior: contain; padding: 8px 16px 18px; scroll-padding-bottom: 100px; } .global-chat-turn { width: 100%; margin: 8px 0; } .global-chat-turn-user { display: flex; justify-content: flex-end; } .global-chat-turn-user p { max-width: min(78%, 38rem); padding: 9px 14px; border-radius: 18px; color: var(--text-primary); background: var(--accent-tint); font-size: 16px; line-height: 1.35; overflow-wrap: anywhere; } .global-chat-turn-assistant { padding-right: min(8vw, 64px); } .global-chat-assistant-copy { margin: 0 0 8px; color: var(--text-primary); font-size: 16px; line-height: 1.4; white-space: pre-wrap; overflow-wrap: anywhere; } .global-chat-first-use, .global-chat-unavailable { display: flex; flex: 1 0 auto; flex-direction: column; justify-content: center; min-height: min(48vh, 380px); padding: 28px 0; } .global-chat-first-use h3, .global-chat-unavailable h3 { color: var(--text-primary); font-size: 24px; font-weight: 700; line-height: 1.2; } .global-chat-suggestion-hint { margin-top: 6px; color: var(--text-muted); font-size: 12px; } .global-chat-unavailable p { max-width: 34rem; margin-top: 5px; color: var(--text-muted); font-size: 15px; } .global-chat-suggestions, .global-chat-inline-actions { display: flex; flex-wrap: wrap; align-items: center; gap: 7px; } .global-chat-suggestions { margin-top: 10px; } .global-chat-related-suggestions { display: flex; flex: 0 0 100%; flex-wrap: wrap; gap: 7px; padding-top: 1px; } .global-chat-related-suggestions button { color: var(--text-secondary); background: var(--dc-raised); } .global-chat-suggestions button, .global-chat-inline-actions button, .global-chat-expand, .global-chat-history { display: inline-flex; align-items: center; justify-content: center; min-height: 36px; padding: 0 13px; border-radius: 9999px; color: var(--brand-ink); background: var(--brand-tint); font-size: 13px; font-weight: 650; line-height: 1.1; } .global-chat-suggestions button:hover, .global-chat-inline-actions button:hover, .global-chat-expand:hover, .global-chat-history:hover { filter: brightness(.97); } .global-chat-suggestions .global-chat-more-suggestions, .global-chat-inline-actions button:last-child, .global-chat-expand, .global-chat-history { color: var(--text-secondary); background: var(--dc-raised); } .global-chat-inline-actions .global-chat-action-primary { color: var(--accent-ink); background: var(--accent); } .global-chat-inline-actions button:disabled { opacity: .5; } .global-chat-result { margin: 8px 0; overflow: hidden; border-radius: 18px; background: var(--dc-sheet-fill); box-shadow: 0 1px 0 var(--app-sheet-line); backdrop-filter: var(--dc-frost); -webkit-backdrop-filter: var(--dc-frost); } .global-chat-result-head { display: flex; align-items: center; gap: 10px; min-height: 38px; padding: 7px 12px; color: var(--text-muted); font-size: 12px; font-weight: 700; text-transform: uppercase; letter-spacing: .035em; } .global-chat-result-head button { display: inline-flex; align-items: center; gap: 3px; margin-left: auto; color: var(--accent); font-size: 12px; font-weight: 650; text-transform: none; letter-spacing: 0; } .global-chat-result-items > :not(:last-child) { border-bottom: 1px solid var(--border-light); } .global-chat-result[data-renderer="app"] .global-chat-result-items { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); border-top: 1px solid var(--border-light); } .global-chat-result[data-renderer="app"] .global-chat-result-items > .global-chat-item { min-width: 0; border-right: 1px solid var(--border-light); border-bottom: 1px solid var(--border-light); } .global-chat-result[data-renderer="app"] .global-chat-result-items > .global-chat-item:nth-child(even) { border-right: 0; } .global-chat-item { display: flex; gap: 10px; padding: 10px 12px 11px; } .global-chat-result[data-renderer="app"] .global-chat-item { gap: 8px; padding: 8px 10px; } .global-chat-app-icon { width: 34px; height: 34px; border-radius: 10px; } .global-chat-item-toggle { display: flex; width: 100%; align-items: flex-start; gap: 8px; border-radius: 8px; text-align: left; } .global-chat-item-toggle:focus-visible { outline: 2px solid var(--accent); outline-offset: 3px; } .global-chat-item-title { display: block; color: var(--text-primary); font-size: 15px; font-weight: 700; line-height: 1.25; overflow-wrap: anywhere; } .global-chat-item-meta { display: block; margin-top: 2px; color: var(--text-muted); font-size: 12px; line-height: 1.3; overflow-wrap: anywhere; } .global-chat-item-chevron { width: 15px; height: 15px; flex: 0 0 auto; margin-top: 2px; color: var(--text-muted); transition: transform .16s ease; } .global-chat-item[data-expanded] .global-chat-item-chevron { transform: rotate(180deg); } .global-chat-item-selector .global-chat-item-toggle { min-height: 34px; align-items: center; } .global-chat-item-selector .global-chat-item-title { font-size: 14px; } .global-chat-item-details { padding-top: 3px; } .global-chat-item-summary { margin-top: 4px; color: var(--text-secondary); font-size: 13px; line-height: 1.35; white-space: pre-wrap; overflow-wrap: anywhere; } .global-chat-item-fields { display: grid; grid-template-columns: repeat(auto-fit, minmax(120px, 1fr)); gap: 6px 12px; margin-top: 8px; } .global-chat-item-fields dt { color: var(--text-muted); font-size: 11px; font-weight: 650; } .global-chat-item-fields dd { margin: 1px 0 0; color: var(--text-secondary); font-size: 12px; overflow-wrap: anywhere; } .global-chat-inline-actions { margin-top: 8px; } .global-chat-inline-actions button { min-height: 30px; padding: 0 10px; font-size: 12px; } .global-chat-expand { gap: 4px; margin: 8px 12px 12px; min-height: 32px; } .global-chat-client-action { padding: 0 12px 12px; } .global-chat-result-nested { margin: 9px 0 2px; border: 1px solid var(--border-light); border-radius: 14px; background: var(--dc-raised); box-shadow: none; } .global-chat-inline-loading, .global-chat-inline-error { margin-top: 8px; color: var(--text-muted); font-size: 12px; } .global-chat-inline-error { color: var(--danger, #b91c1c); } .global-chat-setting-edit { margin-top: 9px; color: var(--brand-ink); font-size: 12px; font-weight: 650; } .global-chat-setting-controls { margin-top: 9px; } .global-chat-setting-instruction { display: flex; flex-wrap: wrap; gap: 7px; margin-top: 9px; } .global-chat-setting-instruction input { min-width: min(100%, 260px); flex: 1 1 260px; min-height: 36px; padding: 7px 10px; border: 1px solid var(--border-light); border-radius: 10px; color: var(--text-primary); background: var(--bg-input, var(--dc-sheet)); font-size: 13px; } .global-chat-setting-instruction button { min-height: 36px; padding: 0 11px; border-radius: 9999px; color: var(--brand-ink); background: var(--brand-tint); font-size: 12px; font-weight: 650; } .global-chat-setting-instruction button:last-child { color: var(--text-secondary); background: var(--dc-raised); } .global-chat-setting-instruction button:disabled { opacity: .45; } .global-chat-settings-editor { padding: 2px 12px 14px; } .global-chat-settings-editor > :last-child { margin-bottom: 0; } .global-chat-development-editor { display: grid; gap: 12px; } .global-chat-setting-status { color: #047857; font-size: 12px; } .global-chat-setting-note { color: var(--text-muted); font-size: 11px; line-height: 1.4; } .dark .global-chat-setting-status { color: #6ee7b7; } .global-chat-result-done { display: flex; align-items: center; gap: 5px; padding: 9px 12px 12px; color: var(--text-muted); font-size: 13px; font-weight: 650; } .global-chat-confirmation { margin: 8px 0; padding: 12px; border-radius: 18px; color: var(--text-primary); background: var(--state-attention-bg); } .global-chat-confirmation strong { font-size: 15px; } .global-chat-confirmation p { margin-top: 2px; color: var(--text-muted); font-size: 12px; } .global-chat-confirmation-details { display: grid; gap: 4px; margin-top: 8px; } .global-chat-confirmation-details > div { display: grid; grid-template-columns: minmax(68px, auto) minmax(0, 1fr); gap: 8px; font-size: 12px; line-height: 1.35; } .global-chat-confirmation-details dt { color: var(--text-muted); text-transform: capitalize; } .global-chat-confirmation-details dd { color: var(--text-primary); overflow-wrap: anywhere; } .global-chat-confirmation-muted { color: var(--text-muted); background: var(--dc-raised); font-size: 13px; } .global-chat-result-loading, .global-chat-loading, .global-chat-activity { display: flex; align-items: center; gap: 7px; min-height: 38px; color: var(--text-muted); font-size: 13px; } .global-chat-progress { margin: 9px 0; padding: 9px 11px; border: 1px solid var(--border-light); border-radius: 14px; color: var(--text-muted); background: var(--dc-raised); font-size: 12px; } .global-chat-progress-current { display: flex; align-items: center; gap: 7px; min-height: 22px; } .global-chat-progress-current span { min-width: 0; flex: 1 1 auto; color: var(--text-secondary); overflow-wrap: anywhere; } .global-chat-progress-current time { flex: 0 0 auto; font-variant-numeric: tabular-nums; } .global-chat-progress details { margin-top: 5px; } .global-chat-progress summary { width: max-content; cursor: pointer; color: var(--accent); font-weight: 650; } .global-chat-progress-details { display: grid; gap: 4px; margin-top: 6px; padding-top: 6px; border-top: 1px solid var(--border-light); } .global-chat-progress-details ol, .global-chat-progress-details ul { display: grid; gap: 3px; margin: 0; padding-left: 18px; } .global-chat-progress-details li[data-status="completed"] { color: var(--text-secondary); } .global-chat-progress-details li[data-status="failed"] { color: var(--danger, #b91c1c); } .global-chat-history { margin: 0 auto 10px; } .global-chat-error { display: flex; align-items: center; gap: 10px; margin: 10px 0; padding: 9px 12px; border-radius: 14px; color: var(--state-blocked); background: var(--state-blocked-bg); font-size: 13px; } .global-chat-error span { min-width: 0; flex: 1 1 auto; } .global-chat-error button { display: inline-flex; align-items: center; gap: 4px; flex: 0 0 auto; font-weight: 700; } .global-chat-composer { display: flex; align-items: flex-end; gap: 8px; flex: 0 0 auto; width: min(calc(100% - 24px), 52rem); margin: 0 auto; /* THE BOTTOM IS THE SAFE BAR'S. The form wears `.platform-safe-bar` (top of this file): its 8px base gap plus the larger of the tab bar's band and the home-indicator strip, since #global-chat-screen keeps the platform tab bar up on a phone. This rule cleared the strip alone — `calc(10px + var(--platform-safe-bottom))` — so the field sat under the tab bar. The 8px declared here is the value the class computes with no bar and no inset, so the two cannot disagree on a desktop. */ padding: 10px 12px 8px; border-radius: 22px 22px 0 0; background: var(--dc-sheet-fill); box-shadow: 0 -5px 18px rgba(0, 0, 0, .06); backdrop-filter: var(--dc-frost); -webkit-backdrop-filter: var(--dc-frost); } .global-chat-composer textarea { flex: 1 1 auto; min-width: 0; min-height: 40px; max-height: 144px; resize: none; overflow-y: auto; border: 0; outline: 0; padding: 9px 4px; color: var(--text-primary); background: transparent; font-size: 16px; line-height: 1.35; } .global-chat-composer textarea::placeholder { color: var(--text-faint); } .global-chat-send { display: inline-flex; align-items: center; justify-content: center; flex: 0 0 auto; width: 40px; height: 40px; border-radius: 9999px; color: var(--accent-ink); background: var(--accent); } .global-chat-send:disabled { opacity: .35; } .global-chat-stop-mark { width: 11px; height: 11px; border-radius: 2px; background: currentColor; } @media (max-width: 639px) { .global-chat-toolbar { padding-right: 12px; padding-left: 12px; } .global-chat-toolbar p { display: none; } .global-chat-budget { display: none; } .global-chat-new { width: 44px; min-height: 44px; padding: 0; } .global-chat-new span { display: none; } .global-chat-transcript { padding-right: 12px; padding-left: 12px; } .global-chat-turn-assistant { padding-right: 0; } .global-chat-turn-user p { max-width: 86%; } .global-chat-suggestions button { min-height: 42px; } .global-chat-inline-actions button { min-height: 36px; } .global-chat-result[data-renderer="app"] .global-chat-result-items { grid-template-columns: minmax(0, 1fr); } .global-chat-result[data-renderer="app"] .global-chat-result-items > .global-chat-item { border-right: 0; } .global-chat-item { padding-top: 12px; padding-bottom: 12px; } .global-chat-item-toggle { min-height: 36px; } .global-chat-setting-instruction input, .global-chat-setting-instruction button { min-height: 42px; } .global-chat-progress { padding: 9px 10px; } .global-chat-composer { width: calc(100% - 16px); } } @media (prefers-reduced-motion: reduce) { .global-chat-result-loading svg, .global-chat-loading svg, .global-chat-activity svg { animation: none; } .global-chat-progress-current svg { animation: none; } } .dark { --bg-primary: #0b0b0c; --bg-secondary: #1c1c1e; --bg-tertiary: #2c2c2e; /* zinc-700, one step up from the dark hover fill (zinc-800). */ --dev-press: #3a3a3c; /* The ladder above, climbing away from the #0b0d1b wallpaper rather than down into it. --dc-sheet takes --bg-secondary's value and --dc-raised takes --bg-tertiary's: a card on the sheet has to be one step lighter again, which is the step the old pairing had no room for. */ --dc-strip: #131316; --dc-sheet: #1c1c1e; /* One step up the same ramp as the sheet below it (`--bg-tertiary`), which is the step the rest of the dark palette already uses for "on top of". */ --dc-sheet-raise: #2c2c2e; --dc-raised: #2c2c2e; /* The dark planes. The strip's tint is the dark wallpaper's own ground rather than the strip's opaque value: at 0.55 over that ground it is nearly a no-op on the flat areas and lets the washes through where they are, which is the point. DENSER THAN LIGHT'S, on purpose. The two themes are not the same problem. Light's wallpaper is cream with pastel washes — averaging it with white barely moves it, so 0.50 still reads as a sheet and shows the washes plainly. Dark's is near-black with washes several times more saturated than their ground; the same alpha there does not read as glass over a page, it reads as the washes themselves with type on top. So dark stays denser and light goes thinner, and the numbers differ because the grounds do. */ --dc-strip-fill: rgba(11, 13, 27, 0.55); --dc-sheet-fill: rgba(28, 28, 30, 0.72); --dc-float-fill: rgba(28, 28, 30, 0.95); /* The same fills composited over the dark wallpaper's ground (11, 13, 27); see the light block for what these are for. */ --dc-sheet-solid: #17181d; --dc-strip-solid: #0b0d1b; --bg-code: #141416; --bg-code-header: #1c1c1e; --bg-card: rgba(90, 169, 255, 0.10); --bg-card-alt: rgba(16, 185, 129, 0.05); --bg-input: #1c1c1e; --border: #2c2c2e; --border-light: #3a3a3c; --text-primary: #f5f5f7; --text-secondary: #e3e3e6; /* #8e8e93, not the #6c6c70 this carried. --text-muted was the ONE token in this block with no dark counterpart — it kept its light value, so on a near-black page it was as dark as it is on a near-white one. Every muted label the token paints measured 3.2:1 or worse against the dark ground, and the create modal's unselected segment pills 2.7:1 against their track. One step up the neutral ramp reads at 6.0 on the ground and 5.3 on a card, and is still plainly quieter than --text-secondary above. #98989d, not #8e8e93 (QA 2026-09-24 Q20): the ground was measured, the raised surfaces were not. On --bg-tertiary (#2c2c2e), which is what the Workshop tabs, the Messages filter track, the theme toggle and the category cards sit on, #8e8e93 is 4.27:1. Five steps lighter clears 4.85 there and stays well under --text-secondary. */ --text-muted: #98989d; --text-faint: #8e8e93; --text-code: #e3e3e6; --accent: #5aa9ff; --accent-light: #8cc4ff; --accent-tint: rgba(90, 169, 255, 0.14); /* violet-950 and violet-300: the wash goes DARK here for the same reason the bubble does — a pale fill on a near-black page is the brightest thing on screen, and this is a control, not the message. */ --accent-wash: #00264d; --accent-wash-ink: #85bcff; --accent-tint-ink: #5aa9ff; --accent-ink: #0b0b0c; /* Dark counterparts of the semantic state tokens. Every --state-* declared on :root has one here — tests/dev-color-tokens.test.js asserts the two lists match, so a token added above without a dark value fails the suite rather than rendering an unreadable badge. */ --state-neutral: #9ca3af; --state-neutral-bg: rgba(156, 163, 175, 0.16); --state-progress: #a78bfa; --state-progress-bg: rgba(167, 139, 250, 0.18); --state-attention: #fbbf24; --brand-ink: #c7d0f5; --brand-tint: #262b45; --brand-line: #3a4270; --lit-ink: #8cc4ff; --lit-tint: rgba(90, 169, 255, 0.16); --lit-line: rgba(90, 169, 255, 0.35); /* Dark inverts both halves rather than dimming them: the hairline goes to white-at-low-alpha (a black one is invisible on a near-black ground) and the shadow goes DEEPER, not softer, because a shadow has to out-darken #0b0d1b to separate anything from it at all. */ --app-sheet-line: rgba(255, 255, 255, 0.12); --app-sheet-shadow-near: rgba(0, 0, 0, 0.55); --app-sheet-shadow-far: rgba(0, 0, 0, 0.4); --dc-lift-shadow: 0 6px 12px -6px var(--app-sheet-shadow-near), 0 8px 24px -4px var(--app-sheet-shadow-far); --pane-scrim-ink: 0 0 0; --pane-scrim-alpha: 0.4; --pane-scrim: rgb(var(--pane-scrim-ink) / var(--pane-scrim-alpha)); --state-attention-bg: rgba(245, 158, 11, 0.18); --state-blocked: #f87171; --state-blocked-bg: rgba(239, 68, 68, 0.18); --state-blocked-fill: rgba(239, 68, 68, 0.38); --state-ok: #34d399; --state-ok-bg: rgba(34, 197, 94, 0.18); --state-ok-fill: rgba(34, 197, 94, 0.38); --state-admin: #fbbf24; --state-admin-bg: rgba(245, 158, 11, 0.14); } /* ── Accessibility: text size and high contrast (#3969) ───────────── Owned by the inline `window.Display` block in frontend/src/head.html, which puts data-text-size / data-contrast on before first paint (the same head-blocking pass as `.dark`, so nothing flashes). Text size scales everything in rem — the primitives' text-[0.9375rem], Tailwind's text-xs…text-3xl, and the rem paddings and heights with them, so tap targets keep their proportion. Fixed-pixel text (font-size: Npx rules and text-[Npx] classes) deliberately does not scale; converting it is a later change. CSS zoom was ruled out: the shell is pinned to height:100dvh and zoom pushes the fixed bars off screen. High contrast deepens the existing ink and line tokens — every value below is one already on the zinc ramp or in the token blocks above, so nothing changes hue. The light overrides are scoped to html:not(.dark) and the dark ones to html.dark, so an element carrying only a light-only zinc class is never darkened on a dark page. The attribute selectors (0,2,1) outrank Tailwind's single-class (0,1,0) and its `:is(.dark …)` (0,2,0) rules, so the stylesheet order native → app → tailwind stays as it is; they do NOT touch the [data-app-tone] ink blocks on #platform-header / #app-frame-host, which keep their tuned ink over a toned app. */ html[data-text-size="large"] { font-size: 112.5%; } html[data-text-size="larger"] { font-size: 125%; } html:not(.dark)[data-contrast="more"] { --text-muted: #3a3a3c; --text-faint: #48484a; --border: #8e8e93; --border-light: #c7c7cc; --app-sheet-line: #c7c7cc; } html:not(.dark)[data-contrast="more"] .text-zinc-400, html:not(.dark)[data-contrast="more"] .text-zinc-500 { color: #3a3a3c; } html:not(.dark)[data-contrast="more"] .border-zinc-200 { border-color: #c7c7cc; } html.dark[data-contrast="more"] { --text-muted: #e3e3e6; --text-faint: #c7c7cc; --border: #8e8e93; --border-light: #48484a; --app-sheet-line: #48484a; } html.dark[data-contrast="more"] .dark\:text-zinc-400, html.dark[data-contrast="more"] .dark\:text-zinc-500 { color: #e3e3e6; } html.dark[data-contrast="more"] .dark\:border-zinc-800 { border-color: #48484a; } /* ── usernode-native kit theming ───────────────────────── The platform loads its own hosted kit (/usernode-native/v1/) — see index.html. The kit's defaults already ARE the platform violet, but we pin the surface/hairline tokens to the platform palette explicitly so kit chrome (sheets, grouped cards, toasts, nav bars) tracks app.css if either palette ever drifts. Override --un-* variables only; never fork or out-specificity the kit CSS. */ :root { --un-accent: var(--accent); --un-surface: var(--bg-secondary); --un-hairline: var(--border); --un-muted: var(--text-muted); --un-group-bg: var(--bg-card); --un-sheet-bg: var(--bg-primary); /* Anchored menus (the home card's "…" actions menu, header menus). Pinned explicitly to an OPAQUE platform surface — --un-group-bg is a translucent violet tint by design, so a popover inheriting it showed the app grid straight through (#847). Matches the platform's other floating dropdowns (.attr-popover, .gc-mention-menu). */ --un-popover-bg: var(--bg-primary); --un-navbar-bg: rgba(255, 255, 255, 0.82); --un-radius-card: 12px; /* The tile-zoom overlay surface: the app view's screens paint on the body background, so the moving card must match it exactly. On the wallpaper routes the body's ground is the cream, and the same rule that paints it re-points this at --home-ground (see "The home ground") — otherwise the card zooms open WHITE and snaps to cream when the kit lifts its surface. */ --un-zoom-bg: var(--bg-primary); } .dark { --un-accent: var(--accent); --un-surface: var(--bg-secondary); --un-hairline: var(--border); --un-muted: var(--text-faint); --un-group-bg: #1c1c1e; --un-sheet-bg: #1c1c1e; /* One step lighter than --bg-primary (#0b0b0c) so the floating menu reads as elevated above the page rather than merging into it. */ --un-popover-bg: #1c1c1e; --un-navbar-bg: rgba(11, 11, 12, 0.78); --un-zoom-bg: var(--bg-primary); } /* Full-screen modal roots whose card is currently riding inside a kit presentModal (see frontend/src/lib/static-modal.ts): the legacy fixed overlay/scrim must not paint a second backdrop. */ .platform-modal-adopted { display: none !important; } /* A legacy modal card riding inside the kit modal shell: the shell already draws the surface, radius, shadow and padding — the card's own chrome would stack on it (double border, doubled whitespace). One chrome only: the kit's. */ .un-modal .platform-modal-card { background: transparent !important; box-shadow: none !important; border: 0 !important; border-radius: 0 !important; padding: 0 !important; width: 100% !important; max-width: none !important; margin: 0 !important; } /* The header drawer riding inside a kit SIDE PANEL on touch (unNative.presentPanel via App.HeaderMenu.open). Same neutralisation of the legacy fixed slide-over chrome as .platform-sheet-adopted below, but sized for a full-height drawer: it FILLS the kit panel rather than being capped, which is what lets #drawer-footer's `mt-auto` hug the bottom of the screen instead of being pushed past a 70vh cut-off. Deliberately no max-height here. */ .platform-panel-adopted { position: static !important; inset: auto !important; transform: none !important; transition: none !important; width: 100% !important; max-width: none !important; height: 100% !important; max-height: none !important; border: none !important; border-radius: 0 !important; box-shadow: none !important; background: transparent !important; display: flex !important; flex: 1 1 auto; min-height: 0; } /* Panels adopted into kit bottom sheets on touch (notifications, work drawer, dev console — the header drawer moved to the side panel above). Their legacy classes pin them as fixed dropdown/slide-over chrome; while riding inside a sheet the sheet owns position, size and surface. */ .platform-sheet-adopted { position: static !important; inset: auto !important; transform: none !important; transition: none !important; width: auto !important; max-width: none !important; max-height: 70vh !important; height: auto !important; border: none !important; border-radius: 0 !important; box-shadow: none !important; background: transparent !important; display: flex !important; } /* ONE PANE OF GLASS, NOT TWO (#2825). The kit's sheet, panel and modal are already frosted in the shell (`--dc-frost`, the "Shell-only frosted kit surfaces" block). The panels that ride inside them — the Homeroom menu and the notifications sheet wear `.dc-lift-panel` — kept their OWN `backdrop-filter` when adopted: `background: transparent` above cleared the fill but not the filter, so the panel re-frosted the already-frosted sheet behind it and read as a second, whiter box inset by the sheet's padding — the "extra white box around pop up dialogs". The kit shell is the only surface; the content sits straight on it. */ .platform-sheet-adopted, .platform-panel-adopted, .un-modal .platform-modal-card { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } /* ── The nav surfaces grow further, and keep their scroller ──────────── The 70vh above is right for a kit sheet that is a DIALOG — a form, a confirm, a short list. The four navigation surfaces are not: the Improve panel carries every change in flight, and the messages/notifications sheets carry as many rows as there are. They get the same near-full cap their no-kit CSS uses, so the behaviour is one rule at every width and on both paths. */ /* The 3rem gap is measured from BELOW the status bar, not from the top of the viewport. A flat `100dvh - 3rem` is 48px, and the status-bar inset on a notched phone is 54pt — so at the cap the sheet's head slid UNDER the clock and the signal bars, which is the one place the gap exists to prevent. The fallback keeps desktop and any browser without the env() unchanged. */ .platform-sheet-adopted#messages-sheet { max-height: calc(100dvh - env(safe-area-inset-top, 0px) - 3rem) !important; } /* The app menu stops at 80%, matching the no-kit bottom-sheet rule in the `max-width: 639px` block: it is a short list of destinations, and a menu that climbs to the status bar reads as a screen you have navigated to rather than something laid over the page. Only the sheet. The desktop presentation is a dropdown under the header chip, capped against the fold by its own rule. THE TWO VISIBILITY PROPERTIES ARE RESET HERE ON PURPOSE. That dropdown hides with `opacity: 0; visibility: hidden` rather than by sliding off an edge, and the generic `.platform-sheet-adopted` block above — which flattens position, transform, transition, border and shadow — covers neither. A touch device WIDER than 639px (a tablet) matches the desktop rule and the kit adoption at once, so without this the kit's sheet could present an invisible panel. It is not merely theoretical insurance for the open state either: the kit measures the content at present time. */ /* HANDED BACK BY THE KIT, OUT OF SIGHT until its next presentation (lib/kit-surface.ts REHOMED_CLASS): the menu's bottom sheet stood again at its open place for 190ms after the kit's exit had taken it away. */ .platform-surface-rehomed { visibility: hidden !important; transition: none !important; } .platform-sheet-adopted#apps-switcher-sheet { max-height: min(80dvh, calc(100dvh - env(safe-area-inset-top, 0px) - 3rem)) !important; opacity: 1 !important; visibility: visible !important; } /* THE BELL IS A FIXED HEIGHT, and that is the whole point of it. Every other surface here is `height:auto` under a cap, so it is as tall as whatever it happens to contain. On the notifications sheet that content changes under the viewer's feet: Unread and All are two filters over one list, so switching tabs re-sized the sheet: a two-row Unread tab was a short sheet and All was a tall one, and the kit seeds its slide-up spring from a single measurement at present time (lib/sheet-controller.js), so the panel jumped rather than resized. A definite height takes the content out of the decision entirely: the sheet is the same object on both tabs and only the rows inside it change. The inner scroller (`flex-1 min-h-0` on the row list) already handles the overflow this creates on a full All tab. #5289: the WHOLE screen, less the status bar and a sliver above the kit's grabber (21px) that keeps it reading as a sheet you can pull down. It was two thirds, which on a phone fit five rows: the bell is a list you read down, and a third of the screen spent on the page behind it bought nothing. The bottom safe inset is the kit's own padding under the sheet. `height` has to beat `height: auto !important` above, hence the !important. */ .platform-sheet-adopted#notifications-sheet { height: calc(100dvh - env(safe-area-inset-top, 0px) - var(--un-safe-inset-bottom, env(safe-area-inset-bottom, 0px)) - 2.25rem) !important; max-height: none !important; } /* THE KIT'S DRAG WOULD OTHERWISE EAT THE SCROLL. `.un-sheet` sets `touch-action: none` and claims any vertical drag for drag-to-dismiss, with no scroller detection — which is why the header drawer became a kit PANEL rather than a sheet (#915), and why an inner `overflow-y: auto` inside an adopted sheet has been decorative up to now. `touch-action` is intersected down the ancestor chain, so the scroller cannot opt back in on its own; the SHEET has to allow vertical panning. Scoped to the sheets that actually contain a scroller, so every other adopted sheet keeps the kit's dismiss gesture exactly as it was. Inside these, a vertical pan goes to the scroller and the kit's pointer handler takes a `pointercancel` (native.js handles it with v=0 and springs back); a drag starting anywhere else in the sheet still dismisses it, and so does the grabber. */ .un-sheet:has(#notifications-sheet), .un-sheet:has(#messages-sheet) { touch-action: pan-y; } /* THE SWITCHER'S ONLY SCROLLER RUNS THE OTHER WAY. Its app rail is a horizontal strip, and `pan-y` here made that strip unreachable by touch — the overflow existed and no gesture could get at it. `pan-x` inverts the trade in this sheet's favour, and it costs less than the panel's does: a VERTICAL drag anywhere still reaches the kit's pointer handler, so drag-to-dismiss survives intact here. */ .un-sheet:has(#apps-switcher-sheet), .un-sheet:has([data-staking-sheet]) { touch-action: pan-x; } /* …EXCEPT ON ITS ABOUT PANE, WHICH IS A PAGE. The app's facts, its builders and its MORE rows run past the sheet's 80% cap on a phone, and `pan-x` above leaves #switcher-nav's overflow unreachable by touch — the pane would end where the sheet does, with Share and Fork below the fold and no gesture to reach them. So while About is showing the sheet takes the notifications sheet's trade instead (the `pan-y` block above): a vertical drag in the pane scrolls it, and the grabber still dismisses. Same specificity as the rule above, so this one wins by coming after it; the menu pane keeps the drag-to-dismiss it has always had. */ .un-sheet:has(#app-about-pane) { touch-action: pan-y; } /* THE HOME-INDICATOR INSET IS THE KIT'S JOB INSIDE AN ADOPTED SURFACE. #improve-footer carries .platform-safe-scroll, which is right in the two cases where nothing else reserves that strip: the desktop slide-over (where the inset is 0 anyway) and mobile Safari, where the kit is absent and the panel stays a fixed slide-over. Inside a kit sheet or panel it is counted TWICE. `.un-sheet` already sets `padding-bottom: var(--un-safe-inset-bottom, env(safe-area-inset-bottom))` and `.un-sheet-body` adds 20px under that, so a 34px indicator put the version row 88px off the bottom (34 + 20 + 34) instead of 54. Measured, not estimated — the duplicate is this one. IT WAS NEVER ONLY #improve-footer, AND THAT IS WHY THIS IS BY CLASS. Every adoptable sheet has an element carrying one of these classes, and measured on a 34px indicator all three double-counted it: #improve-footer .platform-safe-scroll 34 + 20 + 34 = 88px #switcher-nav .platform-safe-sheet 54 + 20 + 34 = 108px the notifications scroller .platform-safe-scroll 34 + 20 + 34 = 88px The app menu's is worst because .platform-safe-sheet adds 1.25rem on top of the inset. And the notifications scroller HAS NO ID — an id-based rule could not have reached it however many ids were listed, which is the argument for writing the rule the comment above already states: inside an adopted surface the inset is the kit's job, wherever it appears. THE GAP IS ALSO HEIGHT. A bottom sheet is as tall as its content, so every one of those pixels pushed the sheet further up the screen. The report was "extra white space at the bottom, which means it doesn't have to come up as much" — exactly the mechanism: the sheet rose to make room for padding nobody could see. Zeroing it drops the app menu from 82% of a 390x844 phone to 75%. What is left under the last row is the kit's own 20px plus the indicator, which is what .platform-safe-sheet's comment asks for anyway ("real padding under it whether or not the device reports an inset"). Ours is the copy that goes, and only on this path: with no kit, nothing else reserves that strip and both classes keep doing their job. `!important` because both classes use it; the descendant selector is what wins the tie. Descendants only — no adopted root carries either class itself today, and one that did would want its own answer rather than this one applied silently. */ .platform-sheet-adopted .platform-safe-scroll, .platform-sheet-adopted .platform-safe-sheet, .platform-panel-adopted .platform-safe-scroll, .platform-panel-adopted .platform-safe-sheet { padding-bottom: 0 !important; } /* Chat/proposal screen headers wired through unNative.attachNavBar (platform-ui.js attachScreenFx): the kit toggles .un-scrolled once the screen's scroller moves — that's the cue for the frosted nav-bar treatment. The bars stay in-flow (not .un-navbar fixed); only the scrolled-state styling changes. */ .platform-chat-header.un-scrolled { background: var(--un-navbar-bg); -webkit-backdrop-filter: saturate(180%) blur(16px); backdrop-filter: saturate(180%) blur(16px); box-shadow: 0 0.5px 0 var(--un-hairline); } /* THE KIT'S TOAST CLEARS THE TAB BAR (QA 2026-09-24 Q28). native.css rests the toast 16px above `--un-toast-inset-bottom`; on a phone that is the tab bar's full outer height, which `--platform-tabs-h` already says (0px on a desktop, where the "bar" is the rail). Read on the toast itself, a child of body, so it inherits body's value. PlatformUI.toast overrides it inline when a composer sits above the bar. */ .un-toast { --un-toast-inset-bottom: var(--platform-tabs-h, 0px); } /* THE LANGUAGE NOTICE RESTS WHERE A TOAST DOES ("Showing Homeroom in Español · Switch to English", features/shell/language-notice.tsx). Fixed, because it has to stay in view until it is answered: in the page flow it scrolled away with Home on a phone, and the sign-in screens are `fixed inset-0` over anything in flow. Above those screens (z-40) and below the drawer and panels (z-50), like the install strip. `--language-notice-inset` is the island's own measurement when a composer sits above the tab bar. */ #language-notice { position: fixed; left: 50%; bottom: calc(16px + max(var(--language-notice-inset, var(--platform-tabs-h, 0px)), var(--platform-safe-bottom, 0px))); z-index: 45; width: max-content; max-width: min(calc(100vw - 24px), 480px); transform: translateX(-50%); } /* ── No glass, on any platform (#787, #3104, and since the phone audit) ── Live backdrop blur is unusually expensive in WebKit on a phone while the content behind it scrolls or a spring moves the surface every frame. #787 measured it in the app's WKWebView and #3104 took it off there, which left the app drawing the opaque no-blur fallbacks (neutral #ffffff / #f5f5f7) while Safari, the PWA, Android and desktop drew warm glass: two colour schemes for one product. The decision since is ONE scheme and no blur: the shell's `--dc-frost` is `none` everywhere (see the token), the planes keep their translucent fills, and what content passes behind is opaque in the `-solid` plane colours, identically on every platform. The kit's own frosted chrome goes the same way here, for the shell only (native.css keeps its defaults for apps): no blur on the nav bar, action sheet cards, alerts and toasts, and the two nav tokens, translucent by design, pinned to the platform surface so nothing reads through them. THE MOTION CHANGES ONLY IN THE APP: `html.un-ios.in-native-webview`. The Flutter shell marks the top document with .in-native-webview before first paint (index.html); with .un-ios that is a reliable scope for the native snapshot's view transition and the decorative loops further down. Do not guess a phone model from the UA, and do not reduce motion in Safari/PWA or on Android. */ :root { --un-navbar-bg: var(--bg-primary); --un-toast-bg: #1c1c2a; } .platform-chat-header.un-scrolled, .un-navbar, .un-action-card, .un-alert, .un-toast { -webkit-backdrop-filter: none; backdrop-filter: none; } /* The kit's default iOS page transition dims its full-page snapshot with a brightness filter while also translating it. Keep the spatial push/pop cue, but use transform-only keyframes and a shorter capture lifetime in the native shell. Reduce Motion remains stricter in native.css and disables these animations entirely. */ html.un-ios.in-native-webview[data-un-vt]::view-transition-old(root), html.un-ios.in-native-webview[data-un-vt]::view-transition-new(root) { animation-duration: 260ms; } html.un-ios.in-native-webview[data-un-vt="push"]::view-transition-old(root) { animation-name: un-vt-native-ios-parallax-out-left; } html.un-ios.in-native-webview[data-un-vt="pop"]::view-transition-new(root) { animation-name: un-vt-native-ios-parallax-in-left; } @keyframes un-vt-native-ios-parallax-out-left { from { transform: translateX(0); } to { transform: translateX(-30%); } } @keyframes un-vt-native-ios-parallax-in-left { from { transform: translateX(-30%); } to { transform: translateX(0); } } /* app.css loads after native.css, so repeat the accessibility override at this selector's higher specificity. Without this rule, the performance animation-name above would win back one sub-property from the kit's earlier `animation: none` shorthand and accidentally re-enable Reduce Motion. */ @media (prefers-reduced-motion: reduce) { html.un-ios.in-native-webview[data-un-vt]::view-transition-old(root), html.un-ios.in-native-webview[data-un-vt]::view-transition-new(root) { animation: none; } } /* ── The top bar does not travel with the page ──────────────────────────── Switching apps from the header chip animates `::view-transition-*(root)`, and the root snapshot is the WHOLE document — the header included. So the bar slid out to the left and a second copy slid in from the right, while every control on it stayed in exactly the same place before and after. The only thing that actually changed was the app window underneath. Naming the header hoists it out of the root snapshot into a group of its own, and killing that group's animation pins it. The bar stays put and the push/pop cue is left to the content, which is the thing that moved. Two details this depends on: - #platform-header paints an opaque background (see platform-header.tsx). A named group is composited ABOVE ::view-transition-group(root), so a transparent bar would have the sliding page showing through it. - The name has to be unique per capture. #platform-header is a single element in the shell and #landing-header is a different id on a shell that never coexists with it, so there is exactly one at any capture. Reduce Motion needs no branch here: this rule REMOVES animation, and the kit's own `animation: none` under prefers-reduced-motion still governs the root group. */ #platform-header { view-transition-name: platform-header; } html[data-un-vt]::view-transition-group(platform-header) { animation: none; } /* ── THE REST OF WHAT PINNING A GROUP DOES NOT DO (#2718 review) ──── `animation: none` on the GROUP stops it sliding. It does not stop the two IMAGES inside it cross-fading, which is the default for every named group — so the bar stayed put and spent 130ms showing "Homeroom" and "Workshop" superimposed, both at half opacity, over a rail whose five labels were ghosting through the root snapshot at the same time. Caught by screenshotting 40ms into a Home -> Workshop push. The old image goes and the new one is simply there. A cross-fade is how you animate a thing CHANGING; this bar does not change, it relabels, and two labels at once reads as a fault rather than as motion. THE RAIL GETS ITS OWN GROUP for the same reason it needed one: unnamed, it is part of the root snapshot and slides with the page it is navigation for. Which tab is lit does change — and pops rather than fading, which is the same trade the bar makes and the right one for chrome. Unique per capture, like the header's: both are single elements in the shell. A group present in only one state (the rail going away as an app opens) has nothing to cross-fade with and pops, which is what the zoom transitions already do to it. */ #platform-tabs { view-transition-name: platform-tabs; } html[data-un-vt]::view-transition-group(platform-tabs) { animation: none; } html[data-un-vt]::view-transition-old(platform-header), html[data-un-vt]::view-transition-old(platform-tabs) { animation: none; opacity: 0; } html[data-un-vt]::view-transition-new(platform-header), html[data-un-vt]::view-transition-new(platform-tabs) { animation: none; opacity: 1; } /* EXCEPT WHEN THE RAIL IS THE THING GOING AWAY (#2718 review). Opening an app hides it, so its group has an OLD image and no new one — and the rule above then reads as "remove it on frame 0", which opened a 224px hole down the left of the window and held it there while the page behind it was still fading. The sidebar vanished, and only then did the app arrive. Held at full opacity instead, the bar simply stays where it is for the length of the transition and the app rises over it, which is what "an app covers the rail" should look like. It leaves when the transition does, under a screen that is by then covering that column. `:has()` against the LIVE DOM is what tells the two cases apart: during a transition the document is already in its new state, so `#platform-tabs` carrying `hidden` means this bar is gone on the other side. A tab-to-tab change has the rail in both states and keeps the rule above, where the old image must go — two translucent rails stacked would double the fill and light two rows at once. */ html[data-un-vt]:has(#platform-tabs.hidden)::view-transition-old(platform-tabs) { opacity: 1; } /* THEY DO NOT GO OPAQUE, and that was tried. The note above says a named group has to paint an opaque background because it composites ABOVE ::view-transition-group(root) — true of an element being COMPOSITED, and these are not: pinning the two images means the group renders the NEW snapshot at full opacity, and a snapshot is a picture, not a live surface sampling a backdrop that is moving underneath it. Forcing `--dc-sheet` here instead made both bars `#ffffff` for the length of every navigation — over a cream wallpaper they normally read as a pale wash of it, so the cure was a white flash on every tab press, which is worse than what it was aimed at. Measured: `rgba(255,255,255,0.5)` with a blur at rest, `rgb(255,255,255)` opaque mid-push. Left as prose rather than as a disabled rule: the next person to read the note above will reach for this, and the answer is that the images are already doing the work. */ /* ── AND THE GROUND UNDER THEM STAYS THE WALLPAPER (#2758) ────────────── Pinning the two bars stopped them moving; it did not stop them flickering. The desktop swap is the kit's fade-through, so for a stretch in the middle of every tab change BOTH root snapshots are near opacity 0 — and the wallpaper is the body's background, inside those snapshots. What showed through the translucent bars for those frames was the flat canvas instead: the rail at (100, 600) measured rgb(255,241,232) at rest, rgb(250,249,242) 40-80ms into a Home -> Discover push, and rgb(255,241,232) again from 120ms. A tint pulse across the whole chrome, on every press. `--un-vt-ground` is the body's `--home-wallpaper`, copied onto by frontend/src/lib/transition-ground.ts as the transition starts — every ::view-transition pseudo inherits from , which cannot see a property declared on the body. On a route with no wallpaper it is unset, the declaration is invalid at computed time, and the ground is the canvas it always was. After the fix the same pixel reads rgb(255,241,232) on every sampled frame. The page's own fade-through is unchanged: the content still leaves before the next screen arrives (#1920), it just passes through the wallpaper, which is the "container's own ground" that design always meant. Nor is this the opaque-bar idea the note above rules out: the bars stay the translucent pictures they were, and what changed is only what they are pictures OVER. DESKTOP ONLY. The phone's bottom bar is being reworked separately (#2766), and the iOS lane slides an opaque snapshot over this ground anyway. */ @media (min-width: 768px) { html[data-un-vt]::view-transition { background: var(--un-vt-ground); } } /* Infinite decorative effects keep compositing even when the user is idle. Their state must remain legible without motion: lifecycle colors stay in place and busy session dots gain a static ring. Functional progress spinners are intentionally not selected. */ html.un-ios.in-native-webview .status-dot.creating, html.un-ios.in-native-webview .work-cog-spinning, html.un-ios.in-native-webview .app-version-pill--stale .app-version-pill-dot { animation: none; } html.un-ios.in-native-webview .dc-active-dot-busy.dc-active-dot-active { animation: none; box-shadow: 0 0 0 2px rgba(16, 185, 129, 0.38); } html.un-ios.in-native-webview .dc-active-dot-busy.dc-active-dot-promoted { animation: none; box-shadow: 0 0 0 2px rgba(31, 134, 255, 0.38); } /* Pressed-state opt-outs: the kit gives every button an instant scale-press, which reads wrong on dense strip controls that sit flush against siblings (segmented pills, theme mode pills, the Dev board's tab strip) — the scale makes adjacent cells appear to shift. Keep the brightness dim, drop the transform. */ .members-vis-pill:active, [data-theme-mode]:active { transform: none; } html, body { height: 100dvh; overflow: hidden; touch-action: pan-x pan-y; -webkit-text-size-adjust: 100%; /* The kit's pull-to-refresh owns the pull-down gesture on the platform's scrollers — keep mobile Chrome's native page-refresh from competing for the same drag. */ overscroll-behavior-y: none; } /* #1518: browser toolbars follow document scrolling. The bridge selects one pageable surface at a time; native/installed apps, chats and app iframes retain the bounded shell above. Clip horizontal hit-area overhang without making these pages into nested vertical scroll containers again. */ html[data-browser-scroller] { height: auto; min-height: 100%; overflow-x: clip; overflow-y: auto; } html[data-browser-scroller] body { --browser-banner-h: 0px; height: auto !important; /* the generated body's fixed-shell inline height */ min-height: 100dvh; overflow: visible; isolation: isolate; background: var(--home-ground) !important; } /* ── THE BOTTOM STILL BOUNCES, SO SAFARI CAN TUCK ITS BAR AWAY (#3565) ── "On mobile Safari, if already scrolled to the bottom of the page, cannot scroll down more to make the address bar shrink." Safari tucks its toolbar away when a drag moves the page. At the end of an ordinary page there is nothing left to scroll, but the drag still moves the rubber band, and that is enough. This document has no rubber band. `html, body { overscroll-behavior-y: none }` above was written for the bounded shell, whose document never scrolls, to keep the browser's own refresh out of the kit's pull (#737). #1518 made the document the scroller in a phone browser, and on that one rule now switches off the viewport's bounce at BOTH ends: WebKit's main scroll view bounces vertically unless the root's `overscroll-behavior-y` is `none` (WKWebView `_updateScrollViewForTransaction` -> `_setBouncesInternal`). So at the foot of Home, Discover or a project page, with the bar showing, an upward drag moved nothing and the bar stayed. The TOP keeps `none`. The kit's pull-to-refresh lives there, and a native bounce or the browser's own refresh would join it. There is no per-edge `overscroll-behavior`, so the edge is told apart by where the page is: lib/browser-scroll.ts marks `data-browser-past-top` while the document sits PAST_TOP_PX (64px) or more below its top, and only then does the viewport take `contain`. That is not `none`, so the far edge bounces (WebKit applies a change to the root's value from the next commit; its own fast/scrolling/ios/overscroll-behavior-on-body.html flips it the other way mid-page). `contain` rather than `auto` so Chrome's refresh stays off if a flick ever outruns the mark to the top. A pull that starts at the top always meets `none`, exactly as before, and a page with less than 64px to scroll keeps `none` everywhere. On Android the bottom edge gets the system's stretch back, as on any other page. Body takes the value too only because the rule it overrides names both; WebKit reads . Phones only: a narrow desktop window also pages the document, and its trackpad has no toolbar to tuck away. */ @media (pointer: coarse) { html[data-browser-scroller][data-browser-past-top], html[data-browser-scroller][data-browser-past-top] body { overscroll-behavior-y: contain; } } /* ── THE PAGE HOLDS STILL UNDER A FULL-SCREEN SCREEN (#4893) ────────────── Onboarding run, 12 Oct 2026, iPhone 17 Safari: with "What do you want to make?" open, Home could still be scrolled underneath, and its cards came up behind the status bar. The make, made and "You're in" screens are fixed boxes, and in a phone browser the document is Home's scroller (above), so a drag their own scroller did not take went on to it. frontend/src/lib/page-lock.ts marks `platform-page-locked` while one is up, and the document stops scrolling: `hidden` rather than `auto`, which keeps where it was (the page is not moved, and is there again when the screen goes) and which iOS honours on the root since 16, bounce and all, so the overscroll rules above are left as they are. What scrolls inside the screen still does. The second selector outranks the paged document's own `overflow-y: auto` by weight, not only by coming later. */ html.platform-page-locked, html.platform-page-locked[data-browser-scroller] { overflow: hidden; } /* AND WHAT IT HOLDS IS OUT OF SIGHT (onboarding run three, 12 Oct 2026, iPhone 17 Safari). The band behind Safari's translucent toolbar is not the screen's (Safari draws a fixed box only to its layout viewport's foot), so it showed Home under the make and made screens. What the lock makes inert (lib/page-lock.ts PAGE_HIDDEN) is drawn at no opacity, which a descendant cannot undo as it could `visibility`, so that band shows the body's own ground. The screens cover it all anyway everywhere else. */ html.platform-page-locked [data-page-locked] { opacity: 0 !important; } /* Body padding reserves these fixed strips at the start of a page. Sticky headers must keep reserving them after that padding scrolls away. */ html[data-browser-scroller] body.has-install-strip { --browser-banner-h: var(--install-strip-h); } html[data-browser-scroller] body.is-offline { --browser-banner-h: var(--offline-strip-h); } html[data-browser-scroller] body.is-offline.has-install-strip { --browser-banner-h: calc(var(--offline-strip-h) + var(--install-strip-h)); } /* Keep the ambient wallpaper viewport-sized as the document grows. Its star continues to track the active scroller via wallpaper-scroll.ts. A fixed layer also works on iOS, where background-attachment: fixed does not. */ html[data-browser-scroller] body::before { content: ''; position: fixed; inset: 0; z-index: -1; pointer-events: none; background: var(--home-wallpaper); } html[data-browser-scroller="home-screen"] #home-screen, html[data-browser-scroller="browse-screen"] #browse-screen, html[data-browser-scroller="leaderboard-screen"] #leaderboard-screen, html[data-browser-scroller="profile-screen"] #profile-screen, html[data-browser-scroller="settings-screen"] #settings-screen, html[data-browser-scroller="auth-landing-scroll"] #auth-landing-scroll, html[data-browser-scroller="dev-forum-scroll"] #dev-forum-scroll, html[data-browser-scroller="auth-login-screen"] #auth-login-screen, html[data-browser-scroller="auth-register-screen"] #auth-register-screen, html[data-browser-scroller="auth-waiting-screen"] #auth-waiting-screen, html[data-browser-scroller="auth-waitlist-screen"] #auth-waitlist-screen, html[data-browser-scroller="auth-more-screen"] #auth-more-screen { flex: none; height: auto; overflow-x: clip; overflow-y: visible; } html[data-browser-scroller^="auth-"] body :is( #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen ):not(.hidden) { position: relative; inset: auto; min-height: calc(100dvh - var(--browser-banner-h)); } /* THE STORY'S FOOT CLEARS SAFARI'S TOOLBAR (iPhone 17 simulator, iOS 26 Safari, 5 October 2026). "Already have an account? Sign in" under Get started sat behind Safari's bottom toolbar. In a phone browser the landing is the paged document, and Safari 26 draws the page on under its floating toolbar: a fixed box ends above the toolbar (the small viewport), the document runs on beneath it. The page's foot reserved the home indicator (`.platform-safe-scroll`) and 34px of air, and Safari reports no inset for its own toolbar, so the last line could never be scrolled out from under it. `100lvh - 100svh` is that toolbar: the page with it tucked away less the page with it shown (about 98px on an iPhone 17; 0 where no toolbar comes and goes). Reserved under the story's own foot, the end of the page now scrolls clear of the toolbar shown, and of the slimmer bar Safari tucks it into. iOS only: there the toolbar is at the foot. In the Homeroom app and an installed app there is no browser toolbar and no `data-browser-scroller`, so nothing changes. */ html.un-ios[data-browser-scroller="auth-landing-scroll"] [data-landing-story] { padding-bottom: max(0px, calc(100lvh - 100svh)); } /* The same toolbar under the sign-in screen's foot (#4593): with the story switched off, the release mail's "Create my account" lands on #signup, and its steps (the account step's button, the line pinned at the foot) ran on under Safari's toolbar the way the story's foot did. */ html.un-ios[data-browser-scroller="auth-login-screen"] #auth-login-screen > .min-h-full { padding-bottom: max(0px, calc(100lvh - 100svh)); } /* THE INVITE PAGE'S LAST LINE IS AT THE FOOT OF ITS SCROLLER (#4049). Paged by the document in a phone browser, the landing's scroller is content-height (`flex: none` above), so the column's `min-h-full` had nothing to fill and the line that says what Homeroom is stopped under the note, with empty page above the pinned Join bar. While an invite's page is up, the scroller takes the rest of the screen above the bar and the column takes all of it, so the line's `mt-auto` puts it at the foot, just above Join. The bar clears Safari's toolbar and the home indicator itself. */ html[data-browser-scroller="auth-landing-scroll"] #auth-landing-scroll:has(> * > [data-landing-invite-homeroom]) { flex: 1 0 auto; display: flex; flex-direction: column; } html[data-browser-scroller="auth-landing-scroll"] #auth-landing-scroll > :has(> [data-landing-invite-homeroom]) { flex: 1 0 auto; width: 100%; } /* THE STORY IS A WHOLE SCREEN IN A PHONE BROWSER TOO (#4037). Paged by the document, the landing's scroller is content-height (`flex: none` above), so the column's `min-h-full` had nothing to fill and "Make an account", its waitlist line and Sign in stopped under the tiles, with empty page below them. While the story is up, the scroller takes the rest of the screen under the header and the column takes all of it, so the story's foot sits at the foot of the screen, as in the app. Scoped to the story: the pitch and the invite cards keep their own height. The landing's logo bar (#landing-header) stays above the story: it is a stranger's first screen, so the logo says where they are (the owner's ruling, after a build that hid it). tests/header-height-parity.test.js pins that nothing hides it. */ html[data-browser-scroller="auth-landing-scroll"] #auth-landing-scroll:has(> * > [data-landing-story]) { flex: 1 0 auto; display: flex; flex-direction: column; } html[data-browser-scroller="auth-landing-scroll"] #auth-landing-scroll > :has(> [data-landing-story]) { flex: 1 0 auto; width: 100%; } /* The anonymous overlay covered the signed-in shell, including any screen painted from the last-session snapshot. In document flow those roots must leave the layout too, so visitors see only the anonymous page. */ html[data-browser-scroller^="auth-"] :is( #platform-header, #home-screen, #browse-screen, #leaderboard-screen, #profile-screen, #settings-screen, #messages-screen, #admin-screen, #app-view ) { display: none; } /* UNDER THE SIGNED-OUT LANDING the platform header is covered (the landing is a fixed overlay with its own bar) but was still read out: an empty level-1 heading beside the page's own on a desktop (polish N10). In a phone browser the rule above already takes it out of the layout. */ body:has(#auth-landing-screen:not(.hidden)) #platform-header { visibility: hidden; } /* IN BROWSER-SCROLLER MODE the document is the scroller and this bar is sticky over it, so it has to hide the content sliding under it rather than letting it read through — which is why it takes a near-opaque wash of the page ground instead of the frosted fill below. #platform-header is the exception now (#2718 review): the tab bar at the foot is `position: fixed` over the very same scrolling document and has always been `--dc-sheet-fill` under `--dc-frost`, so "frost over moving content" is a thing this shell already does at one edge of the screen. The two bars are the same kind of object and the owner asked for them to look it, on phone and desktop alike. The landing header keeps the wash: it has no tab bar to match and nothing frosted anywhere near it. The `!important` goes with the exception. It was here to beat the Tailwind `bg-zinc-200` utility on the element, and the surface rule further down beats that on specificity alone (`body:has(...) #platform-header`), so dropping it costs nothing and stops this rule silently outranking a later one. */ html[data-browser-scroller] :is(#platform-header, #landing-header) { position: sticky; top: var(--browser-banner-h); z-index: 30; } /* Faked glass, not a live blur: the landing scrolls under this header over the fixed wallpaper, so it paints its tint over the washes once (see "THE ONE FAKED LAYER"). */ html[data-browser-scroller] #landing-header { --fake-glass-tint: color-mix(in srgb, var(--home-ground) 92%, transparent); background: transparent; clip-path: inset(0); } html[data-browser-scroller="browse-screen"] #browse-search-bar { top: calc(var(--browser-banner-h) + var(--platform-header-h) + var(--platform-safe-top)); } html[data-browser-scroller^="auth-"] :is( #auth-login-screen, #auth-register-screen, #auth-waiting-screen ) > .min-h-full { min-height: calc(100dvh - var(--browser-banner-h)); } /* These screens are already below the strips in document flow. The bounded shell's separate offset on the corner Back link would count them twice. */ html[data-browser-scroller^="auth-"] body.is-offline [data-auth-back] { top: calc(env(safe-area-inset-top, 0px) + 1rem) !important; } html[data-browser-scroller="dev-forum-scroll"] :is(#app-view, #app-content), html[data-browser-scroller="dev-forum-scroll"] #app-content > div { flex: none !important; height: auto !important; overflow: visible !important; } /* During a tile zoom the outgoing page remains in document flow until the animation ends. Give the incoming app its final viewport bounds while both are painted, rather than measuring a zero-height flex child. */ html[data-browser-scroller]:not([data-browser-scroller="dev-forum-scroll"]) #app-view { position: fixed; top: calc(var(--browser-banner-h) + var(--platform-header-h) + var(--platform-safe-top) - .5rem); bottom: 0; left: 0; right: 0; height: auto !important; } html[data-browser-scroller="auth-landing-scroll"] #app-viewer { position: fixed; top: calc(var(--browser-banner-h) + var(--platform-header-h) + var(--platform-safe-top)); bottom: 0; left: 0; right: 0; } /* The home feed scroller: contain overscroll so a pull that starts on a short list can't chain to the browser's own refresh gesture. The anonymous landing scroller (the inner wrapper, not the fixed overlay — see index.html #auth-landing-scroll) carries its own kit pull-to-refresh (auth-screens.js _wireLanding) and needs the same containment. ── AND THE FEED SCROLLS ONE WAY ─────────────────────────────────── `overflow-x: hidden` is not belt and braces, it is the whole of a fix. Both of these are `overflow-y-auto` and NOTHING else, and CSS turns that into a scroller on BOTH axes: `overflow` computes `visible` to `auto` on one axis as soon as the other is not `visible`. So the home feed has always been a horizontal scroll container by accident, waiting for something inside it to be one pixel too wide — and on a phone something is. `.un-touch-target` (native.css) grows any control to a 44px hit box with an absolutely-positioned ::after CENTRED on it, so the ⋮ that opens an area's menu — `w-4`, 16px, and the last thing in the row — reaches 14px past itself on each side. The section's gutter is `px-3`. 12 < 14, so the box lands 2px beyond the viewport, and a 390px home screen measured 392px of scrollWidth: enough to drag the whole feed sideways and rubber-band it back, on every phone, for the sake of a tap area nobody can see. Clipping is right rather than merely convenient. That overhang is a HIT AREA, not content: it is meant to hang off its control, and this is the only thing that decides whether hanging off becomes geometry. The 2px it costs comes off the outside of a target that still extends 12px past a 16px button on that side. Nothing else in the feed is expected to escape it — the ⋮ menu itself is a kit popover, fixed and parented to , as is the drag-to-rearrange ghost (.un-reorder-ghost) — so a lift can still be carried to the screen edge and past it. `hidden` AND NOT `clip`, AND THAT IS NOT A BROWSER-SUPPORT HEDGE. `clip` reads like the better answer — it makes the box no scroll container on that axis at all, so there is not even an overflow region left — and it is simply not available here: CSS Overflow 3 says a `clip` sitting beside an `auto` on the other axis COMPUTES TO `hidden`, the same way `visible` beside it computes to `auto`. Written either way this box ends up `overflow-x: hidden`, which was measured, not assumed. So the axis keeps a 2px overflow region that `element.scrollLeft = n` could still move; no GESTURE reaches it, which is the whole of the reported bug, and nothing in the shell scrolls a feed sideways on purpose. tests/home-vertical-scroll-only.test.js pins the pair. */ #home-screen, #auth-landing-scroll { overscroll-behavior-y: contain; overflow-x: hidden; } /* ── EVERY PAGE BOUNCES, HOWEVER LITTLE IT HOLDS (#3566) ─────────────── "Should be able to over scroll on home page down, doesn't feel as native because can't", and after #3591 (#3565) gave Home's foot its bounce back in a phone browser, All communities still did not. A page's rubber band comes from one of two places, and a screen has one only if its own place gives it: - THE DOCUMENT, in a phone browser, for the screens browser-scroll.ts PAGES (Home, Discover, Leaderboard, Profile, Settings, a project page). #3591's `data-browser-past-top` gives its foot `contain`, which bounces. - ITS OWN SCROLLER everywhere else: every screen in the installed app and the native WebView, and in a phone browser the screens the document does not page (All communities, Your changes / requests / votes, the Messages list). Those roots are `overflow-y: auto` and the bounce is iOS's, which rubber-bands a scroller only when it CAN scroll. One with no range hands the drag to the document, which the bounded shell holds still on purpose (`html, body`: `overflow: hidden`, `overscroll-behavior-y: none`), so neither end moves. Measured at 390x664 (iPhone agent, touch), in the phone browser and the installed layout alike: #workshop-screen 572/572 and 620/620 (scrollHeight/clientHeight) with two cards on it, #profile-proposals- screen the same, and .messages-list-scroll 457/457 with one conversation. No range, so no bounce at either end. Home, Discover, Profile, Settings and Leaderboard bounced in the installed app only because this account's were longer than the screen; a new account's short page would not. SO EVERY PAGE SCROLLER HAS AT LEAST ONE PIXEL TO SCROLL, by #3544's mechanism for a project's short tabs (see "A SHORT TAB STILL HAS SOMETHING TO SCROLL" further down): a 1px box hung 1px below the scroller's bottom edge, which puts that pixel into its scrollable overflow whatever the content does. Absolute and offset from the scroller's own padding box, so neither a flex chain that fills the screen (Home's `.home-body-fill`, an open Settings section) nor a percentage floor can take it back. Past the fold of a long page it is a transparent pixel in the middle of the content and changes nothing. A PAGE SAYS IT IS ONE with `data-page-bounce` on its scroller: Home, Discover, All communities, Leaderboard, Profile, Your changes / requests / votes, Settings, Admin, and the Messages list. Every screen root among them is already its own containing block (`position: relative`, inline); the Messages list was not, and becomes one here: its rows are their own containing blocks, and nothing in it was positioned against anything further out (measured). ONLY WHERE THE SCROLLER IS THE PAGE: `html:not([data-browser-scroller])`. When the document pages a screen the root is `overflow: visible`, and the pixel would only lengthen the page; that bounce is #3591's. ONLY ON A TOUCH SCREEN: with a mouse, a pixel of range would put a scrollbar on a window that has nothing to scroll. NOT the Communities Needs you feed (`[data-workshop-pane="needs"]`): it is fitted to the screen on purpose (#3516) and scrolls inside, like a project's Needs you and Discussion, which #3544 leaves fitted too. NOT the chats (a Messages thread, Global Chat, an agent session): a transcript opens on its newest line and stays there; it is not a page. A project page is #3544's rule. tests/page-overscroll.test.js holds App.SCREEN_IDS against the attribute, so a new screen root carries it or is named there with its reason. */ @media (pointer: coarse) { html:not([data-browser-scroller]) [data-page-bounce] { position: relative; } html:not([data-browser-scroller]) [data-page-bounce]::after { content: ''; position: absolute; left: 0; bottom: -1px; width: 1px; height: 1px; pointer-events: none; } /* A rule of its own, so an engine without `:has()` drops only this. */ html:not([data-browser-scroller]) [data-page-bounce]:has([data-workshop-pane="needs"])::after { content: none; } } /* ── `.touch-target-32`: the kit's hit-slop, sized for a dense row ────── QA 2026-09-24 Q19. `.un-touch-target` (native.css) grows a control's hit box to 44px, which is right for a lone icon in a bar. In a DENSE row it is wrong: two Revoke buttons stacked 8px apart, or View and Delete sitting over an open file preview, and a 44px box reaches over the neighbour and takes its taps, because the later element's ::after paints on top. This is the same trick at the 32px a phone needs, which fits inside those gaps, and only on a coarse pointer: a mouse is precise enough to hit the control itself. Zero-specificity `position` for the same reason the kit gives. */ @media (pointer: coarse) { :where(.touch-target-32) { position: relative; } .touch-target-32::after { content: ""; position: absolute; left: 50%; top: 50%; width: max(100%, 32px); height: max(100%, 32px); transform: translate(-50%, -50%); } } /* A held launcher tile can select nearby text (such as Discover) even when the tile itself is non-selectable. Protect the whole launcher content before the long-press timer fires. The search field is outside #home-body so its text selection and editing callout remain available. */ #home-body { -webkit-user-select: none; user-select: none; -webkit-touch-callout: none; } /* ── The home ground ─────────────────────────────────────── The launcher's own wallpaper, ported layer for layer from the homescreen design's Figma export (a 402x874 phone frame): a warm cream page, a fine yellow paper grain, three gaussian-blurred colour discs and a blue halftone star tucked into the top-right corner. PAINTED ON THE BODY, on the home route and inside an app. The body is the fixed 100dvh column that the header and the screen roots all sit in, so one background here runs under both — the bar is cleared over it (below) and the star lands behind the bell, where the design puts it — and the washes never scroll: the grid and panels move over a wallpaper, not under a banner. The star is the one layer that rides the page — its position reads `--home-star-y`, which frontend/src/lib/wallpaper-scroll.ts writes on from the visible screen's scroll offset, so it slides away under the bar with the tiles and returns with them. The gradient layers are sized to the body (100% 100%), which is the viewport, so a long feed cannot stretch a wash across two screens. `body:has(:is():not(.hidden))` is the route test. The shell swaps screens by toggling `.hidden` on their roots (see frontend/src/lib/visibility-store.ts and App.SCREEN_IDS), so "this root is showing" IS "we are on this route", read from the DOM with no class for a module to publish. THE ROOTS are the launcher and everything the design treats as its peers — the app view (so tapping an app from the launcher leaves the bar exactly as it was: the frame covers everything below it, the wallpaper shows as the band behind the bell, and the push has nothing to animate in the bar), the leaderboard, the profile, the directory, settings, and the anonymous landing shell, so a signed-out visitor lands on the same page. The platform surfaces an app shows in its own frame (the Dev board, a session) sit on the wallpaper too, as the launcher's cards do. Messages and the admin console keep the `bg-zinc-100` ground and the zinc-200 bar: both are dense working surfaces, not pages. An engine without :has() (none the shell supports) simply keeps that everywhere. THE CREAM IS DIMMED. The export's page is #FFFEEA — 98% relative luminance, which is white with a cast to the eye, and a bright one: the greys most apps sit on (zinc-100, iOS's grouped background) are 88-90%. The ground here is the same hue at that luminance, #F4F2E4 (88%), and each wash is lowered by the same lightness step (about 3 points) so it keeps the presence it had on the export's cream rather than sinking into the dimmer page. The white cards read as cards on it, which on the export's page they only just did. THE DISCS are the export's blurred circles as radial gradients: each holds its fill to (r - 2σ), is at half opacity at r, and is gone by (r + 2σ), which is a gaussian edge to within what the eye reads. The two corner discs are anchored in px to their corners, as in the export; the mid-height one is anchored at 59% (515/874) so it stays mid-screen on a taller viewport instead of parking at one fixed offset. THE STAR AND THE GRAIN ARE INLINE, not files. app.css is the one asset the shell already precaches and build-scopes (/b//css/…), and a url() to a sibling image would need the same treatment in sw.js and in the build-scoped path parser — two more places to keep honest for two decorative layers. The grain is the export's own filter chain (fractalNoise → luminanceToAlpha → one discrete band → #FFEE6F) on one stitched SVG tile, under 1 KB — at 30% rather than the export's 50%, which is what a pixel sweep against the designer's own render settled on: at 50% the specks measured a third louder than hers. The star is the designer's own raster of the element WITH its "halftone dot screen" effect — 194x156, the export's 97x78 box at 2x, so it is pixel-exact on a 2x screen — set 32px in from the right and flush with the top, where the export puts it (its top point is already cropped in the raster, as the design crops it at the screen edge). It is one colour (#DEEDF8) at varying alpha, so it is stored as an indexed PNG: one palette entry at 32 alpha levels, which keeps the halftone intact at a quarter of the RGBA size. Do not rebuild it by hand — an SVG re-creation of the halftone came before it, and every engine drew it differently (Firefox drops blend modes inside an SVG image, for one); a raster is the same everywhere. DARK MODE IS THE SAME WALLPAPER ON THE INVERTED GROUND. The mock is a light-mode design, so the dark one is derived from it rather than drawn: the ground is the cream inverted (#0b0d1b — near black, a breath of blue), and every colour layer keeps its OWN hue on top of it. A plain inversion was tried first and lost the washes: inverted pastels sit a few lightness points above the inverted ground, which near black is nothing. So the washes are re-tuned instead — same lavender, rose and ember, the same alphas and geometry, at a lightness that reads on the dark ground (the ember a notch lower than the other two, since it is the most saturated of the three). The star stays periwinkle, which lifts off dark by itself, and the grain keeps its gold at a lower opacity, so it reads as a faint speckle rather than a glow. The .dark rule below sets those four values; everything else — the zoom surface, the cleared bar, the launch cover, the landing root — follows through the same custom properties in both modes. #agent-session-screen IS A ROOT TOO (#3082). An agent session is drawn on the dev session's lift ladder, whose strip is translucent glass over the body — so it has to be on this list or the glass frosts the bare `bg-zinc-100` / `dark:bg-zinc-950` body instead of the wallpaper. On a desktop the session usually shows inside #messages-screen (listed), which hid the omission; the side panel beside an app is phone-width, swaps `messages/agent/` for `agent/`, and so drew it gray. #profile-proposals-screen IS ONE TOO (#3498). Profile's Your changes, Your requests and Your votes are a drill-in off Me like Settings and the Leaderboard, drawn in the same plane cards, but the screen arrived after these lists and was on none of them: the page kept the gray body and the bar its zinc-200 surface. Every list here that names #workshop-screen, its React-owned sibling, names it as well. */ body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) { --home-ground: #f4f2e4; /* The kit's tile-zoom paints the moving #app-view on this (native.js sets its inline background to the variable), and it is read from the body's descendants, so this is where it has to follow the ground: the card that zooms open out of a tile carries the wallpaper itself — the kit lays the view out at its settled size and scales it with a transform, so the star and the washes grow out of the tile and land pixel-for-pixel on the body's, and nothing pops when the kit lifts the surface. */ --un-zoom-bg: var(--home-wallpaper); --home-star: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMIAAACcCAMAAAAau4SEAAAAYFBMVEXe7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fje7fiX04/GAAAAIHRSTlMACBAZISkxOkJKUlpja3N7hIyUnKWttb3Fztbe5u/3/3zanboAAAwlSURBVHja7VzZcqM4FLUW0AJCrJJAQvz/X05dAY6zdSeO7dg91ksmXZUaDpxz96vD4dIHIYzQARGuKsUJycqu78oMHxAhBB0e6aC8KIocISLbrpH4sR5+RUBk0zaSEKatM1WGH+nhMc0oQZRr66zmQvU++E5miGR5Rh4DQl5WimPe2DAHU3d2muM89hLzuqnFQ/AJ8aZtJZGDj8syDTbEZVmCU6QYzFDgJ4Qnkf4/cl4PFXWCwIvOh6nlD/XwBwTOWbQOiNTUtZnjPJQ5SucxAFDGeU6Vm5dl8c6YKS5xbAXOhOAZ2iDetxRkb0wtm2SJ4hwCQJlHnZXGmhIfDgjj+w43EFY+zoPq4MlfztzkdYihJk8INyWSf1giHQ67nMNbOfNHkfMBU0oJLlcIdhjGuESrOcLwz4/i1IRgmU5ECpNzPn0FiSnnjN73+185jqiom1rJFj7CEoP3yT+YKhO61oKge9YChhgIUdmM0zQ0ZrVIMcYk69CVzTiNNSeIMJbfabhBGGMU5WqYl2XqXXxlVKPRQ1xiLynKhBAZekL4RSIxguj9Euke5LwHw+e6nvR3CHNd64LVCcIc/AT/MQ0lYUqV7LoEQoQSjE4CgGN8/zVI69/hXA3W1PtX2AIMb1Qm27YR1/FtiGYZTQwoCk4QolxKhhEiTIgcg0x5CgxIzhj8xDnLwUXhLD/+JOnvpchxVnaT94MeNi3Mc3JxYyNrKInlBOEso/jw8qrQ26//fRLQQlcFQUT0zrWcENE51+QY887aOkOIt8Zoejiwdhgqcjiwpu8U/Ky7toCfuoGCIykGZysqe0j3JzPuFimuSFyfygEVw6yqFBCKZFnKpSEgAUiYkBUSxt8Fkemuqyii5bgsVlJajMtiOMbFGOPAEJJunvvsgKQNoaWHgzDT1MDPYXSaHA6it6YiiFZ+iV2uxjm9df/aqC5+DTQ6iWXbtVDJoGCEDysUvEIhp1/n/wXhMyLB701OmZ5iNDKHhws9p7S0fmpzTOTgrKYIiXboS4JIaUenf4dIn8kZfhe5aNy8xKlv6sHH2eqybJyfOslY2ZuhygnhuqklQSiHfsKncm6TnPUf5IzOl/Mbo4rAAuUYZ1yWRVHUiRjzNLppjtGbvjM+eNto3RprW1XIqu3aSjAmVaUkE+oUQtwhuFpsRXr0jjAXTIHSa0CE67ZVGas665yz41aJmNOzgLcNMcYwTaMPIfjRudF778zQm3EcTds7D0SyU3wNoa+HkKp6OC8KuRrptbqHycW8NYJsCxFWmXHsC5XKunF+ncV/cOKpCwuT32Ki7e9iTBDmyaUE1DVFXrZdU1BCBGgCI5xLCWEfxE4MqgM7NLJp5BvypkWlJMm08fM89YPfXuPypbOHc3Pcf38DcV4hjr3uJz+1UojGjU7nNKusMyVGpByGTqIDlm1bc3RAXKkigzeb51/tEWVV2yrKOqBAcOO8XONE17m4RKPKcojL3PKcdXEJmiBahzApdMCVdQNAKdpWs8MBZZx/NbL9ByCsRMovTaTl60QyndiIxM4j0o3lTN/LmbMk4+2Rz5Dz7h24bpv3RjWeBeHFqJoe6kmmElnRQjMXY1aWRZ4efbVAZ3jlT8N+CKKTaytW1xbhLfp4DpGOEEabvoKtVdmOk9Msy1XftxIjDITJU8CxvvVLtThSSQsCjNKt3tnH8+S7E2kc/bLEaeg6N8cwVGXZARSeM4ACfoJvX2X3Cz9IULc/RWvYV45/IdIXtbJ+jdl7P8clemvMOEMXSOvBg7w5r91oFUFHv/ANGb+HACEjSsG2EeV0Dds6r2WBOA190sigpAQjW1O8G1Uwpoz8jyGsRILEs2GFnX9GpOUcIrGfEWmXc0r/CWvBT19CzuEDOdefyBkfLtNKScE3LRrjnOmGVNI6uqyvI9iNql1dm9ZmnkMrWBryKQnCvKrKSxvVNz47F0JwVg4p5bHfi50+hhBD9wIB5YUUNL31q7V/MCSmmDV2jnHqzPxjvxDjfPQLLNsDjVN/cGko4OIYzqshLMvY9OHHfmE5kXNdymYcXZVhLJvkD6AscGlCZWVVCZIpePix7sJFYu6jUa1VCroZwcraZEwpyy9d+f4HIBBRSIapgOLLoLZ+cozn+4XbEwkRSkFtom5bxdZq3exDPNsvnMi5vo2cX2QtJSO8teM02t76LS+IL6L9jlHN92D7mC/coouTSmWEyUrrUlQGaqTeuLXk9UkA8hmEVmRkS3lu2cSFgWUYoYDZOwG10wjEsH+E8Gm+oPhOoGNZ+AZQCF9bJrwzpqISvsLi7fhHIn2aLxgtU/qfYcR1XbG1FHbtNiItVMnxXpyXBgQdxums8G/23dGYFn0qgUEzl9MnhK8QCaVGVa8Ih/HBeezt/BciLXdEpE3O0C5kFFrkbpr6sglflXP4fTm/jV9l07UqV1uF42NX93m+QH9/CiB505xi0Y2nlukbEO5gxGotmW0Q3BS/5xdYmluFvvUvjuBC31lla6nsDwnpJ35BZWobN9zbhb9woGnbsMqfZVQnnTdzhKL8Uc5PCOcSqfw7kZY7JtJ35RzuT877twD/7M1DGtVTCOGTr3DXru01kWYfzs4X8O8tTr7yCzGenS/AxCR9QKP6EmwjVq6NqieEH/uFv9SV7pRI35VzuD85Q4qCdwjv8oX1u+xzqt4MW9P2xaimlvmvG9Us25a/5ncBxvpdoPC4+oOmW1vnaiuF0WNr5PdSHpyXShWi8R8nnrN/tdfWdSuUttkKkoKprmsLitGvhXk4V2Ych2b4JP3fpwG2dSTvtwGHaSsLt1ubMMNb+n/7Qzgk/tNewfh612crztt1JkPlexHmCeH/SaS/yzl8KOf2fuSMUFaUpRT1GwjzBEOefjRp6HOoddVaZ5uirLpxGlspYYV7ajglsmk0/02jiqnshr7Vb4gUXdNP3vdKrKO3eZYxIXhOaSZ1XQma8do5oyihZde3v7RIv46ZrAVJN7xdO0oQpq5gdL1QBcHCJKMwPw2LMDSH2MhqxmRjraly/JL63C7/JEzwDK9l4fCu5xbcel1BJbQbHawfibaD3UKR1pGE6tdt9KZzIfihYmS3SPvY+Q0OldBKX4vz7yPUuE1CtmU3L7EXFMNEvSK5SkthRePWcM84yOJcK6j2YVToZfj/CeHLREJHIi1vVy0egEh/lrPVXZJzTnY5QwWcvJUzfy/nm5eTqKjdNNlu7/KkZnoMY8P3K53So5/+RVoWhr5EUwuMadG26XaSX6uEsdqeNKri7Dq478LWgqQdHfx+ixAloqA0sEYQglHbtMdwQwK9REfQri9S03YfTz9C0BzTbQ/udF8NpbWj1OVPewoUBiJeDzzfslEF7ULNqym+rOqk0ZZEJAebbWaAvbe93Lu33LdrbSAy7ZO8X4+d37K6B03bvqjDhyWv0GTKx9AAhNcbU2i7XAhXPkwVzoo3w/+3aNr+QxDeEGn5gEjmzokEfecfyPlwB3IG10Z2CNbaKcxhMnWhB2NqaHp80c4fl8LozUthsLrHeb0SKQxKG2sbmdOMwddB33gV61u/OQREeFVrXW3DntGUlbEWLodI8kVff/TVe/8CkQjXdprcsTE19caHYGuB80rrr2yVb/dgILiYUSB8ezlTCWOe83EZeG1RTX1JOGzc/h3CfokEVm60JSa3N6r/AISPiDR/i0j0t4mU5Fx/KufDA8gZYaa0VlLbtCzs6hwslPzB67t5sA1JsLNQ0lpXthkmXzSmf6iq3QpBinVQVvYedvgLURlrIDf+KQH2RtVxFuN6iNY5VdGv2yRNUU8h9IIisl3tcebL39uFqfO5aeJqM9tpyFOmfD/6dbDQSIrIfo3Zt1W1QtiatkjUjWbXlfU/AOE1kWoB/YUGLs66JJGuO/z/Ws6cQn/hEvcd3VDOp0a1Sa4sz8gDXp+9uTZJ0SNcpPj+/cP9SGu+UCQIF/aquziup4X1fqQ1zOvAErH1yqeL5eRboHGFdaT9HaXLhbI12LZlDrdSyUsOIGzF+Wsshf07EFYi0VMiXfZay+sT6UM548uq+dpyPi3CZI/oD16XwvDDPTR6IdLN/ncXfu1JZvu9edf/yhfXwn4jw37p3A0g4CeEf5BI/4Kcn+d5nud5nud5nud5nud5nud5nud5zj//Ac7b73f5xK5wAAAAAElFTkSuQmCC"); --home-grain: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='240' height='240'%3E%3Cfilter id='n' x='0' y='0' width='100%' height='100%' color-interpolation-filters='sRGB'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='.3333' numOctaves='3' seed='8632' stitchTiles='stitch'/%3E%3CfeColorMatrix type='luminanceToAlpha'/%3E%3CfeComponentTransfer result='a'%3E%3CfeFuncA type='discrete' tableValues='0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0'/%3E%3C/feComponentTransfer%3E%3CfeFlood flood-color='%23FFEE6F' flood-opacity='.3'/%3E%3CfeComposite in2='a' operator='in'/%3E%3C/filter%3E%3Crect width='240' height='240' filter='url(%23n)'/%3E%3C/svg%3E"); /* THE WHOLE WALLPAPER AS ONE SHORTHAND VALUE, so the body and the zoom surface paint the identical thing. The kit assigns the moving view's `background` (the shorthand) from --un-zoom-bg, so a multi-layer shorthand is what that variable has to hold; the body uses the same value, and the 640px rule below swaps in the wider one. Each layer is ` / `, the colour rides on the last. */ --home-washes: radial-gradient(circle at calc(100% - 92px) 115px, rgba(229, 216, 239, 0.55) 138px, rgba(229, 216, 239, 0.275) 198px, rgba(229, 216, 239, 0) 258px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at calc(100% - 62px) 59%, rgba(245, 215, 230, 0.65) 50px, rgba(245, 215, 230, 0.325) 120px, rgba(245, 215, 230, 0) 190px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at 70px calc(100% - 69px), rgba(252, 219, 212, 0.75) 90px, rgba(252, 219, 212, 0.375) 170px, rgba(252, 219, 212, 0) 250px) 0 0 / 100% 100% no-repeat var(--home-ground); --home-wallpaper: var(--home-star) right 32px top var(--home-star-y, 0px) / 97px 78px no-repeat, var(--home-grain) 0 0 / 240px 240px repeat, var(--home-washes); background: var(--home-wallpaper); } /* THE WALLPAPER FOLLOWS THE APP'S TONE AS WELL AS THE SHELL'S (#1945). The dark rule below fires for the dark shell, as it always did, AND for a dark app under the light shell; the light base above it holds for the light shell and for a light app under the dark shell. `data-app-tone` is what features/app-frame/app-tone.js writes on from the page colour the framed app's bridge reports, and it exists only while that app is on screen — so on every other route these selectors are exactly the two they were. See "THE BAR TAKES THE APP'S TONE" below for the tokens that ride along with the ground. */ :is(.dark:not([data-app-tone="light"]), [data-app-tone="dark"]) body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) { --home-ground: #0b0d1b; /* THE STAR IS AS QUIET HERE AS IT IS ON CREAM. The same halftone raster, with its one palette entry re-tinted: #DEEDF8 on #F4F2E4 is a faint cool cast a reader notices only when looking for it, and that same near-white blue on a near-black page is the loudest thing on the screen. Matched in CIE Lab rather than by eye — the light pair sits ~14 dE apart, and #1A2239 on this ground is ~12, which is the same "there, but not announcing itself". The geometry, the alpha ramp and the file are untouched; only the palette entry differs. */ --home-star: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAMIAAACcCAMAAAAau4SEAAAAYFBMVEUaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjkaIjlBgHcuAAAAIHRSTlMACBAZISkxOkJKUlpja3N7hIyUnKWttb3Fztbe5u/3/3zanboAAAwlSURBVHja7VzZcqM4FLUW0AJCrJJAQvz/X05dAY6zdSeO7dg91ksmXZUaDpxz96vD4dIHIYzQARGuKsUJycqu78oMHxAhBB0e6aC8KIocISLbrpH4sR5+RUBk0zaSEKatM1WGH+nhMc0oQZRr66zmQvU++E5miGR5Rh4DQl5WimPe2DAHU3d2muM89hLzuqnFQ/AJ8aZtJZGDj8syDTbEZVmCU6QYzFDgJ4Qnkf4/cl4PFXWCwIvOh6nlD/XwBwTOWbQOiNTUtZnjPJQ5SucxAFDGeU6Vm5dl8c6YKS5xbAXOhOAZ2iDetxRkb0wtm2SJ4hwCQJlHnZXGmhIfDgjj+w43EFY+zoPq4MlfztzkdYihJk8INyWSf1giHQ67nMNbOfNHkfMBU0oJLlcIdhjGuESrOcLwz4/i1IRgmU5ECpNzPn0FiSnnjN73+185jqiom1rJFj7CEoP3yT+YKhO61oKge9YChhgIUdmM0zQ0ZrVIMcYk69CVzTiNNSeIMJbfabhBGGMU5WqYl2XqXXxlVKPRQ1xiLynKhBAZekL4RSIxguj9Euke5LwHw+e6nvR3CHNd64LVCcIc/AT/MQ0lYUqV7LoEQoQSjE4CgGN8/zVI69/hXA3W1PtX2AIMb1Qm27YR1/FtiGYZTQwoCk4QolxKhhEiTIgcg0x5CgxIzhj8xDnLwUXhLD/+JOnvpchxVnaT94MeNi3Mc3JxYyNrKInlBOEso/jw8qrQ26//fRLQQlcFQUT0zrWcENE51+QY887aOkOIt8Zoejiwdhgqcjiwpu8U/Ky7toCfuoGCIykGZysqe0j3JzPuFimuSFyfygEVw6yqFBCKZFnKpSEgAUiYkBUSxt8Fkemuqyii5bgsVlJajMtiOMbFGOPAEJJunvvsgKQNoaWHgzDT1MDPYXSaHA6it6YiiFZ+iV2uxjm9df/aqC5+DTQ6iWXbtVDJoGCEDysUvEIhp1/n/wXhMyLB701OmZ5iNDKHhws9p7S0fmpzTOTgrKYIiXboS4JIaUenf4dIn8kZfhe5aNy8xKlv6sHH2eqybJyfOslY2ZuhygnhuqklQSiHfsKncm6TnPUf5IzOl/Mbo4rAAuUYZ1yWRVHUiRjzNLppjtGbvjM+eNto3RprW1XIqu3aSjAmVaUkE+oUQtwhuFpsRXr0jjAXTIHSa0CE67ZVGas665yz41aJmNOzgLcNMcYwTaMPIfjRudF778zQm3EcTds7D0SyU3wNoa+HkKp6OC8KuRrptbqHycW8NYJsCxFWmXHsC5XKunF+ncV/cOKpCwuT32Ki7e9iTBDmyaUE1DVFXrZdU1BCBGgCI5xLCWEfxE4MqgM7NLJp5BvypkWlJMm08fM89YPfXuPypbOHc3Pcf38DcV4hjr3uJz+1UojGjU7nNKusMyVGpByGTqIDlm1bc3RAXKkigzeb51/tEWVV2yrKOqBAcOO8XONE17m4RKPKcojL3PKcdXEJmiBahzApdMCVdQNAKdpWs8MBZZx/NbL9ByCsRMovTaTl60QyndiIxM4j0o3lTN/LmbMk4+2Rz5Dz7h24bpv3RjWeBeHFqJoe6kmmElnRQjMXY1aWRZ4efbVAZ3jlT8N+CKKTaytW1xbhLfp4DpGOEEabvoKtVdmOk9Msy1XftxIjDITJU8CxvvVLtThSSQsCjNKt3tnH8+S7E2kc/bLEaeg6N8cwVGXZARSeM4ACfoJvX2X3Cz9IULc/RWvYV45/IdIXtbJ+jdl7P8clemvMOEMXSOvBg7w5r91oFUFHv/ANGb+HACEjSsG2EeV0Dds6r2WBOA190sigpAQjW1O8G1Uwpoz8jyGsRILEs2GFnX9GpOUcIrGfEWmXc0r/CWvBT19CzuEDOdefyBkfLtNKScE3LRrjnOmGVNI6uqyvI9iNql1dm9ZmnkMrWBryKQnCvKrKSxvVNz47F0JwVg4p5bHfi50+hhBD9wIB5YUUNL31q7V/MCSmmDV2jnHqzPxjvxDjfPQLLNsDjVN/cGko4OIYzqshLMvY9OHHfmE5kXNdymYcXZVhLJvkD6AscGlCZWVVCZIpePix7sJFYu6jUa1VCroZwcraZEwpyy9d+f4HIBBRSIapgOLLoLZ+cozn+4XbEwkRSkFtom5bxdZq3exDPNsvnMi5vo2cX2QtJSO8teM02t76LS+IL6L9jlHN92D7mC/coouTSmWEyUrrUlQGaqTeuLXk9UkA8hmEVmRkS3lu2cSFgWUYoYDZOwG10wjEsH+E8Gm+oPhOoGNZ+AZQCF9bJrwzpqISvsLi7fhHIn2aLxgtU/qfYcR1XbG1FHbtNiItVMnxXpyXBgQdxums8G/23dGYFn0qgUEzl9MnhK8QCaVGVa8Ih/HBeezt/BciLXdEpE3O0C5kFFrkbpr6sglflXP4fTm/jV9l07UqV1uF42NX93m+QH9/CiB505xi0Y2nlukbEO5gxGotmW0Q3BS/5xdYmluFvvUvjuBC31lla6nsDwnpJ35BZWobN9zbhb9woGnbsMqfZVQnnTdzhKL8Uc5PCOcSqfw7kZY7JtJ35RzuT877twD/7M1DGtVTCOGTr3DXru01kWYfzs4X8O8tTr7yCzGenS/AxCR9QKP6EmwjVq6NqieEH/uFv9SV7pRI35VzuD85Q4qCdwjv8oX1u+xzqt4MW9P2xaimlvmvG9Us25a/5ncBxvpdoPC4+oOmW1vnaiuF0WNr5PdSHpyXShWi8R8nnrN/tdfWdSuUttkKkoKprmsLitGvhXk4V2Ych2b4JP3fpwG2dSTvtwGHaSsLt1ubMMNb+n/7Qzgk/tNewfh612crztt1JkPlexHmCeH/SaS/yzl8KOf2fuSMUFaUpRT1GwjzBEOefjRp6HOoddVaZ5uirLpxGlspYYV7ajglsmk0/02jiqnshr7Vb4gUXdNP3vdKrKO3eZYxIXhOaSZ1XQma8do5oyihZde3v7RIv46ZrAVJN7xdO0oQpq5gdL1QBcHCJKMwPw2LMDSH2MhqxmRjraly/JL63C7/JEzwDK9l4fCu5xbcel1BJbQbHawfibaD3UKR1pGE6tdt9KZzIfihYmS3SPvY+Q0OldBKX4vz7yPUuE1CtmU3L7EXFMNEvSK5SkthRePWcM84yOJcK6j2YVToZfj/CeHLREJHIi1vVy0egEh/lrPVXZJzTnY5QwWcvJUzfy/nm5eTqKjdNNlu7/KkZnoMY8P3K53So5/+RVoWhr5EUwuMadG26XaSX6uEsdqeNKri7Dq478LWgqQdHfx+ixAloqA0sEYQglHbtMdwQwK9REfQri9S03YfTz9C0BzTbQ/udF8NpbWj1OVPewoUBiJeDzzfslEF7ULNqym+rOqk0ZZEJAebbWaAvbe93Lu33LdrbSAy7ZO8X4+d37K6B03bvqjDhyWv0GTKx9AAhNcbU2i7XAhXPkwVzoo3w/+3aNr+QxDeEGn5gEjmzokEfecfyPlwB3IG10Z2CNbaKcxhMnWhB2NqaHp80c4fl8LozUthsLrHeb0SKQxKG2sbmdOMwddB33gV61u/OQREeFVrXW3DntGUlbEWLodI8kVff/TVe/8CkQjXdprcsTE19caHYGuB80rrr2yVb/dgILiYUSB8ezlTCWOe83EZeG1RTX1JOGzc/h3CfokEVm60JSa3N6r/AISPiDR/i0j0t4mU5Fx/KufDA8gZYaa0VlLbtCzs6hwslPzB67t5sA1JsLNQ0lpXthkmXzSmf6iq3QpBinVQVvYedvgLURlrIDf+KQH2RtVxFuN6iNY5VdGv2yRNUU8h9IIisl3tcebL39uFqfO5aeJqM9tpyFOmfD/6dbDQSIrIfo3Zt1W1QtiatkjUjWbXlfU/AOE1kWoB/YUGLs66JJGuO/z/Ws6cQn/hEvcd3VDOp0a1Sa4sz8gDXp+9uTZJ0SNcpPj+/cP9SGu+UCQIF/aquziup4X1fqQ1zOvAErH1yqeL5eRboHGFdaT9HaXLhbI12LZlDrdSyUsOIGzF+Wsshf07EFYi0VMiXfZay+sT6UM548uq+dpyPi3CZI/oD16XwvDDPTR6IdLN/ncXfu1JZvu9edf/yhfXwn4jw37p3A0g4CeEf5BI/4Kcn+d5nud5nud5nud5nud5nud5nud5zj//Ac7b73f5xK5wAAAAAElFTkSuQmCC"); /* NO GRAIN IN DARK MODE. The speck field is a scatter of gold dots at a low opacity: on cream it is the paper's tooth, which is what the export draws it as. On a near-black ground the same dots are little bright points — the page read as a starfield, which is a different picture from the one the design is of. Dropped rather than dimmed: at an opacity low enough to stop reading as stars it was not visible at all, so the layer was costing a repeat paint for nothing. is a valid layer image, so the shorthands below keep their shape and the desktop rule needs no second copy. */ --home-grain: none; --home-washes: radial-gradient(circle at calc(100% - 92px) 115px, rgba(80, 48, 105, 0.55) 138px, rgba(80, 48, 105, 0.275) 198px, rgba(80, 48, 105, 0) 258px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at calc(100% - 62px) 59%, rgba(117, 36, 77, 0.65) 50px, rgba(117, 36, 77, 0.325) 120px, rgba(117, 36, 77, 0) 190px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at 70px calc(100% - 69px), rgba(118, 31, 15, 0.75) 90px, rgba(118, 31, 15, 0.375) 170px, rgba(118, 31, 15, 0) 250px) 0 0 / 100% 100% no-repeat var(--home-ground); --home-wallpaper: var(--home-star) right 32px top var(--home-star-y, 0px) / 97px 78px no-repeat, var(--home-grain) 0 0 / 240px 240px repeat, var(--home-washes); } /* WIDE VIEWPORTS. The three discs above are the phone frame's, anchored in px to its corners, and on a desktop window they shrink into the corners and leave a field of plain cream. From the shell's desktop breakpoint four more washes join them — the same three tints, sized in viewport units so they scale with the window rather than with the phone, and placed across the middle of the page where the frame's discs never reach. The dark rule above is the more specific selector, so it would keep the phone layers at every width on its own — the second rule here gives dark the same four extra washes, in its own tints. */ @media (min-width: 640px) { body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) { --home-washes: radial-gradient(circle at calc(100% - 92px) 115px, rgba(229, 216, 239, 0.55) 138px, rgba(229, 216, 239, 0.275) 198px, rgba(229, 216, 239, 0) 258px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at calc(100% - 62px) 59%, rgba(245, 215, 230, 0.65) 50px, rgba(245, 215, 230, 0.325) 120px, rgba(245, 215, 230, 0) 190px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at 70px calc(100% - 69px), rgba(252, 219, 212, 0.75) 90px, rgba(252, 219, 212, 0.375) 170px, rgba(252, 219, 212, 0) 250px) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 38vw 36vh at 24% 20%, rgba(229, 216, 239, 0.65), rgba(229, 216, 239, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 36vw 32vh at 66% 76%, rgba(245, 215, 230, 0.65), rgba(245, 215, 230, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 32vw 32vh at 4% 64%, rgba(252, 219, 212, 0.7), rgba(252, 219, 212, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 34vw 28vh at 90% 32%, rgba(229, 216, 239, 0.55), rgba(229, 216, 239, 0) 70%) 0 0 / 100% 100% no-repeat var(--home-ground); --home-wallpaper: var(--home-star) right 32px top var(--home-star-y, 0px) / 97px 78px no-repeat, var(--home-grain) 0 0 / 240px 240px repeat, var(--home-washes); } :is(.dark:not([data-app-tone="light"]), [data-app-tone="dark"]) body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) { --home-washes: radial-gradient(circle at calc(100% - 92px) 115px, rgba(80, 48, 105, 0.55) 138px, rgba(80, 48, 105, 0.275) 198px, rgba(80, 48, 105, 0) 258px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at calc(100% - 62px) 59%, rgba(117, 36, 77, 0.65) 50px, rgba(117, 36, 77, 0.325) 120px, rgba(117, 36, 77, 0) 190px) 0 0 / 100% 100% no-repeat, radial-gradient(circle at 70px calc(100% - 69px), rgba(118, 31, 15, 0.75) 90px, rgba(118, 31, 15, 0.375) 170px, rgba(118, 31, 15, 0) 250px) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 38vw 36vh at 24% 20%, rgba(80, 48, 105, 0.65), rgba(80, 48, 105, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 36vw 32vh at 66% 76%, rgba(117, 36, 77, 0.65), rgba(117, 36, 77, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 32vw 32vh at 4% 64%, rgba(118, 31, 15, 0.7), rgba(118, 31, 15, 0) 70%) 0 0 / 100% 100% no-repeat, radial-gradient(ellipse 34vw 28vh at 90% 32%, rgba(80, 48, 105, 0.55), rgba(80, 48, 105, 0) 70%) 0 0 / 100% 100% no-repeat var(--home-ground); --home-wallpaper: var(--home-star) right 32px top var(--home-star-y, 0px) / 97px 78px no-repeat, var(--home-grain) 0 0 / 240px 240px repeat, var(--home-washes); } } /* THE HEADER STAYS CLEAR OF THE STAR in a running app and on New project (polish N20). On Home the star sits behind the bell by design, but over somebody's app the bar is the app's header, and on the make screen the bar holds only the ✕ and the mark: there it read as a stray shape showing through. Both draw the same wallpaper with its first layer, the star, left out. `html:root` lifts this past the dark and wide rules above, which define the full shorthand at the same route test. The make screen paints `var(--home-wallpaper)` on its own root (make.tsx), so the variable is redefined there too; it reads the body's grain and washes. */ html:root body:has(#app-view:not(.hidden):not([data-app-surface="platform"])), [data-first-session-make] { --home-wallpaper: var(--home-grain) 0 0 / 240px 240px repeat, var(--home-washes); } /* THE BAR OVER THE WALLPAPER. On every wallpaper route the header's zinc-200 surface goes, so the wallpaper (and the star) run up behind the bell — the one place the design's "page ground runs to the top of the screen" is literal. (#landing-header never had a surface; it sits on the body's ground already.) The controls on it carry their own periwinkle fill and hairline (--brand-tint / --brand-line), so they still lift off cream and off dark alike. Everywhere else the bar keeps its surface — see the "THE BAR'S OWN SURFACE" note in platform-header.tsx for why it has one. The view-transition group note above (#platform-header is opaque) has its exception here, and it is what makes the launcher → app push read as one bar: both routes paint the same wallpaper under the same cleared bar, so the bar's snapshot is identical on both sides of the transition and only the page moves. */ body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #global-chat-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) #platform-header { background-color: transparent; } /* ── THE BAR IS THE SAME MATERIAL AS THE BAR AT THE FOOT (#2718 review) ── The rule above clears the header on every screen that paints the wallpaper, so the ground runs straight through it. That was right while the bar floated alone on a page; it is wrong now that a second bar is on screen with it, because the two are the same KIND of thing — the platform's own chrome around somebody's content — and they were drawn as two different ones: `.platform-tabs` a frosted wall with a hairline, the header nothing at all. So the header takes the tab bar's surface exactly: `--dc-sheet-fill` under `--dc-frost`, the pane material every floating surface in the shell wears. On a desktop the rail and the header meet at the corner and read as one continuous edge around the page, which is what the design draws. NOT INSIDE AN APP, and not signed out. `#app-view` keeps the clear bar because there is no tab bar there to match and the strip takes the APP's tone instead (`data-app-tone`, #1945) — a frost over somebody else's page colour is a smear, not a surface. The auth screens have no bar either. NO BORDER-BOTTOM. The tab bar's hairline is its top edge meeting the page; this bar's bottom edge is `rounded-b-2xl -mb-2`, a notch every platform surface below tucks 8px up into, so a line drawn across it would cut the notch in half. The frost IS the edge here. */ body:has(:is(#home-screen, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #global-chat-screen, #agent-session-screen, #profile-proposals-screen):not(.hidden)) #platform-header { background-color: var(--dc-sheet-fill); backdrop-filter: var(--dc-frost); -webkit-backdrop-filter: var(--dc-frost); } /* …AND OVER AN APP'S OWN WORKSHOP (#2806). The exclusion above is about the APP: its page colour is under the bar, and the bar takes that tone instead. An app's Workshop tab (board, sessions, a discussion) is not the app, it is the platform's own page about it — `data-app-surface="platform"`, set by AppView._setSurface for everything the shell renders into #app-content — and with the frame parked there is no app tone either (toneForState answers null). So it is the same chrome as the standalone Workshop screen and wears the same glass; left clear, the bar went bare on exactly those pages and nowhere else. A separate rule, not a widened selector: the one above is pinned to exclude #app-view, because a running app must stay clear. */ body:has(#app-view:not(.hidden)[data-app-surface="platform"]) #platform-header { background-color: var(--dc-sheet-fill); backdrop-filter: var(--dc-frost); -webkit-backdrop-filter: var(--dc-frost); } /* …AND THE HEADER, faked the same way as the tab bar ("FAKED GLASS" below; its layer is in the shared rule there), on exactly the routes the glass rules above cover. The clip follows the bar's own `rounded-b-2xl` (1.25rem in tailwind.config.js), so the notch the surfaces below tuck into keeps its shape. Nothing inside the header reaches past its box, so the clip cuts nothing. */ body:has(:is(#home-screen, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #global-chat-screen, #agent-session-screen, #profile-proposals-screen):not(.hidden)) #platform-header, body:has(#app-view:not(.hidden)[data-app-surface="platform"]) #platform-header { background-color: transparent; clip-path: inset(0 round 0 0 1.25rem 1.25rem); } /* THE STRIP OVER THE BAR FOLLOWS IT HOME (onboarding run three, 12 Oct 2026, iPhone 17 Safari 26). In a browser tab Safari colours the strip behind the status bar from the fixed bar's own `background-color`, and only an opaque one: the project's green bar turned it green, and back on Home, whose bar is transparent with its glass drawn by the layer below, it stayed green (measured on a copy: green, then transparent, held the green; an opaque colour took it back at once). So the bar here has an opaque ground under its glass, the glass's own solid plane colour. The layer covers it whole (its washes end on the ground colour), so nothing on the bar changes; only the strip does. */ html.un-ios.web-browser-chrome:not([data-community-tint]) body:has(:is(#home-screen, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #global-chat-screen, #agent-session-screen, #profile-proposals-screen):not(.hidden)) #platform-header, html.un-ios.web-browser-chrome:not([data-community-tint]) body:has(#app-view:not(.hidden)[data-app-surface="platform"]) #platform-header { background-color: var(--dc-sheet-solid); } /* …AND ON THE APP TAB, WHERE THE PAGE IS NOT THE SCROLLER (newcomer run six, 14 Oct 2026, iPhone Safari 26). Safari takes the strip's colour from a bar FIXED (or sticky) at the top. On the routes above a phone browser scrolls the document (lib/browser-scroll.ts), so the bar is sticky (`html[data-browser-scroller]`) and the strip follows its ground. The App tab of a first version being built is the platform's own page, but the document is not its scroller (pageScroller answers only the project's own pages, #dev-forum-scroll), so its bar sat in the flow, Safari found no bar to take a colour from, and the strip stayed the hub's teal over the App tab's light bar. Sticky at the top here as well: the page does not scroll, so the bar stays exactly where it was, and the strip takes the opaque ground the rule above gives it. Back on the hub the bar is sticky and tinted again (`data-community-tint`), and the strip turns teal. …AND ON EVERY OTHER SCREEN THE DOCUMENT DOES NOT SCROLL (newcomer run seven, 14 Oct 2026, iPhone Safari 26): from the hub to Messages the strip stayed teal over Messages' light bar, for the same reason. Of the routes above, only Home, Browse, Leaderboard, Profile and Settings are page scrollers (lib/browser-scroll.ts PAGES); Messages, Communities, #general, an agent's session and a profile's proposals each scroll an element of their own, so their bar is sticky here too. Sticky changes no layout on them: it offsets the bar only when its nearest scroller, (`overflow: hidden`, 100dvh), scrolls, and nothing scrolls it, so the bar stays where it sits in the flow; and it is already `relative z-10`, so it was a stacking context and a containing block before. */ html.un-ios.web-browser-chrome:not([data-community-tint]):not([data-browser-scroller]) body:has(:is(#messages-screen, #workshop-screen, #global-chat-screen, #agent-session-screen, #profile-proposals-screen):not(.hidden)) #platform-header, html.un-ios.web-browser-chrome:not([data-community-tint]):not([data-browser-scroller]) body:has(#app-view:not(.hidden)[data-app-surface="platform"]) #platform-header { position: sticky; top: 0; } /* THE BAR TAKES THE APP'S TONE (#1945). A dark app under the light shell used to sit beneath a cream strip, and a light app under the dark shell beneath a night one: the bar has no surface inside an app, so the shell's wallpaper ran up behind its controls whatever colour the page under them was. The framed app's bridge already tells the shell its opaque page colour (`__usernode_background`, #1581); features/app-frame/app-tone.js reads it as a tone and writes `data-app-tone` on while the frame is on screen. The wallpaper rules above key off it, and these carry the tokens that have to move with the ground: the bar's periwinkle controls (--brand-*: the chip, the bell, the back disc, which "lift off cream and off dark alike" only with the value for the ground they are on) and the sheet edge (--app-sheet-*: a black hairline is invisible on a night ground, a white one on cream). SCOPED TO THE BAR AND THE SHEET, deliberately, rather than to . The theme is still the shell's: `.dark` on is the theme module's alone and every `dark:` utility keeps reading it. The sheets, dialogs and menus opened over a dark app follow its tone too since #2803, but by carrying `.dark` themselves (lib/surface-tone.ts, and the `.platform-app-tone-dark` rule below), not through these tokens. Custom properties inherit, so setting them on the two elements reaches every control and edge inside them and nothing outside. The chip's subtitle is the one control drawn with a `dark:` utility rather than a brand token, so it is re-inked here by hand. THE INK AND THE SURFACES MOVE WITH THE GROUND TOO (#2704) — and that is what these blocks were missing. The ground is repainted PAGE-WIDE (the wallpaper rules above put --home-ground at #0b0d1b for a dark app under the light shell), but the tokens were scoped here and carried only the brand controls and the sheet edge. So everything inside the bar and the sheet that inks itself from the platform's text ramp, or paints itself from its surface tokens, kept the LIGHT values on a ground that had already gone dark. That is the hybrid: a dark page with light-theme parts on it, which is exactly as readable as it sounds. THE LAUNCH COVER IS WHERE IT WAS WORST, and it is on screen every time an app opens. .app-launch-cover takes --home-ground (the rule above) and .app-launch-cover-name takes --text-primary, so the app's own name was painted #0a0a0a on #0b0d1b: 1.03:1, which is not dim, it is gone. The mirror case is identical — a light app under the dark shell put #f5f5f7 on cream, also 1.03:1. Carrying the ramp takes both to 17.6:1, which is the contrast the same cover already had in the untoned theme. THE VALUES ARE THE THEME'S OWN, dark tone from `.dark` and light tone from `:root`, so a toned surface stays byte-identical to a themed one — the invariant tests/app-tone.test.js already pins for the brand tokens. --text-faint and --text-muted are one value in both themes today and are carried anyway, so the ramp is complete and a later divergence cannot quietly reopen the split. STILL SCOPED TO THE BAR AND THE SHEET, and still never to . This widens what the strip repaints; it does not widen what the strip is. The floating surfaces are the next block's job. */ [data-app-tone="dark"]:not(.dark) #platform-header, [data-app-tone="dark"]:not(.dark) #app-frame-host { color: #eaeaea; /* zinc-100, the body's dark ink */ --text-primary: #f5f5f7; --text-secondary: #e3e3e6; --text-muted: #98989d; --text-faint: #8e8e93; --bg-primary: #0b0b0c; --bg-secondary: #1c1c1e; --border: #2c2c2e; --border-light: #3a3a3c; --brand-ink: #c7d0f5; --brand-tint: #262b45; --brand-line: #3a4270; --app-sheet-line: rgba(255, 255, 255, 0.12); --app-sheet-shadow-near: rgba(0, 0, 0, 0.55); --app-sheet-shadow-far: rgba(0, 0, 0, 0.4); } .dark[data-app-tone="light"] #platform-header, .dark[data-app-tone="light"] #app-frame-host { color: #1c1c1e; /* zinc-900, the body's light ink */ --text-primary: #0a0a0a; --text-secondary: #3a3a3c; --text-muted: #68686c; --text-faint: #8e8e93; --bg-primary: #ffffff; --bg-secondary: #f5f5f7; --border: #d1d1d6; --border-light: #e3e3e6; --brand-ink: #37477b; --brand-tint: #e4e9f7; --brand-line: #c9d2f2; --app-sheet-line: rgba(0, 0, 0, 0.1); --app-sheet-shadow-near: rgba(24, 39, 75, 0.12); --app-sheet-shadow-far: rgba(24, 39, 75, 0.08); } /* THE ICON TILE IS THE ONE SURFACE THE CARRIED TOKENS CANNOT REACH ON THEIR OWN. .app-icon-tile draws its face from --bg-primary and its ring from --border-light, and dark mode does not simply hand those tokens dark values for it: `.dark .app-icon-tile` steps the face UP to --bg-secondary and the ring DOWN to --border, because --bg-primary is near-black and a tile painted in it reads as a hole in the page rather than a surface on it (that rule carries the whole argument). The step is keyed to the CLASS, so under a tone it never happened — the app's own icon stayed a white square on the near-black launch cover, beside the name that had gone invisible. These are that rule's twins, scoped to the sheet the tone owns and reading the tokens carried above. Same reason the chip's subtitle is re-inked by hand below. */ [data-app-tone="dark"]:not(.dark) #app-frame-host .app-icon-tile { background-color: var(--bg-secondary); border-color: var(--border); } .dark[data-app-tone="light"] #app-frame-host .app-icon-tile { background-color: var(--bg-primary); border-color: var(--border-light); } [data-app-tone="dark"]:not(.dark) #platform-header #app-switcher-subtitle { color: #8e8e93; /* zinc-400 */ } .dark[data-app-tone="light"] #platform-header #app-switcher-subtitle { color: #68686c; /* zinc-500 */ } /* …AND THE SIDEBAR BESIDE THE APP. On a desktop the rail stays docked beside a running app (App._railBesideApp), so it is part of the strip around the app just as the bar is, and it takes the same tone: with the shell's own values it drew a pale column (a white half-fill over the toned, night wallpaper) beside a dark bar, or a night one beside a light bar. A DARK APP UNDER THE LIGHT SHELL puts `.dark` on the rail and its parked foot (lib/surface-tone.ts, the way the sheets over a dark app follow it, #2803), so the theme's own dark palette draws them: fill, ink, lit row, counts and tiles, with nothing restated here. A LIGHT APP UNDER THE DARK SHELL cannot do that (`.dark` cannot be taken away below a dark ), so the light values are carried here, the theme's own from `:root`, as the bar's are above. The two plane fills are set on the rail itself rather than as tokens: `--dc-sheet-fill` and `--dc-sheet-solid` are declared once per theme and nowhere else (tests/no-glass-one-scheme.test.js), so the rail paints `:root`'s values directly, on the desktop, where it is a rail. */ .dark[data-app-tone="light"] #platform-tabs, .dark[data-app-tone="light"] #platform-parked { color: #1c1c1e; /* zinc-900, the body's light ink */ color-scheme: light; --text-primary: #0a0a0a; --text-secondary: #3a3a3c; --text-muted: #68686c; --text-faint: #8e8e93; --bg-primary: #ffffff; --bg-secondary: #f5f5f7; --border: #d1d1d6; --border-light: #e3e3e6; --app-sheet-line: rgba(0, 0, 0, 0.1); --lit-ink: #0062cc; --lit-tint: #eaf4ff; --lit-line: rgba(10, 110, 224, 0.25); --accent: #0a6ee0; --accent-ink: #ffffff; } @media (min-width: 768px) { .dark[data-app-tone="light"] #platform-tabs { background-color: rgba(255, 255, 255, 0.50); /* :root's --dc-sheet-fill */ } .dark[data-app-tone="light"] #platform-tabs.platform-tabs-peek { background-color: #faf9f2; /* :root's --dc-sheet-solid */ } } /* Its app tiles take the light theme's face and ring, as the sheet's do (see "THE ICON TILE IS THE ONE SURFACE" above). */ .dark[data-app-tone="light"] :is(#platform-tabs, #platform-parked) .app-icon-tile { background-color: var(--bg-primary); border-color: var(--border-light); } /* AND WHAT OPENS OVER A DARK APP IS DARK TOO (#2803). This used to be the one thing the tone left alone: every sheet, dialog and menu kept the viewer's own mode, so Send feedback and the Homeroom menu opened as cream cards over a night-black app under a bar that had already gone dark. They follow the app now. lib/surface-tone.ts puts `.dark` on each kit shell (modal, sheet, panel, action sheet, popover, alert) and on the two in-tree sheets while `data-app-tone="dark"` holds under the light shell, marked with this class so it only removes its own. `.dark` is all the palette needs — the token blocks here and in native.css are plain `.dark { … }` and `dark:` utilities compile to `.dark .dark\:…` — so a toned surface is drawn exactly as it is under the dark shell. The one thing `.dark` on the surface cannot carry is the INK: the body's is `text-zinc-900 dark:text-zinc-100`, keyed on , and these shells inherit it from . So it is set here, the same literal the bar's tone uses. `:where()` keeps this at zero specificity: a kit rule that inks its own surface from a token still wins, and reads the dark token anyway. A light app under the dark shell is out of scope, as the request says: that direction would need `.dark` taken AWAY below a dark . */ :where(.platform-app-tone-dark) { color: #eaeaea; /* zinc-100, the body's dark ink */ color-scheme: dark; } /* THE CANVAS UNDER THE PUSH is the ground too — 's own background, set inline in the head (frontend/src/head.html) so the first paint is never white, moved from the old zinc greys to the wallpaper's base in each mode when the wallpaper became the platform's ground. It is what the page transition shows wherever its snapshots do not reach: the seam of the iOS push and a frame of the Android fade. Nothing route-scoped is needed for it any more; theme-color and the manifest carry the same value, so the browser chrome and a cold launch frame the page in it. The launch cover reads the same ground, so the app opens on the page's colour in both modes. */ body:has(:is(#home-screen, #app-view, #leaderboard-screen, #profile-screen, #browse-screen, #settings-screen, #messages-screen, #workshop-screen, #profile-proposals-screen, #agent-session-screen, #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen):not(.hidden)) .app-launch-cover { background-color: var(--home-ground); } /* THE LANDING ROOT PAINTS THE WALLPAPER ITSELF. #auth-landing-screen is a fixed, full-viewport overlay with its own opaque `bg-white` (it covers whatever the signed-in shell has left on the page), so the body's wallpaper never showed through it. It takes the same shorthand the body paints — inherited from the body's rule, which is on because this root is showing — in both modes. */ #auth-landing-screen, #auth-login-screen, #auth-register-screen, #auth-waiting-screen, #auth-waitlist-screen, #auth-more-screen { background: var(--home-wallpaper); } /* ── THE LANDING'S ACTIVITY RAIL LOOPS ───────────────────────────────── The signed-out landing draws four chips wider than a phone (frontend/src/features/auth/landing.tsx). The overflow is the point — it says more goes on here than fits — but a strip that only overflows reads as a row somebody forgot to finish. Looping it says the same thing on purpose. The track holds the four chips TWICE and travels exactly half its own width, so the second copy arrives where the first began and the seam never shows. Half is exact only because each chip carries its 8px as a right MARGIN rather than the row carrying `gap`: with `gap` the track is eight chips plus seven gaps, and half of that lands mid-gap and stutters once per cycle. The second copy is aria-hidden in the markup, so a reader hears the four lines once. 34s is a deliberate amble — about 25px a second. Fast enough to be clearly alive on a screen somebody looks at for a few seconds, slow enough not to pull the eye off the heading, which is the thing this screen is actually for. The transform runs on the compositor (translate3d, will-change) because this is the one thing animating on a screen that also decodes a 90KB illustration on first paint. */ .landing-rail-track { display: flex; width: max-content; will-change: transform; animation: landing-rail-loop 34s linear infinite; } @keyframes landing-rail-loop { from { transform: translate3d(0, 0, 0); } to { transform: translate3d(-50%, 0, 0); } } /* Decoration, so it STOPS rather than slows: a reader who asked for less motion still gets the whole row, still overflowing, simply still. */ @media (prefers-reduced-motion: reduce) { .landing-rail-track { animation: none; } } /* ── App cards ─────────────────────────────────────────── */ .app-card { transition: background-color 150ms; } /* A pointer that can actually hover only (#2892). On a touch screen WebKit emulates :hover from the last tap and keeps it until the next tap lands somewhere else — so a tile held for its menu kept this fill as a stuck "selected" look, most visibly after "Add to Homeroom widget", the one menu action that leaves you on the home screen with the tile still in view. */ @media (hover: hover) { .app-card:hover { background-color: var(--bg-card); } } /* The widget strip as a DROP TARGET (#2894): a "Your apps" tile dragged over it. home.js (_markWidgetDrop) sets `data-drop` for the span of the hover — an attribute because the strip's className is React's. `ok` is the same tint as the grid's own target cells (.home-grid-cell--on); `refused` (already pinned, or the widget is full) is a muted outline that says "not here" without shouting. */ #widget-strip[data-drop="ok"] { border-style: solid; border-color: rgba(31, 134, 255, 0.75); background-color: rgba(31, 134, 255, 0.14); } #widget-strip[data-drop="refused"] { border-color: rgb(161 161 170); opacity: 0.7; } /* THE TILE LABEL — iOS-homescreen sized (#951). 11px on a 13px line, TWO lines, ellipsised on overflow. #4934 tried one step up (12px on a 14px line) because over the wallpaper's washes the label read tiny — but on a phone's four columns the bigger type cut most names after a few letters (#5195), so it is back here. One pixel of type and one of line height is what a step up would cost: the two-line lane would be 2px taller, and the --home-cell-h derivation below would grow by the same 2px. The colour is inherited from the body's text-zinc-900 / dark:text-zinc-100, which clears 13:1 on the cream ground and its washes and 10:1 on the darkest dark wash (the ember); the label sets no colour of its own so the Create tile's muted ink still applies. Before #951 the label was one 14px/20px line with `truncate`, which cut most real app names after ~12 characters; at this size and two lines a tile shows roughly three times as much of a long name. The lane measures exactly two lines (26px, 2 x 13) as a MIN-height, not a fixed height: a one-line title and a two-line title still occupy the same box at the design size, so the caption below a tile — and the tile's whole content height — does not shift per tile, and the 124px budget in the --home-cell-h derivation is unchanged. But the box now GROWS when a device renders the font larger than the design size (#3661): Android's text scaling / font boosting inflates this label's font-size and line-height (~14px on ~17px lines) while rem-based lengths stay put, and the old fixed-height lane clipped that second line mid-glyph. With the floor the inflated text simply takes its two lines' worth of room — at most a few pixels into the row gap on such a device, never a cut-off word. The grid's rows themselves stay fixed; only the label's own box is content-sized beyond its floor. line-height is unitless (13px at the design size, 13/11) for the same reason: it tracks whatever font-size the device actually renders, so the two line boxes scale with the glyphs instead of staying 13px under them. -webkit-line-clamp is the only cross-browser way to ellipsise at a line COUNT (the standard `line-clamp` is listed alongside it for the engines that have shipped it unprefixed); it needs the -webkit-box display, which is why this is a class rather than Tailwind's `truncate`. overflow-wrap: anywhere keeps a single long unbroken word (a slug-style name) inside the tile instead of overflowing it. */ .app-card-title { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; overflow: hidden; width: 100%; min-height: 1.625rem; /* 26px — exactly two lines at the design size */ font-size: 0.6875rem; /* 11px */ line-height: 1.18; /* 13px at the design size; unitless so it tracks the font */ font-weight: 500; text-align: center; overflow-wrap: anywhere; word-break: break-word; } /* The status caption ("Spinning up…" / "Awaiting secrets" / "Error") steps down with it: 11px on a 12px line, no top margin, so the two text lanes together are 26 + 12 = 38px — the same as the old 20 (title) + 16 (caption) + 2 (mt-0.5) budget. */ .app-card-status { font-size: 0.6875rem; /* 11px */ line-height: 0.75rem; /* 12px */ } /* ── App icon tiles ──────────────────────────────────────── The single treatment for every homescreen-style app icon tile: home cards, the widget strip and the landing (unauthed) grid. A plain white face (an elevated zinc surface in dark mode) with a faint hairline tracing whatever rounded shape the call site picks (rounded-xl on the 56px tiles, rounded-lg on the 40px widget tiles) — the border is drawn by this class, the radius by the element's own Tailwind class, so the ring always follows the tile. The hairline uses a DIFFERENT token per mode. --border-light is inverted between the two palettes: in light mode it is fainter than --border (#e4e4e7 vs #d4d4d8), but in dark mode it is stronger (#484870 vs #2e2e50). Using it in both would make the tile ring the most contrasty border on a dark page, wrapped around every icon — so dark mode steps down to --border instead (see below). The token itself is left alone; 17 other rules depend on its current value. The glyph inherits `color` from here. Image icons still fill the tile: they're `w-full h-full object-cover` inside the border box, so the image sits flush inside the hairline. Tile call sites must NOT set their own background / text colour utilities — routing every tile through this one class is the point. */ .app-icon-tile { background-color: var(--bg-primary); border: 1px solid var(--border-light); color: var(--text-secondary); } /* THE PER-APP IDENTITY TINT IS GONE. The reskin hashed each app's slug into one of six pastels and painted the tile with it (`--tile-lime` and friends, `.app-icon-tile[data-tint="…"]`). A launcher of six unrelated pastels reads as six unrelated things rather than as one shelf, and an app's icon is its own artwork — the tile should hold it, not compete with it. One neutral face everywhere, which is what the rule above already draws. Nothing sets `data-tint` any more, so the `:not([data-tint])` guards that protected the two rules below from it are gone with it: the specificity trap they described — both selectors at (0,2,0), source order deciding — cannot recur without the attribute. */ /* The first-letter fallback specifically — one step fainter than the base glyph colour so a name initial reads as a quiet placeholder rather than as content. Tiles tag their kind with data-icon, so this never touches emoji tiles (whose colour glyphs ignore `color` anyway) or image tiles. Both modes step to the same faint token. */ .app-icon-tile[data-icon="letter"] { color: var(--text-faint); } /* An image tile's initial while its picture loads (AppIconContent's IconImage, polish board #11): the letter tile's own quiet placeholder, laid under the image, and gone once the image has drawn. The tile is its box at zero specificity, so a tile that already positions itself keeps doing so. */ :where(:has(> .app-icon-wait)) { position: relative; } .app-icon-wait { position: absolute; inset: 0; display: grid; place-items: center; color: var(--text-faint); font-weight: 700; line-height: 1; pointer-events: none; } .dark .app-icon-tile { /* --bg-primary is near-black in dark mode; one step up so the tile reads as a surface sitting on the page rather than a hole in it. */ background-color: var(--bg-secondary); /* …and back DOWN one step for the ring: --border-light is the brighter of the two hairline tokens in dark mode (see above), so the faint-hairline intent needs --border here. */ border-color: var(--border); } /* Drag-reorderable starred cards (issue #191): a long-press must pick the card up, not select its title text or pop the mobile copy/look-up callout. Static rather than toggled at drag start because selection begins during the ~350ms long-press window, before any JS drag state exists. Scoped to the drag-enabled class (added in home.js only when reordering is possible) so text everywhere else on the page selects normally. */ .app-card-draggable { user-select: none; -webkit-user-select: none; -webkit-touch-callout: none; -webkit-tap-highlight-color: transparent; } /* ── Home section headers ──────────────────────────────── */ .home-section-header { font-size: 0.75rem; color: var(--text-muted); padding: 0.25rem 0; } /* The home screen's content column: everything in the feed — the search bar, the "Your apps" grid, and the trailing Featured / Create sections — is capped at 1024px and centred in the viewport, so a wide desktop window reads as one column instead of a grid stretched edge to edge. The cap INCLUDES each block's own horizontal gutter (the px-3 / p-3 the children carry), which is why the search bar's padding lives on its inner .home-column rather than on the full-bleed bar: both columns then have identical content edges. Below 1024px this is a no-op and the gutters are the only horizontal padding, which is what a phone wants. Inside the column the trailing sections' boxes are FULL WIDTH — they used to be narrower and indented to line up with the leftmost app icon, a measured offset that existed only because the column itself was unbounded. Centring the column is the better answer, so don't re-introduce a per-box width bound. */ .home-column { width: 100%; max-width: 64rem; /* 1024px */ margin-left: auto; margin-right: auto; } /* ── Home-screen sections (#911) ──────────────────────────── Discover, Challenges and Create app: three bordered blocks stacked under the launcher grid, in that order, each a plain full-width child of its own
. THE UI OVERHAUL fixed them there. They were draggable ITEMS of #app-list before it — a `.home-panel-slot` host at a stored (column, row) cell, spanning real cells so app icons flowed around them the iOS-widget way — and everything below that answered to a rectangle: a two-cell height cap, a half-column width cap, a stretch-to-fill, and a phone branch that reshaped the content to fit ONE 116px cell. All of it is gone with the placement. A section is as tall as it draws and as wide as .home-column. HEIGHT — nothing survives the rectangle. The block used to carry --home-panel-max-h ("about two rows of app icons", 16rem, derived from --home-cell-h), enforced by flex — flex-none title bar and footer, a rows list with min-height: 0 and overflow: hidden — so content CLIPPED at the ceiling instead of growing the tile, with .home-panel--expanded lifting it. A section grows. What bounds the Challenges block is the MARKUP: HomePanels.challengesView draws a short pick (every First challenge, or at most three Next ones) and "See all" in its heading goes to the Challenges tab. THE LEADERBOARD FILL (.home-panel-fill) was a standings preview under the challenge rows, and it is REMOVED — two labelled lists with two different tap destinations inside one card called Challenges. The standings are a screen, and the section's heading carries the one tap to it. Its rules are gone from this file, and so is the heading's own "Open challenges" link (`.home-panel-lb-browse`), replaced by "See all" (`.home-panel-see-all`). NO WIDTH CAP any more. It was --home-panel-max-w, half of .home-column (512px of 1024px), and the argument for it was "a widget is not a section": a challenges row is one short line plus two small chips, and stretching it to 1024px left a lonely reward chip pinned to the far right. These ARE sections now — they are the screen's areas, stacked, each one the full width of the column above it — and a half-width Discover under a full-width app grid reads as a rendering fault, not as restraint. The lanes and rows inside them lay out against the width they are given. tests/home-panels-render.test.js pins the row budget and the tile tokens it was derived from, so a drift fails rather than silently mis-sizing the block. */ :root { /* ONE APP-GRID ROW. Every other height on the home screen is derived from it: the grid's own grid-auto-rows and the drag overlay's cells, which must line up with real tiles to the pixel. Desktop (>= 640px), from .app-card's own tokens in home.js renderAppCard: p-3 0.75rem x 2 = 1.5rem w-14 h-14 3.5rem = 3.5rem gap-1.5 0.375rem = 0.375rem title 2 x 13px = 1.625rem <- .app-card-title, two lines caption 12px line = 0.75rem <- .app-card-status, see below -------- 7.75rem (124px) #951 shrank the label from one 14px/20px line to two 11px/13px lines and tightened the icon->label gap and the caption line to match, so the total is UNCHANGED and nothing derived from --home-cell-h moved. Both text lanes are fixed heights, so a one-line and a two-line title produce identical tiles. #4934 grew the label to 12px on 14px lines; #5195 brought it back, because on a phone's four columns the bigger type cut most names after a few letters. The phone variant is 116px: index.html tightens the tile to `p-2` (0.5rem x 2), which is 8px less. Four 56px icons per row only read as a home screen at that density. THE CAPTION LANE IS NOT OPTIONAL. Most tiles are running apps and draw nothing there, so it looks like dead space — but the status dot is gone from the tile face, which makes "Spinning up…" / "Awaiting secrets" / "Error" the ONLY status signal a tile has. Rows are a FIXED height (the 8-row canvas and the drag overlay both depend on it), so a caption with no room doesn't push the row taller — it paints over the tile below. Budgeting for it is what keeps an errored app legible instead of bleeding into its neighbour. */ --home-cell-h: 7.75rem; /* 124px — see the derivation above */ /* ONE EMPTY ROW on a phone (#975). Half a cell — 58px against the phone's 116px — so a row the viewer left empty keeps its place in the arrangement without reserving a whole tile to be empty. DERIVED from the cell rather than written out, so the two can never drift. Emitted by Home.rowTemplate for the rows HomeLayout.blankRows names, and only at four columns; the :root value here (62px) is never used, since a desktop grid gets no inline template at all. A variable and not an inline calc() because every track in that template has to stay a single space-free token — see rowTemplate. */ --home-blank-row-h: calc(var(--home-cell-h) / 2); /* A CHALLENGE ROW IS TWO LINES NOW (56px, was 40). The METER LANE is gone with the third line of tokens that used to sit here (--home-panel-meter-lane / -bar-h / -bar-gap). That lane was a 14px strip reserved along the bottom of every row in a panel that had at least one numeric challenge, with the row's text padded clear of it — so the bar had somewhere to ride and every goal still sat on one baseline. It worked, and it cost two things nobody chose. Reserving the lane on EVERY row put all the text 7px above the row's true centre; and on a row with no bar to draw, the reserved strip was simply a hole, so a mixed list read as some rows aligned and some rows not. Both go away by giving the row a second LINE instead of a reserved strip: the goal, its count and its reward take line one, the track takes line two and runs the full width of the text column, and every challenge draws one — a yes-or-no challenge gets a two-state track (empty or full) rather than nothing. There is no shared baseline to protect because there is no row that lacks a bar, and the flex centring is over the whole row again. The track's own geometry is Tailwind utilities on the element (see panels/challenges.tsx) rather than derived rules here: it is an ordinary block in the row's second line now, so there is nothing left to derive. */ --home-panel-row-h: 3.5rem; /* 56px — see the budget above */ } /* NO HEIGHT CAP. `max-height: var(--home-panel-max-h)` lived here, and the whole apparatus below it — .home-panel-rows' overflow: hidden, the flex-none title bar and footer, .home-panel--expanded lifting the cap — existed to make a block CLIP inside the two-app-row rectangle it occupied on the launcher canvas. A section has no rectangle. What bounds the Challenges block now is the MARKUP: HomePanels.challengesView draws a short pick and "See all" goes to the Challenges tab, so there is nothing left for a second, invisible mechanism to bound. Keeping the cap after the fill stopped being leftover-sized would have clipped the standings preview the Challenges area now exists to show. */ .home-panel { display: flex; flex-direction: column; } /* THE TITLE BAR IS GONE (and it WAS the drag handle, #911). It carried `cursor: grab` and a "Drag to move this widget" tooltip while these blocks were grid items; THE UI OVERHAUL fixed them into sections and took the grip with it, leaving a `user-select: none` strip that held a title. The title is the section's own label above the card now and the block's controls went with it (frontend/src/features/home/panels/ui.tsx), so there is no bar left to style — a card opens on its content. The label row it became is `.home-area-label`, and it needs no rule here: it is utilities all the way down, and DELIBERATELY not `.home-section-header` above, which is the 12px caption the widget strip and the search-results heading use. */ .home-area-label button { cursor: pointer; } /* The rows list must be allowed to SHRINK below its content height — min-height: 0 is what makes overflow: hidden clip instead of the flex item refusing to compress and pushing the article past the cap. */ .home-panel-rows { flex: 1 1 auto; min-height: 0; overflow: hidden; } /* The challenges widget's BODY (#947): the rows list plus, on the desktop tile, the LEADERBOARD fill under it. It is the flex child that takes the article's remaining height and clips — the job .home-panel-rows used to do alone, moved out one level so the two stacked blocks inside it keep their natural heights. That is the whole reason this wrapper exists: with `flex: 1 1 auto` still on the rows list, the surplus would be absorbed BETWEEN the challenge rows and the leaderboard label, splitting the tile with a gap down its middle. Pinning both children to their content height collects the leftover at the BOTTOM of the tile, where it reads as ordinary padding. Scoped to the challenges panel; discover and create keep their markup, and the existing descendant selectors (`.home-panel .home-panel-rows--metered .home-panel-row`, asserted in dapp.json) still match through it. */ .home-panel-body { display: flex; flex-direction: column; flex: 1 1 auto; min-height: 0; overflow: hidden; } .home-panel-body > .home-panel-rows { flex: 0 0 auto; } /* `.home-panel-footer::before`, the rule above the footer, is gone. The Challenges block was the only one with a footer, and it sits on the page ground now with no divider anywhere in it (the ITERATION 03 board's Home screen): the 14px step between items is what separates them. */ /* Uniform height is what makes the 4-slot budget above exact. Each row is TWO LINES — goal/count/reward, then the track — and both are fixed, so a row with a long goal and a row with a short one occupy the same box. STRICTLY ONE LINE PER LINE. `nowrap` here is the belt to the per-element `whitespace-nowrap` braces in panels/challenges.tsx: a fixed-height row HIDES a wrap (the extra line just overflows the box and gets clipped by the panel), so relying on the goal's `truncate` alone and on flex to keep the chips honest is how a three-line row ships unnoticed. Declaring it on the row means every present and future child inherits it, and `overflow: hidden` clips rather than letting a chip spill over the neighbouring row. The whole row is the tap target into the Challenges screen and it spans the column, so its hit AREA is far past what the 44px minimum-dimension guideline protects — that rule is about small icon controls, and the one of those here (the ⋮ menu) keeps .un-touch-target. */ .home-panel-row { position: relative; height: var(--home-panel-row-h); white-space: nowrap; overflow: hidden; } /* A hairline between two stacked rows, FLUSH with the column. No markup draws two today: the only `.home-panel-row` is the Challenges block's between-seasons line, and it is alone, so this rule does not fire. It used to start 0.625rem in, matching that line's `px-2.5` inside the retired plate's rounded corners; the block is a flat column on the page ground now and its text starts at the heading's edge, so a rule starts there too. A pseudo-element rather than a border because the row is a fixed-height box whose height budget (--home-panel-row-h) is spent exactly: a 1px border is part of the border box and would make every row after the first a pixel shorter than the first, which is the whole reason the 4-slot budget above is stated in whole rows. */ .home-panel-row + .home-panel-row::before { content: ''; position: absolute; top: 0; left: 0; right: 0; height: 1px; background: var(--border-light); pointer-events: none; } /* `.home-panel-rows--metered` and the `.home-panel-bar-track` geometry rule are gone with the lane, and the track and fill names went with the count capsule that inherited them: a Home challenge card draws the Challenges tab's shared progress rail now (features/leaderboard/challenge-card.tsx), and the declared checks select on its `[role=progressbar]`. */ /* The season progress's own hairline (`.home-panel-season::after`) is gone with the plate it divided. `.home-panel-season` stays in the markup as the hook the declared checks select on, and needs no rule: the block is one flat column now and the progress is just its first band. */ /* The footer bar (`.home-panel-footer`, the "See all N challenges" / "Show less" toggle) and `.home-panel--expanded .home-panel-rows`, which stopped the rows list clipping while the block was expanded in place, are gone with the toggle: the block shows a short pick and "See all" in its heading goes to the Challenges tab (the Semi design, 2026-10-16). */ /* `.home-panel-slot` — the in-grid drag host — is gone with the placement. It spanned real cells so app icons flowed around a widget the iOS way, and it carried a width cap, a stretch-to-fill and a phone release from that stretch. THE UI OVERHAUL made the three blocks fixed
s, so there is no rectangle to fill and nothing to drag. */ /* ── The launcher grid ────────────────────────────────────── Free-form placement: every child is positioned at an explicit (column, row) by an inline `grid-column` / `grid-row` from Home.renderGridItem. Rows are a FIXED height so eight of them are a deterministic canvas and so the drag overlay's cells line up with real tiles to the pixel — `auto` rows would size to content and the overlay would drift the moment one tile had a status line and another didn't. position: relative anchors that overlay (below). The SEARCH view is exempt: it is a flat, transient list, and its "N results" header and empty-state line would each claim a whole tile row under a fixed height. Home.render() stamps data-view on the grid. ON A PHONE THIS IS THE DEFAULT ROW HEIGHT, NOT EVERY ROW'S (#968, #975). Home.render() writes an inline `grid-template-rows` below 640px — one entry per occupied row, `var(--home-cell-h)` for most of them plus two exceptions: * a content-sized `minmax(floor, auto)` for a row a FIT widget owns outright (HomeLayout.fitRows; challenges only today). Without it the between-seasons widget drew a ~68px box inside a 116px reservation and handed the other ~48px to nobody: a grid item cannot shrink a fixed track, so shrinking the BOX was never going to shrink the PAGE. * `var(--home-blank-row-h)` — half a cell — for a row with NOTHING in it (HomeLayout.blankRows). Same reasoning one step further: an empty row was spending a whole tile's height on nothing, and on the default phone arrangement there are two of them between the app tiles and the lower widgets. Note what shrinking a blank row is NOT: nothing re-packs, nothing collapses, nothing is tidied away. The row keeps its index, keeps its place in the arrangement and stays a drop target — a hole is still an arrangement the viewer chose. Only its pixel height changes, and only on a phone. Two things the rule deliberately does not do: it never shrinks a row holding an app tile (a card with no status caption is ~100px, and that lane is load-bearing — see --home-cell-h), which is also why a PARTLY empty row stays full; and it never emits more entries than there are occupied rows (an explicit grid exists whether or not anything is in it, so eight entries would pad a three-app home screen out to ~950px — which is likewise why the trailing empty rows below the last tile are not in the template and have nothing to shrink). Desktop gets no template at all and this token is still the whole story there. */ #app-list { position: relative; grid-auto-rows: var(--home-cell-h); } /* HOLD THE LAUNCHER'S SPACE UNTIL THE GRID HAS RENDERED ONCE. The document the service worker serves is the PRERENDER, and the prerender's #app-list is empty — so a cached load paints the header, five area labels and the account row stacked at the top of the page, and everything below the grid then slides down by two rows the moment the bundle hydrates and the skeleton appears. That is the largest single jump between the cached paint and the loaded one, and it is pure CSS to remove: reserve the two-row default (HomeLayout.DEFAULT_ROWS) that the grid is about to draw anyway. Keyed on `data-view`, which app-grid.tsx sets on its first READY render and the prerender therefore lacks — so this applies for exactly the parse-to- hydrate window and never to a loaded grid, including the empty one a brand new account has (which would otherwise be padded with two blank rows). */ #app-list:not([data-view]) { /* Two cells PLUS the gap between them and the grid's own padding (app-grid.tsx: `gap-1.5 p-2 pt-1.5`, from 640px `gap-2 p-3 pt-2`). The box is border-box, so two bare cells came up 20px short of the two rows they stand for (28px from 640px), and the sections under the grid moved by that much when it drew (#10). */ min-height: calc(2 * var(--home-cell-h) + 1.25rem); } @media (min-width: 640px) { #app-list:not([data-view]) { min-height: calc(2 * var(--home-cell-h) + 1.75rem); } } /* …AND HOLD EVERY AREA AT THE HEIGHT THIS DEVICE LAST DREW IT (#10, 19 Oct 2026). Two rows was the right guess for the grid alone, but the real launcher draws as many rows as the screen has room for, plus "Show all N apps", and Discover and Challenges below it land at heights no skeleton can know: the desktop measured one shift of 0.0585 on every cold load (Discover 54 → 121px, Challenges pushed from y 392 to 523). The head's inline script puts the heights this device last drew on (`first-paint-reserved` and the `--reserve-*` properties; frontend/src/lib/first-paint-reserve.ts keeps them), and each area holds its height only while it is still a skeleton: the grid until its first ready render (`data-view`, as above), a section while `.home-section-pending` (features/home/panels/sections.tsx). The real page then lands in boxes of its own size. `overflow: hidden` clips a skeleton taller than its box; nothing real is ever inside one. The sidebar's community rows have the same hold, beside their own rules. */ html.first-paint-reserved #home-apps-section:has(#app-list:not([data-view])) { height: var(--reserve-home-apps); overflow: hidden; } html.first-paint-reserved #home-discover-section.home-section-pending { height: var(--reserve-home-discover); overflow: hidden; } html.first-paint-reserved #home-challenges-section.home-section-pending { height: var(--reserve-home-challenges); overflow: hidden; } #app-list[data-view="search"] { grid-auto-rows: auto; } /* ── The drag-time grid overlay ───────────────────────────── While something is lifted, the grid it snaps to is drawn underneath it — every cell of the canvas outlined, including the empty ones, so "you can drop this anywhere" is visible rather than something to discover. It is a real GRID sharing #app-list's own gap and row height (the column template is set inline, since the column count is a JS-side decision), and it is inset by the grid's own padding. That is what makes it align with zero arithmetic: it is laid out by the same engine, with the same numbers, as the tiles it sits behind. The row height below is the DEFAULT and the padding for rows past the content (#968, #975). Since a phone row can now be shorter than a cell — content-sized for a fit widget, half a cell for an empty row — Home._showGridOverlay copies #app-list's USED tracks (getComputedStyle → "116px 67.5px 58px …") onto this element inline and pads them out to the eight-row canvas with this token. The padded rows stay a FULL cell on purpose: they are past the template, so they are the drag-only region below the content, where there is no page height to reclaim and a big drop target is worth more. Copied rather than re-derived on purpose: one element decides the row heights and the other reads its answer, so the two grids cannot disagree. In pixels, too — the cells here are empty divs, so a content-sized track would collapse to nothing. The inset must track that padding EXACTLY, including the tighter top — #app-list is `p-2 pt-1.5 sm:p-3 sm:pt-2`, so a uniform inset sits the whole overlay 2px (phone) / 4px (desktop) low. That is not just a cosmetic drift in the tint: Home._rectForCell measures these cells to find where a committed drop lands, so any offset here becomes a jump at the end of the release glide, exactly where the motion is supposed to be seamless. It doubles as the drag's HIT-TEST surface (Home._cellFromPoint), which is why the layer disables pointer events but the cells re-enable them: a hit must land on a cell, not on a tile behind it. The kit's ghost is pointer-events:none, so it never occludes them either. */ .home-grid-overlay { position: absolute; /* #app-list's p-2 pt-1.5 on a phone */ inset: 0.375rem 0.5rem 0.5rem; display: grid; gap: 0.375rem; /* gap-1.5, matching the phone grid */ grid-auto-rows: var(--home-cell-h); pointer-events: none; z-index: 0; } .home-grid-cell { position: relative; pointer-events: auto; border: 1px dashed var(--border-light); border-radius: 0.75rem; /* rounded-xl, same as a tile */ transition: background-color 120ms, border-color 120ms; } /* The cell's HIT AREA bleeds into the surrounding gap. The overlay is a real grid, so the gap between cells belongs to no cell — and a pointer resting there would resolve to nothing, dropping the highlight and making a release over a gap spring the item back. A pseudo-element hit-tests as its originating cell, so half the gap in each direction closes the seams with no arithmetic. Adjacent areas overlap by a pixel or two; elementFromPoint takes the later cell in DOM order, which is deterministic. */ .home-grid-cell::before { content: ''; position: absolute; inset: -4px; } /* The cells the drop would land in. A widget tints its whole footprint, so "this doesn't fit here" is legible before releasing; an ILLEGAL cell is left plain rather than tinted red — the absence of the affordance is the clearer signal, and it matches the ghost springing back. */ .home-grid-cell--on { background-color: rgba(31, 134, 255, 0.14); border-color: rgba(31, 134, 255, 0.75); border-style: solid; } @media (prefers-reduced-motion: reduce) { .home-grid-cell { transition: none; } } /* ── The live displacement preview ────────────────────────── While something hovers a target, the items it WOULD push move to the cells they'd land in. The flow reorder this replaced gave that away for free (everything shuffled as you dragged); free placement has to show it deliberately, because only the items that actually collide move at all — without it a drop onto an occupied cell is a guess. The transform is set inline from the plan (a measured delta between two of the overlay's own cells); this rule only supplies the MOTION, so it matches the kit's FLIP family — 200ms ease, the same as attachReorder's gridFlip. z-index keeps a sliding tile above its stationary neighbours instead of disappearing behind the one it is passing. */ .home-item-displaced { transition: transform 200ms ease; z-index: 2; } /* Pushed clean off the canvas into the dense overflow rows below it. There is no overlay cell to slide to, so the tile says so where it stands: dimmed, with a downward chevron. Better than sliding it to a position that does not exist yet, and better than moving it silently. */ .home-item-to-overflow { position: relative; opacity: 0.45; } .home-item-to-overflow::after { content: '↓'; position: absolute; right: 0.25rem; bottom: 0.25rem; width: 1.125rem; height: 1.125rem; display: flex; align-items: center; justify-content: center; border-radius: 9999px; font-size: 0.75rem; line-height: 1; color: #fff; background-color: rgba(31, 134, 255, 0.9); } @media (prefers-reduced-motion: reduce) { /* The new POSITION is the information, so the tiles still move — only the tween goes. */ .home-item-displaced { transition: none; } } /* Tiles sit ABOVE the overlay. Without this the overlay's cells would paint over the icons they are supposed to sit behind. */ #app-list > .app-card { position: relative; z-index: 1; } /* ...but they must be TRANSPARENT TO HIT-TESTING for the duration of a drag. This is load-bearing, not a polish detail. The overlay's cells are what Home._cellFromPoint resolves a pointer to, and they sit BELOW the tiles (they have to — a dashed outline painted over an app icon would be nonsense). So while the tiles keep their pointer events, elementFromPoint under the finger returns a TILE for every occupied cell, cellFromPoint returns null, and the drop is treated as "not over the grid": • dropping onto another app did nothing at all — the target was never even resolvable, so displacement could not be reached; • and a tile could not be moved to any position overlapping its OWN footprint, because its own drop slot swallowed the hit-test. The kit puts .un-reordering on the list for exactly the span of a lift, so scoping it there means normal taps are untouched. */ #app-list.un-reordering > .app-card { pointer-events: none; } /* ── THE TILE GRID IS RETIRED ─────────────────────────────── `.home-discover-tiles` was six explicit grid tracks (`--lane-tracks`, set from the lane's own count and floored at four), `.home-discover-icon-wrap` capped the fluid icon at the 40px the tile always drew at, `.home-discover- icon` held it square, `.home-discover-tiles .home-discover-tile` stripped the launcher card's padding back off, and `.home-discover-name` clamped the label to two lines because a ~55px track rendered most names as "Opinio…". Every one of those existed to fit six icons into ONE grid cell on a phone. The lane is a rail of cards (see `.home-discover-rail` below) and the block is a section that grows to its content, so none of that arithmetic has anything left to constrain. What survives is the lane wrapper and the empty note. The NAME keeps its class and loses its clamp: on a 152px card a real name has room to be read on one line, and the second line would only ever be spent on the longest few. Truncation is a utility on the element now. */ .home-discover-lane { flex: 1 1 auto; } /* `.home-discover-divider` is RETIRED. It drew the hairline row that carried the "Popular" caption between the block's two rails. Discover is one category and one rail now — the curated apps and the most-used ones flow as a single continuous set of cards — so there is no sub-group left to label and no seam left to draw. */ /* The empty state: no rail at all, one centred line in its place, so the block reads as a compact strip rather than a mostly-blank box. */ /* #1913: a card now, in the rail's card language (the tint vars come from the `.home-tint-*` class on the element) — so the empty lane still reads as a lane with something in it, and the whole plate is the link on to the directory. */ .home-discover-empty { display: flex; padding: 0.875rem 1rem; border-radius: 0.875rem; background: var(--tint-bg); border: 1px solid var(--tint-line); text-decoration: none; } .home-discover-empty:hover { filter: brightness(0.98); } .home-discover-empty:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; } /* ── THE CARD LANGUAGE: TINTS ─────────────────────────────── Discover's app cards and Challenges' challenge cards are the same object in two sizes — a tinted plate with art on it — and they share one palette so the launcher reads as one page rather than two lists that happened to get colours. Five tints, assigned by a hash of the app slug / challenge id (see tintOf in panels/ui.tsx) rather than by position, so a card keeps its colour as the lane reorders around it. Raw hex, like the wallpaper above and for the same reason: these are the design's own tints, not steps of a Tailwind scale, and `zinc`/`violet` are the only scales the product is allowed to name (see the palette rule in tests/admin-ui-registry.test.js). `--tint-art` is the deeper block the icon sits on; `--tint-line` is the hairline that keeps a pale card off a pale wallpaper. Dark mode does what the wallpaper does: the same hues, re-tuned to a lightness that reads on the inverted ground rather than inverted into mud. */ .home-tint-1, .home-tint-1[data-preview-theme="light"], .dark .home-tint-1[data-preview-theme="light"] { --tint-bg: #e3efe0; --tint-line: #cfe0ca; --tint-art: #cfe3c7; } .home-tint-2, .home-tint-2[data-preview-theme="light"], .dark .home-tint-2[data-preview-theme="light"] { --tint-bg: #dfeaf6; --tint-line: #c9dcee; --tint-art: #c6dcf0; } .home-tint-3, .home-tint-3[data-preview-theme="light"], .dark .home-tint-3[data-preview-theme="light"] { --tint-bg: #e9e2f2; --tint-line: #d9cfe8; --tint-art: #ded2ef; } .home-tint-4, .home-tint-4[data-preview-theme="light"], .dark .home-tint-4[data-preview-theme="light"] { --tint-bg: #fbe6d5; --tint-line: #f2d5bd; --tint-art: #f7ddc6; } .home-tint-5, .home-tint-5[data-preview-theme="light"], .dark .home-tint-5[data-preview-theme="light"] { --tint-bg: #f8dde8; --tint-line: #eec7d6; --tint-art: #f4d6de; } .dark .home-tint-1, .home-tint-1[data-preview-theme="dark"], .dark .home-tint-1[data-preview-theme="dark"] { --tint-bg: #1b2a1f; --tint-line: #2c4433; --tint-art: #22331f; } .dark .home-tint-2, .home-tint-2[data-preview-theme="dark"], .dark .home-tint-2[data-preview-theme="dark"] { --tint-bg: #17263a; --tint-line: #27405e; --tint-art: #1b2f47; } .dark .home-tint-3, .home-tint-3[data-preview-theme="dark"], .dark .home-tint-3[data-preview-theme="dark"] { --tint-bg: #241f38; --tint-line: #3a3157; --tint-art: #2b2442; } .dark .home-tint-4, .home-tint-4[data-preview-theme="dark"], .dark .home-tint-4[data-preview-theme="dark"] { --tint-bg: #33231a; --tint-line: #50392a; --tint-art: #3d2a1f; } .dark .home-tint-5, .home-tint-5[data-preview-theme="dark"], .dark .home-tint-5[data-preview-theme="dark"] { --tint-bg: #331d28; --tint-line: #513043; --tint-art: #3e2231; } /* Harmonic palette: select tone 50 once. Dark surfaces are computed from that same token, blended into the shell's zinc-950 ground. The fixed 10%, 14%, 24% proportions give every hue the same quiet surface hierarchy. These formulas also drive explicit editor previews; no second palette. */ .home-tone-cream { --tone-50: #fefdf5; --tone-light-line: #f5f0d0; } .home-tone-yellow { --tone-50: #fff9de; --tone-light-line: #f0d85c; } .home-tone-orange { --tone-50: #fff0e0; --tone-light-line: #e8a878; } .home-tone-coral { --tone-50: #fde8e4; --tone-light-line: #e09488; } .home-tone-pink { --tone-50: #f8e4ee; --tone-light-line: #d48eb4; } .home-tone-purple { --tone-50: #ede4f4; --tone-light-line: #aa92c2; } .home-tone-indigo { --tone-50: #e4e8f6; --tone-light-line: #8896c8; } .home-tone-blue { --tone-50: #deedf8; --tone-light-line: #6aadd4; } .home-tone-teal { --tone-50: #deeeed; --tone-light-line: #72bab2; } .home-tone-mint { --tone-50: #e2f2e8; --tone-light-line: #88c49e; } .home-tone-sage { --tone-50: #eaf2e4; --tone-light-line: #a9cf97; } .home-tone-gray { --tone-50: #f4f3f1; --tone-light-line: #b8b4ac; } :is(.home-tone-cream, .home-tone-yellow, .home-tone-orange, .home-tone-coral, .home-tone-pink, .home-tone-purple, .home-tone-indigo, .home-tone-blue, .home-tone-teal, .home-tone-mint, .home-tone-sage, .home-tone-gray) { --tone-dark-bg: color-mix(in srgb, var(--tone-50) 10%, #0b0b0c); --tone-dark-art: color-mix(in srgb, var(--tone-50) 14%, #0b0b0c); --tone-dark-line: color-mix(in srgb, var(--tone-50) 24%, #0b0b0c); --tint-bg: var(--tone-50); --tint-line: var(--tone-light-line); --tint-art: var(--tone-50); } .dark :is(.home-tone-cream, .home-tone-yellow, .home-tone-orange, .home-tone-coral, .home-tone-pink, .home-tone-purple, .home-tone-indigo, .home-tone-blue, .home-tone-teal, .home-tone-mint, .home-tone-sage, .home-tone-gray), :is(.home-tone-cream, .home-tone-yellow, .home-tone-orange, .home-tone-coral, .home-tone-pink, .home-tone-purple, .home-tone-indigo, .home-tone-blue, .home-tone-teal, .home-tone-mint, .home-tone-sage, .home-tone-gray)[data-preview-theme="dark"] { --tint-bg: var(--tone-dark-bg); --tint-line: var(--tone-dark-line); --tint-art: var(--tone-dark-art); } .dark :is(.home-tone-cream, .home-tone-yellow, .home-tone-orange, .home-tone-coral, .home-tone-pink, .home-tone-purple, .home-tone-indigo, .home-tone-blue, .home-tone-teal, .home-tone-mint, .home-tone-sage, .home-tone-gray)[data-preview-theme="light"], :is(.home-tone-cream, .home-tone-yellow, .home-tone-orange, .home-tone-coral, .home-tone-pink, .home-tone-purple, .home-tone-indigo, .home-tone-blue, .home-tone-teal, .home-tone-mint, .home-tone-sage, .home-tone-gray)[data-preview-theme="light"] { --tint-bg: var(--tone-50); --tint-line: var(--tone-light-line); --tint-art: var(--tone-50); } /* ── Discover: the card rail ──────────────────────────────── The lane was a GRID of six 40px icon tiles inside the block's white card: the most an area called Discover could say about an app was its name, clamped to two lines at 9.6px. It is a horizontal rail of cards now — art, name, the app's own sentence, and how many people built it — which is what the design asks for and what makes the area answer "should I open this?" IT BLEEDS TO BOTH SCREEN EDGES. The negative margin cancels the section's px-3 gutter so the first card starts on the text's left edge and the last one runs off the right, which is the affordance: a card cut by the edge says there are more. #home-screen states `overflow-x: hidden` (see the gesture rule above, pinned by tests/home-vertical-scroll-only.test.js), so the overhang is clipped by the feed rather than widening it. BOTH AXES, AND THE SECOND ONE IS NOT OPTIONAL (#1762). This rule said `touch-action: pan-x` for the same reason the switcher's app rail carries it — without it a diagonal drag that starts here can be claimed by the vertical feed and the rail never moves — under a comment claiming that "a VERTICAL drag still reaches the page, the browser only takes the axis this element declares". That claim is simply false, and it cost the whole screen: `touch-action` is not a preference about which axis this element would like, it is the complete set of gestures the browser may run for a touch that STARTS here, intersected down the ancestor chain. `pan-x` therefore DENIES vertical panning; it does not hand it to the feed. Two rails of ~13rem cards bleeding to both screen edges is most of the Discover block, so on a phone that was a band you could not scroll the page from at all — put a finger on a card, drag up, and nothing moved, not even the rubber band. (`.un-sheet:has(#notifications-sheet)` a thousand lines up has to opt vertical panning back IN for its scroller for exactly this reason, and states the rule correctly.) `pan-x pan-y` is what `html, body` already declares, so this is the page's own value rather than a new one: both axes are legal for a touch starting here and the browser's axis lock picks the one the drag is going in — a mostly-horizontal drag scrolls the rail, a mostly-vertical one scrolls the feed. What that costs is the narrow case the `pan-x` was written for: a genuinely diagonal drag that is slightly more vertical now scrolls the feed instead of the rail. That is the trade every horizontal rail on the web makes, and it is the right side of it — failing to scroll the rail costs one retry, failing to scroll the page costs the screen. It also has to stay `pan-y` for the drag-to-add gesture (#1763): the kit arms a lift on a long press with a movement slop, so a scroll that starts here cancels the press rather than competing with it — but only if the scroll is allowed to start. */ .home-discover-rail { display: flex; gap: 0.625rem; overflow-x: auto; overflow-y: hidden; scroll-snap-type: x proximity; -webkit-overflow-scrolling: touch; touch-action: pan-x pan-y; scrollbar-width: none; margin-inline: -0.75rem; padding-inline: 0.75rem; /* The snap position must be the KEYLINE, not the rail's own edge. Without it `scroll-snap-align: start` lines the first card up with the scrollport edge — 0.75rem outside the section's gutter, since the negative margin above cancelled it — and WebKit applies that snap on layout, so on iOS the rail arrived pre-scrolled with the first card stuck to the screen. */ scroll-padding-inline: 0.75rem; /* Room for the cards' own shadow-less hairline to not be clipped, and for a focus ring on the last card. */ padding-block: 0.125rem; } .home-discover-rail::-webkit-scrollbar { display: none; } /* ── THE RAIL STOPS AT THE CONTENT'S EDGE, AND FADES THERE (#2718 review) ── On a phone the rail BLEEDS: `margin-inline: -0.75rem` with the padding added back lets a card scroll flush to the screen edge, which is the whole affordance — the row visibly continues past the frame. On a desktop the frame is not the screen. The page has a rail on its left and a gutter mirrored on its right (see --platform-gutter), and a lane that bleeds 12px past that gutter puts its cards 12px closer to the window edge than every other thing on the page — which reads as the lane being misaligned rather than as it continuing. So the bleed is cancelled and a MASK says the same thing instead: the last 2rem of the scrollport fades to transparent, so a row with more in it trails off rather than being cut. The mask is static rather than driven by scroll position — a lane shorter than the port fades empty space, which is invisible, and the alternative is a scroll-timeline this shell cannot rely on in every browser it ships to. */ @media (min-width: 768px) { .home-discover-rail { margin-inline: 0; padding-inline: 0; scroll-padding-inline: 0; -webkit-mask-image: linear-gradient(to right, #000 calc(100% - 2rem), transparent); mask-image: linear-gradient(to right, #000 calc(100% - 2rem), transparent); } } /* 9.5rem is the reference's card at a 390pt phone (150/390 of the frame), and it is a fixed width on purpose: cards that flex would resize as the lane's count changes, and the rail's whole affordance is that the row continues past the edge at a constant rhythm. */ .home-discover-card { flex: 0 0 auto; width: 9.5rem; scroll-snap-align: start; border-radius: 0.875rem; background: var(--tint-bg); border: 1px solid var(--tint-line); overflow: hidden; cursor: pointer; } /* `cover`, not `contain`: the framing editor's zoom bottoms out at the exact cover fit and its pan is clamped to it, so the art fills the block at every legal framing rather than letterboxing itself against the tint. */ .home-discover-illustration { width: 100%; height: 100%; object-fit: cover; pointer-events: none; } .home-discover-art { overflow: hidden; height: 7.5rem; background: var(--tint-art); display: flex; align-items: center; justify-content: center; } /* The app's own icon, at the size the art block can carry. An emoji is a glyph and scales with font-size; an uploaded image fills the block, which is the one case that looks like the reference's own art. */ .home-discover-art-emoji { font-size: 2.75rem; line-height: 1; } .home-discover-art-img { width: 100%; height: 100%; object-fit: cover; } .home-discover-art-letter { font-size: 2.25rem; line-height: 1; font-weight: 700; opacity: .45; } /* Two lines, ellipsised — the reference's own treatment. `line-clamp` is three properties and one of them is prefixed, which is why it is here rather than as utilities beside the element. */ .home-discover-blurb { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; overflow: hidden; } /* The same two lines for the NAME (#4937): the single `truncate` it carried cut long community names mid-word on a card wide enough to read them. `overflow-wrap: anywhere` keeps a name with no spaces in it from overflowing the card instead of wrapping. */ .home-discover-name { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; overflow: hidden; overflow-wrap: anywhere; } /* ── Challenges: a flat column of cards ───────────────────── The block was one white card of divided rows, then a translucent PLATE (`.home-challenges-plate`) holding the season summary and the cards. Both are gone. The ITERATION 03 board's Home screen draws the area straight on the page ground: season summary, group headers, cards and footer in one column, 14px apart, aligned with the section heading and with no border or rule anywhere. The cards and the group headers are surfaces of their own, so the plate was a second frame around them, and its padding pulled the block in from the heading's edge. The spacing is utilities in frontend/src/features/home/panels/challenges.tsx; nothing here draws it. The cards carry no rules of their own. Each is the Challenges tab's shared card (features/leaderboard/challenge-card.tsx), drawn entirely in utilities; `.home-challenge-card` survives only as the root class the declared checks and tests select on. The tinted card, the white pill, the count capsule and the category well that lived here are retired with the design they drew. */ /* ── The Create tile: the launcher grid's last cell ───────────── "Create an app" is the grid's trailing tile (the prototype's scrHome), drawn entirely in utilities in frontend/src/features/home/create-tile.tsx: an app card's cell with a dashed, unfilled face and a muted label. It replaced the full-width Create section that sat below Challenges, and the `.home-create-widget` wrapper went with that section. Here are only the three things a utility cannot say, and each mirrors a rule the app cards already carry (the `#app-list > .app-card` rules): the tile sits ABOVE the drag overlay, at the top of its row, and it is transparent to hit-testing for the span of a lift. That last one is load-bearing for the same reason it is on the cards — the overlay cell under the tile has to stay a drop target, and a drop there is an ordinary drop into an empty cell (the tile is not in the layout; the next paint moves it along). It also fades while a drag is live: it is the one thing on the canvas that does not move with the preview, and at full strength it read as a tile being displaced. */ #app-list > .home-create-tile { position: relative; z-index: 1; align-self: start; } #app-list.un-reordering > .home-create-tile { pointer-events: none; opacity: 0.4; } /* Keyboard focus draws the ring the challenge cards draw (`.home-challenge-card[role="button"]:focus-visible`). */ .home-create-btn:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; } /* ── EDIT MODE (#4669): the wiggle ─────────────────────────── A held tile puts My apps into edit mode, and the tiles gently wiggle the way a phone's home screen does. The animation is on the ICON WRAPPER (the card's `.relative` child), not on the card itself: the kit's drag writes `transform` to the CARD element for the lift, displacement preview and release spring, and an animation transform on the same element would fight it. The wrapper is React's alone. `alternate` swings the one keyframe pair between -1.5deg and 1.5deg, and the per-row delays (2n / 3n) spread the phase so the grid reads as a jelly of tiles rather than one rigid tile repeated. */ @keyframes home-wiggle { from { transform: rotate(-1.5deg); } to { transform: rotate(1.5deg); } } #app-list[data-editing] > .app-card > .relative { animation: home-wiggle 260ms ease-in-out infinite alternate; } #app-list[data-editing] > .app-card:nth-child(2n) > .relative { animation-delay: -130ms; } #app-list[data-editing] > .app-card:nth-child(3n) > .relative { animation-delay: -65ms; } /* While a drag is live the kit puts .un-reordering on the list; the wiggle pauses so the dragged tile's wrapper is not also turning under the finger. */ #app-list.un-reordering[data-editing] > .app-card > .relative { animation-play-state: paused; } @media (prefers-reduced-motion: reduce) { /* The arrangement affordances stay — the remove buttons, "Done" and the Add apps tile are markup, not motion — only the wiggle goes. */ #app-list[data-editing] > .app-card > .relative { animation: none; } } /* ── Phone density ────────────────────────────────────────── Below 640px the grid is 4 columns with a tighter tile, so the cell is 8px shorter (p-2 instead of p-3) and the gap is 6px instead of 8, and the overlay's inset/gap follows from that — kept here, in one block, so the two can't drift. 640px IS the breakpoint: it is Tailwind's `sm` on #app-list's `grid-cols-4 sm:grid-cols-5`, and HomeLayout.BREAKPOINT_PX in frontend/src/features/home/home-layout.js. All three must agree or the JS lays out against a column count the CSS isn't rendering. */ @media (max-width: 639.98px) { :root { /* 116px — p-2 (16) + icon 56 + gap-1.5 (6) + title 26 + caption 12 */ --home-cell-h: 7.25rem; /* --home-panel-max-h was redefined here as ONE CELL (#968), because a block was a grid item whose phone footprint was a single row and a 238px cap in a 116px cell would have let an oversized system text size paint the article over the app tiles below it. The blocks are fixed sections outside the grid now — they overlap nothing and they size to their own content — so neither the override nor the token it narrowed exists any more. */ } .home-grid-overlay { gap: 0.375rem; } /* The doubled class is deliberate. This rule is what makes the phone cell 116px rather than 124px, but the card element carries Tailwind's own `p-3`, and tailwind.css is linked AFTER app.css in index.html — so at equal specificity the utility won and this tightening never applied (the cell budget above said p-2 while tiles rendered at p-3, which is how a captioned tile came to overflow its row). `.app-card.app-card` is the same element, one specificity step up, so the intended phone padding lands without an !important or a #app-list scope that would miss the landing grid's tiles. It also buys the label 8px of extra line width, which at 11px is roughly two more characters per line. NOT the Discover card. It carries `.app-card` only as the wiring contract with `_wireDiscoveryCards`; it is a tile of its own whose art block is meant to run edge to edge, and this padding inset the illustration inside a frame of tint on every phone. */ .app-card.app-card:not(.home-discover-card) { padding: 0.5rem; } /* `.home-panel-slot > .home-panel--fit { align-self: flex-start }` lived here: the phone-only release from the slot's stretch-to-fill, so a short block ended sooner instead of spending its cell on whitespace. Both the slot and the stretch went with the placement — a section is as tall as it draws, everywhere, with no rule needed to say so. */ } @media (min-width: 640px) { .home-grid-overlay { /* #app-list's sm:p-3 sm:pt-2 */ inset: 0.5rem 0.75rem 0.75rem; gap: 0.5rem; /* sm:gap-2 */ } /* THE MY APPS BLOCK'S WIDTH (#4861): the area spans the full column again. #4738 had capped it at 48rem and centred it, so a few apps grouped closer — but on review of that softening the narrower block read as odder than wide spacing: the grid sat inside a box narrower than the search bar above it and the sections below (evan, on #4861), so the cap is gone and everything on Home lines up at the same edges again. Tile padding and gaps are untouched, so the overlay's inset below still mirrors #app-list, and the cap being on no box at all means the absolutely positioned drag overlay (inside #app-list) and Home's cell measurements still line up with zero arithmetic. Search keeps the full width it always had. */ } /* App tiles sit at the TOP of their row rather than stretching to fill it. Rows are a fixed --home-cell-h whenever tiles alone define them, so this changes nothing on its own. It earned its keep in the rows a multi-cell WIDGET spanned, where an expanded block made the row taller than a card and a stretched tile grew a pool of dead space under its title; nothing spans rows since THE UI OVERHAUL. It stays because the blank rows Home.rowTemplate emits (#975) are half a cell, and a tile stretched to a short track is the same wrong default in the other direction. */ #app-list > .app-card { align-self: start; } /* The feed body is a full-height flex COLUMN so the trailing sections can be bottom-anchored on a tall screen. min-height:100% (of the #home-screen scroller) does double duty: - it guarantees the scroller can always be scrolled by at least the hidden search bar's height, even with an empty "Your apps" — a short page would otherwise leave the bar permanently on screen (the search bar sits ABOVE this box inside the same scroller, so total content is always barHeight + 100%, and Home._searchReveal parks the scroller at barHeight); - it makes this box exactly as tall as the visible feed at that resting scroll position, which is what makes "anchored to the bottom of the box" read as "anchored to the bottom of the page". Height stays AUTO (min-height is only a floor), so nothing shrinks and nothing clips once the content is taller than the viewport. The safe-area padding keeps a bottom-anchored section off an iPhone's home indicator; box-sizing:border-box means it eats into the 100% rather than adding scroll. */ .home-body-fill { display: flex; flex-direction: column; min-height: 100%; /* #home-screen is the one screen root with no `.platform-safe-scroll`, so it reserves the tab bar's band here instead — same `max()`, same reason (see that utility near the top of this file). It matters more here than anywhere else: the trailing sections are BOTTOM-ANCHORED to this box, so under-reserving does not merely crop the last card, it parks Create and Challenges permanently behind the bar. */ padding-bottom: max(var(--platform-tabs-h, 0px), var(--platform-safe-bottom)); /* 4px, so the first label (its own `pt-4`) clears the header's notch by the 12px Workshop, Messages and Profile leave: the bar overlaps this box by 8. It sits on #home-body, not the search bar, because the bar parks by its own offsetHeight (home.js), and a taller bar would park the gap away with it. */ padding-top: 4px; } html[data-browser-scroller="home-screen"] .home-body-fill { /* The header overlaps its content by .5rem (its rounded lower edge). */ min-height: calc(100dvh - var(--browser-banner-h) - var(--platform-header-h) - var(--platform-safe-top) + .5rem); } /* THE PARKED SEARCH BAR IS TRANSPARENT (QA 2026-09-24 Q30c). Parking the scroller at the bar's height does not take the bar off the screen on a phone: the platform header is translucent (rgba(255,255,255,.5) over a blur) and overlays the top of the scroller, so the parked bar sat right under it and "Search your apps…" read through the Homeroom logo on every load. Home._searchReveal already stamps whether the bar is showing (data-revealed, half the bar or more); the bar simply fades with it. A focused bar is never transparent, whatever its scroll position, so a keyboard focus can never leave the caret in an invisible field (the focus handler in home.js also scrolls it out, see _searchReveal.reveal). */ #home-search-bar { transition: opacity 150ms ease; } #home-search-bar[data-revealed="false"]:not(:focus-within) { opacity: 0; } /* NOTE: .home-bottom-anchor is gone with the two trailing sections it existed for ("Featured apps" and "Create an app", which pushed to the bottom of a short feed). Both are widgets in the grid now, so there is nothing below the grid left to anchor. .home-body-fill above stays — its min-height is what keeps the hidden search bar pullable on a short page, which was always a separate job. */ /* ── Browse screen rows / boxes ───────────────────────────── The #apps screen renders ONE row markup (icon · name+meta · Add button) and lets CSS pick the layout: a hairline-divided vertical list on a phone, bordered app boxes in a 2/3-column grid on a wide screen — the Apple App Store shape at both sizes. Only the GRID is Tailwind (responsive classes on #browse-list); every border lives here, which is deliberate and load-bearing: Tailwind's `divide-y` compiles to .divide-y > :not([hidden]) ~ :not([hidden]) { border-top-width: 1px; border-bottom-width: 0 } and `md:divide-y-0` zeroes BOTH widths on the same selector. That selector is (0,3,0) and beats a bare `.browse-row` (0,1,0), so mixing the two mechanisms stripped the top AND bottom border from every box except the first child — which is exactly the bug this replaced. The hairline is therefore a sibling rule here, in the same cascade as the box, and #browse-list carries no divide-* utilities at all. Written as one min-width query matching Tailwind's `md` (768px) — keep the two in step if the container's breakpoint ever moves. */ .browse-row { /* One hairline token per theme so the rules below never need a `.dark` variant (which would out-specify the sibling/hover rules). */ --browse-border: var(--border-light); transition: background-color 150ms, border-color 150ms; } .dark .browse-row { --browse-border: var(--border); } /* Neutral, not --bg-card: that token is an accent TINT, so a plain hover read as a selected/highlighted row once the accent turned blue. */ .browse-row:hover { background-color: var(--bg-secondary); } /* #1617: on phones, the name gets the whole width above metadata + Add. One DOM tree keeps the explicit add/remove action and row navigation intact. Desktop boxes and all other ListRow users retain their existing layout. */ @media (max-width: 639px) { .browse-row.browse-row { display: grid; grid-template-columns: 2.75rem minmax(0, 1fr) auto; column-gap: 1rem; row-gap: 0.25rem; } .browse-row > .app-icon-tile { grid-column: 1; grid-row: 1 / 3; } .browse-row .browse-row-content { display: contents; } .browse-row .browse-row-title { grid-column: 2 / 4; grid-row: 1; white-space: normal; } .browse-row .browse-row-name { white-space: normal; overflow-wrap: anywhere; } .browse-row .browse-row-meta { grid-column: 2; grid-row: 2; min-width: 0; } .browse-row > .browse-add-btn { grid-column: 3; grid-row: 2; min-height: 44px; } .browse-row .browse-row-title > span { align-items: baseline; } } /* QA 2026-09-24 Q10: from 640px up the name keeps its row beside the icon and the Add pill, and it used to be one `truncate`d line there, which cut "Staging demo Puzzle Chain" to "Staging de…" in a desktop box. It may take TWO lines now before it ellipsises. The phone rule above already lets it wrap freely on its own full-width row; this is the clamped version of the same idea for the boxes. */ @media (min-width: 640px) { .browse-row .browse-row-title { white-space: normal; } .browse-row .browse-row-title > span { align-items: baseline; } .browse-row .browse-row-name { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; line-clamp: 2; white-space: normal; overflow-wrap: anywhere; } } /* Phone: a single hairline BETWEEN consecutive rows, INSET to the text column. The rows sit in one white card now (#browse-list carries the card classes below md), so a rule running the card's full width would reach its corner radius — the same reason the home panels' hairlines are inset, and the same 4.75rem depth @/components/ui/grouped-list.tsx uses for a row with a leading tile (px-4 1rem + tile 2.75rem + gap-4 1rem). A pseudo-element rather than `border-top` so the md+ box below can own the `border` shorthand outright: .browse-row is a ListRow, which is already `relative`. */ .browse-row + .browse-row::before { content: ''; position: absolute; top: 0; left: 4.75rem; right: 0; height: 1px; background: var(--browse-border); pointer-events: none; } /* md+: every row is its own complete box. The sibling selector is listed alongside so this wins over the phone rule at equal specificity rather than relying on source order alone. */ @media (min-width: 768px) { /* Each row is its own box here, so the between-rows hairline has nothing to separate — it would draw across the top of every box but the first. */ .browse-row + .browse-row::before { content: none; } .browse-row, .browse-row + .browse-row { /* The widget language separates by figure/ground, so the box is a white surface on the grey page rather than a hairline outline. The border stays declared and transparent so the hover rule below has a width to colour in without the box changing size under the cursor. */ border: 1px solid transparent; background-color: var(--bg-primary); border-radius: 1rem; } .browse-row:hover, .browse-row + .browse-row:hover { border-color: var(--accent-light); } } /* ── The phone directory: controls on the ground, the list in a card ──── SINCE THE COMMUNITIES PROTOTYPE the search, the filter chips and Sort sit on the ground above the card rather than as its head: the card holds what it lists, and the controls over it read as the control rows over Home's and the Communities screen's cards do. What follows is #1919's reasoning for the one-pane shape it replaces; the parts, the page-scoped classes and the empty-note rule still hold, and the split ring does not (the body and the note are whole cards now). #1919: below md the search bar, the Sort control and the list they narrow wear the Workshop's working pane (`.dev-ws-pane`, further down): one frosted sheet (`--dc-sheet-fill` over `--dc-frost`), a 22px radius and a hairline ring, with the head pinned at the top and the rows sliding under its frost. Before this the bar was a wallpaper-coloured strip and the list a plain white rounded-2xl card below it, which is the pre-pane shape every other recent screen has moved off. PAGE-SCOPED CLASSES, deliberately not the Workshop's own. The two panes are the same treatment today and should be allowed to move separately; sharing `.dev-ws-pane-*` would also drag the Workshop's sticky offset and its stage-board width rules onto a screen that has neither. NO WRAPPER, so no single element to ring. The head (#browse-search-bar) and the body (#browse-list) are siblings under #browse-screen — the head sticks against the SCREEN's scroller, and wrapping both in a pane would put a new ancestor between the head and the thing it sticks in. So the ring is a `border` split across the two parts (the head keeps no bottom edge, the body no top edge) rather than the Workshop's inset box-shadow, which cannot leave one side out. Same margins on both parts is what makes the two half-rings meet as one. The parts paint the SAME fill over the SAME backdrop, for the reason the Workshop's note gives: a fill on a wrapper plus a fill on the sticky head stacks 50% on 50% and draws a lighter band across the controls. THE NOTE IS THE BODY WHEN THE LIST IS EMPTY. A search that matches nothing leaves #browse-list with no children and #browse-empty with the sentence; the empty list collapses (`:empty`) and the note takes the body's bottom half of the ring instead, so the pane still closes. And while neither is drawn — the directory is still loading, or the load failed and the error card is the body's only child — the head closes itself (`:has`, the same way the shell's body rules already read screen state). Written as one max-width query matching the md breakpoint's lower edge (767px), the mirror of the min-width query above — keep the two in step if the container's breakpoint ever moves. */ @media (max-width: 767px) { /* The controls on the ground (the prototype's Discover): no sheet, no ring, no fill, and NOT PINNED on a phone. A pinned head has to hide the rows sliding under it, which takes a fill, and a fill is a band across the wallpaper's washes and star that no flat colour matches (the header fakes its glass for the same reason; a fixed layer inside this scroller is not safe to fake, since the screen transitions transform it). So on a phone the controls scroll away with the list, as a search over a store list does. md+ keeps its pinned bar as it was. */ #browse-screen .browse-pane-head { position: static; margin: 0; /* 20px at the top: 8 under the header's notch, 12 of air (12 left the search field 4px under the bar). */ padding: 20px 12px 10px; background: transparent; } #browse-screen .browse-pane-body, #browse-screen .browse-pane-note { background-color: var(--dc-sheet-fill); backdrop-filter: var(--dc-frost); -webkit-backdrop-filter: var(--dc-frost); border: 1px solid var(--app-sheet-line); margin: 0 12px 12px; border-radius: 22px; /* The rows' hover fill and the hairlines would otherwise poke out of the corners. Nothing in the body positions itself outside it (the "+" menu the Workshop pane keeps `overflow: visible` for has no counterpart here). */ overflow: hidden; } #browse-screen .browse-pane-body:empty { display: none; } #browse-screen .browse-pane-note { padding: 12px 14px 16px; } } /* Where there is no backdrop-filter the fill is all there is, and 50% white with rows sliding crisply under the pinned head is the rendering fault the frost prevents. All three parts go opaque together, because they must stay the same colour as each other above all. */ /* SOLID ON A PHONE, ALL THREE TOGETHER, on every platform. The list scrolls under the pinned head, so with no blur the head has to be opaque, and the three parts are one pane, so they stay one colour (see --dc-sheet-solid). md+ is untouched: there the bar wears the wallpaper's own ground. */ @media (max-width: 767px) { #browse-screen .browse-pane-body, #browse-screen .browse-pane-note { background-color: var(--dc-sheet-solid); } } /* ── App-card "…" actions menu ───────────────────────────── Popover built by Home.openCardMenu (appended to , fixed- positioned against the trigger rect). Plain CSS rather than Tailwind utilities so the dynamically-inserted panel doesn't depend on the CDN JIT having generated classes at scan time. */ /* The "…" menu's container and item rows are kit-owned now (unNative.popover's .un-popover / .un-popover-item, #741) — only the build-info header content below stays app-styled; it rides inside the kit popover as a headerEl. */ /* Build-info header (Home.renderMenuHeaderHtml): full untruncated app name + slug + the deployed-commit pill that used to sit on the card face. max-width bounds long names — they wrap, never truncate. */ .card-menu-header { max-width: 18rem; padding: 0.5rem 0.875rem 0.55rem; margin-bottom: 0.25rem; border-bottom: 1px solid var(--border-light); } .card-menu-title { font-size: 0.875rem; font-weight: 600; color: var(--text-primary); overflow-wrap: anywhere; } .card-menu-slug { font-size: 0.7rem; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; color: var(--text-muted); overflow-wrap: anywhere; } .card-menu-version { margin-top: 0.375rem; font-size: 0.75rem; color: var(--text-muted); } .card-menu-updated { margin-top: 0.25rem; font-size: 0.7rem; color: var(--text-muted); } /* The app's full pill set inside the menu header — the card face carries no chips at all, so this is the one place they render. */ .card-menu-pills { margin-top: 0.375rem; display: flex; flex-wrap: wrap; gap: 0.375rem; } /* ── Status dots ───────────────────────────────────────── */ .status-dot { width: 8px; height: 8px; border-radius: 50%; display: inline-block; } .status-dot.running { background-color: #22c55e; } .status-dot.creating { background-color: #eab308; animation: pulse 1.5s ease-in-out infinite; } .status-dot.error { background-color: #ef4444; } @keyframes pulse { 0%, 100% { opacity: 1; } 50% { opacity: 0.4; } } /* ── App iframe ────────────────────────────────────────── */ #app-content { position: relative; } /* Surface-dependent bottom safe area (#970, extended). #app-view used to carry the kit's `un-safe-bottom` unconditionally, so its padding was subtracted from the flex height of EVERY surface inside #app-content — the running app included. On a phone that left the app ~34px short of the screen's rounded bottom edge, with the body background showing through the gap, while the shell itself painted edge-to-edge. #970 gated that padding on the PLATFORM surface. NEITHER SURFACE CARRIES PADDING ANY MORE. Gating it was only half the fix: on a platform surface the padding still sat on the OUTER box, so every Dev-mode surface was shrunk by the inset and the strip below it was dead background — the dev-chat composer floated above an empty band and the chat lost that height. The inset moved INWARD to the innermost thing that needs it (each scroller's content padding, each composer bar's own padding, via .platform-safe-scroll / .platform-safe-bar above), so Dev mode now paints edge-to-edge like the app surface does and only its content is held clear. What these two rules do is publish the TOKEN, so the surface contract stays stated where it is read and tested: - platform: restate the real inset (identical to :root — explicit here because this is the boundary the contract is about); - app: ZERO it, so no shared class can ever reserve the strip over an app frame. The frame keeps reaching the true bottom edge and the insets are forwarded INTO the app instead (AppView.broadcastSafeArea → the bridge's --un-safe-inset-*), which is what lets an app inset its own bottom chrome rather than being clipped by ours. No `!important` needed: nothing competes with either rule. */ #app-view[data-app-surface="platform"] { --platform-safe-bottom: var(--un-safe-inset-bottom, env(safe-area-inset-bottom, 0px)); } #app-view[data-app-surface="app"] { --platform-safe-bottom: 0px; } #app-iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; border: 0; background: var(--bg-primary); } /* THE "STILL OPEN" DOT (#2902), on an app kept loaded — its tile on Home, its App row in the sidebar (features/app-frame/live-apps.tsx). QUIET GREY since the 19 Oct polish board (N17): it was green, and the shell shows a coloured status dot only when something is wrong (AGENTS.md, "let zero say nothing"), never a green one on every running app. An app kept open is a convenience, not news; the dot stays because the sidebar's close control (#5525) sits where it is. Ringed in the page ground so it stays a dot on any icon behind it. */ .app-live-dot { display: block; width: 10px; height: 10px; flex: none; border-radius: 999px; background: var(--text-muted); box-shadow: 0 0 0 2px var(--bg-primary); } /* On a launcher tile: the icon's top-right corner, where the fork tag's bottom-left one leaves room. */ .app-card-live-dot { position: absolute; top: -2px; right: -2px; } /* ── APPS KEPT ALIVE BEHIND THE ONE ON SCREEN (#2902) ────────────────── The last few apps you opened stay loaded, each in its own frame beside #app-iframe (features/app-frame/app-frame.tsx), so resuming one shows it exactly as you left it. A kept frame keeps #app-iframe's box — the same absolute inset — so the app inside never sees a resize while it waits, and is hidden by `visibility`, not `display`: nothing paints and nothing can be hit, but its layout (and so its scroll position) is untouched. `inert` and `aria-hidden` on the element take it out of the keyboard and screen-reader order; this only takes it off the screen. */ .app-launch-host > iframe[data-kept] { position: absolute; top: 0; left: 0; width: 100%; height: 100%; border: 0; visibility: hidden; pointer-events: none; } /* ── THE APP SHEET, and why the corner lives HERE (#1571) ────────────── The running app arrives as a raised sheet on the page ground: its own top radius, its own hairline, its own shadow. That is a different mechanism from the one every OTHER route uses, and the split is not an inconsistency — it is the only arrangement that works on both. #platform-header carries `rounded-b-2xl -mb-2`: a notch cut out of THE BAR, overlapping downward so whatever sits below reads as rounded-topped. It costs the screens below it nothing, which is what makes it right for them — every screen root is TRANSPARENT (the body paints the ground, the roots are `flex-1 overflow-y-auto` and nothing else), so there is no fill on them to round in the first place. That notch needs a bar surface to cut, and on an app route there isn't one: the rule at "THE BAR OVER THE WALLPAPER" above clears #platform-header's background wherever the wallpaper shows, and #app-view is on that list. So inside an app the notch produced nothing at all, while the one opaque thing on the screen — the app's own document, behind #app-iframe's `background: var(--bg-primary)` — met the cream in a hard horizontal line corner to corner. That line is what #1571 reported ("cuts out on apps … a gray horizontal line not matching the background of the app"), and no radius on the bar can reach it. So the app frame rounds ITSELF. #app-frame-host is the right element and not #app-view: it is React-owned end to end (see features/app-frame/app-frame.tsx), it is shown only while an app is actually mounted, and it is already `overflow: hidden`, so the radius clips the frame with nothing further to arrange. Its sibling #app-content — Dev mode, the status placeholders — keeps the header's notch like every other platform surface, because like them it is transparent and has nothing to round. The shadow reaches UP into the bar's strip on purpose, which is what makes the sheet read as lifted rather than abutted. Nothing clips it: #app-view sets no overflow, and the bar's own `z-10` paints it above the shadow without hiding it, because on this route the bar has no background to hide anything with. Geometry is the design's (Streamlined Concept, node 736:4306): a 28px top radius, a 1px hairline and a two-layer shadow. THE HAIRLINE IS `border-top` ONLY, and that is the whole of it. The sheet is as wide as the screen and runs off the bottom, so a border on any other side is not an edge of anything — it draws a 1px rule down the left and right of the display for the entire height of the app, which reads as a letterboxed frame around it rather than as a card. Only the top edge is a real boundary here, because it is the only side where the sheet actually meets the page ground. */ #app-frame-host { border-radius: 1.75rem 1.75rem 0 0; border-top: 1px solid var(--app-sheet-line); box-shadow: 0 6px 12px -6px var(--app-sheet-shadow-near), 0 8px 24px -4px var(--app-sheet-shadow-far); /* KEPT ON A LAYER, or the corners flicker while the app opens — see "WHY BOTH PROMOTIONS" below for what this costs and why the frame needs one of its own too. */ will-change: transform; } /* THE CLIP, STATED AT EVERY LEVEL, because one level is not enough here. #app-frame-host's own `overflow: hidden` (an inline style, see features/app-frame/app-frame.tsx) is the whole fix in Chrome and Firefox for content that stays on its parent's layer. Two things in this subtree do not: - #app-iframe. WebKit has a long-standing bug where an