What's That: reference card should stay visible while scrolling at every viewport; snip page uses vertical space poorly

[WilfordGrimley]

Part of #704.

Reported symptom

Owner: "we aren't using the available space on each page effectively either. I think the ref card should always be visible as a user scrolls at every page resolution."

Code evidence

No sticky positioning anywhere in the file. A search of QuestionFeed.tsx for "sticky" returns zero matches. The subject/reference card (SubjectCardBox, QuestionFeed.tsx:197-207) sits inside Subject (QuestionFeed.tsx:178-190), an ordinary flex child of WtcHero (QuestionFeed.tsx:167-176, display:flex, flex-wrap:wrap) alongside QPanel (QuestionFeed.tsx:192-195, the questions column) - both are normal-flow siblings with no position:sticky, position:fixed, or scroll-anchoring of any kind.

cardPanel.tsx's own header comment confirms this was a deliberate, recent removal: "CardPanel/StaticCardPanel's old 767.98px max-width-derived-from-vh height cap (the portrait static top block hack) is retired (WD4 - the page is an ordinary scrolling document now)" (cardPanel.tsx:25-27), and CardPanel/StaticCardPanel themselves (cardPanel.tsx:130-142) now carry only position:relative, z-index:0, width:100% - no sticky/fixed positioning was reintroduced to replace the retired height-cap hack.

No viewport-tier awareness either. frontend/src/features/display/useViewportTier.ts provides four-tier viewport detection (phone/tablet/laptop/desktop) via matchMedia listeners (lines 12-38), and is imported by frontend/src/features/display/DisplayPage.tsx and frontend/src/features/gridSelector/SelectVersionResults.tsx. QuestionFeed.tsx imports neither useViewportTier nor any position:sticky rule - its only responsive mechanism is a single CSS container query, @container hero (max-width: 560px) on WtcHero (container-type: inline-size, line 168), which reflows Subject from a side column into a horizontal strip below that width, but never changes how it scrolls.

Net effect: at every viewport, once QPanel's question content (candidate grid, chips, action buttons) grows taller than the visible viewport, the page scrolls as one ordinary document and the reference card scrolls out of view along with everything else - there is no code path that keeps it on screen.

Confirmed / Refuted / Inconclusive

Confirmed. No sticky/fixed positioning exists for the subject card at any viewport, and the page was explicitly converted to "an ordinary scrolling document" in a prior pass with no replacement pinning mechanism added.

Scope

This is the largest item in the layout track and the organizing thesis for it, per the owner's framing. A fix would add position:sticky (with a top offset, likely coordinated with WtcHead) to Subject or SubjectCardBox at wider containers, and needs a specific decision for narrow/single-column layouts (where Subject and QPanel stack vertically via the container query) since sticky-while-stacked has different UX implications than sticky-beside-a-column. Likely needs useViewportTier or an equivalent container-query-based check to decide when sticky behavior applies vs. when the existing @container hero reflow takes over. Touches WtcHero, Subject, and potentially WtcHead's own height budget.

Layout-pass coupling

This is the organizing thesis for the entire layout track - the other five layout items (hover-zoom clipping, chip collapse, title overlay, MTGAC applet size, Yes button size) are each individually small, but all six compete for the same constrained vertical space this item is about reclaiming. The reference-image-title-overlay and MTGAC-applet-size items are the most directly coupled (both change SubjectCard's or its neighboring credit block's height budget), so should be sequenced first within the same repass, with this item's sticky mechanism added last once the space it needs to keep visible has been reduced by the others.

---

Owner decisions (2026-08-05 review)

Scope expansion — horizontal, not just vertical. Owner: "not just vertical but horizontal. on desktop we have more of that and on mobile we have vertical." This item is no longer a vertical-space-only fix: it is a full responsive-space pass. Desktop has surplus HORIZONTAL space the page currently fails to use (WtcHero's flex-wrap lets Subject/QPanel sit side-by-side, but neither column is shown claiming the extra width a wide viewport offers beyond their flex-basis). Mobile has surplus VERTICAL space per the original symptom (the reference card scrolls out of view with no pinning). Both are instances of the same underlying complaint: the page isn't using the space each viewport actually has.

Build-once-scale-nicely standard, located and quoted. The standard the owner referenced is the container-first layout policy for this exact surface:

• docs/proposals/mockups/wtc-rebuild/SPEC-wtc-rebuild.md:185-190 — "Policy (owner-ratified 2026-07-24, WTC = first consumer): components style against their CONTAINER (@container), not the viewport; snip the layout folds continuously (flex-wrap + clamp() + auto-fill/minmax); snip viewport breakpoints are reserved for STRUCTURAL reordering only. The three retired horizontal-scrollers (MobileButtonRow, MobileCandidateScroller, MobileChipRow) and HeroGrid's 768px grid-template-areas swap are the anti-pattern being deleted."
• docs/proposals/mockups/wtc-rebuild/SPEC-wtc-rebuild.md:198-206 — the continuous fold-point table: intrinsic flex-wrap, clamp()-driven sizing, and auto-fill/auto-fit grids fold "6→4→3→2 cols continuously," explicitly "no viewport sizing."
• docs/features/printing-tags.md:764 — "no viewport breakpoint drives sizing (container-first policy, WTC = first consumer)."
• QuestionFeed.tsx:23-26 (this file's own header) restates it: "one @container-driven hero... that folds continuously via flex-wrap + clamp() + auto-fill/auto-fit grids - no viewport breakpoint drives ANY sizing."

This is "build once and scale nicely" in concrete form: one intrinsic (container-query-driven) layout tree that continuously reflows across every viewport, rather than viewport-specific breakpoint variants. The reference-card-visibility fix and the new horizontal-space fix should both be implemented as intrinsic/container-driven behavior consistent with this policy, not as a new viewport breakpoint bolted on top of it.

Reiterated hard requirement. The reference card must remain visible while scrolling at EVERY viewport — phone, tablet, laptop, and desktop alike, not just "mobile" or "narrow."

useViewportTier.ts gap noted. frontend/src/features/display/useViewportTier.ts (four-tier matchMedia hook) is imported by frontend/src/features/display/DisplayPage.tsx and frontend/src/features/gridSelector/SelectVersionResults.tsx, but is NOT imported by QuestionFeed.tsx — confirmed by direct search (zero matches). Any sticky/space-reclaiming mechanism built for this issue should decide explicitly whether it needs useViewportTier (or an equivalent container-query-based check) or can stay purely container-driven per the policy above — see this file's existing "Scope" section, which already flagged this same question.

[WilfordGrimley]

Owner Decision — 2026-08-05

Reconciliation: Container-first policy reaffirmed as binding. Reference image should stay visible while scrolling at every viewport, achieved via pinning WITHIN the container (WD4 amendment), not viewport-sticky positioning.

The prior statement "should stay visible while scrolling at every viewport" combined with the absence of any sticky mechanism left an open question: how? Owner decision: the reference card is pinned within its own @container hero ancestor via position: sticky applied to SubjectCardBox or Subject — not the page viewport.

This satisfies the persistent-visibility requirement while keeping the container-first policy intact. Viewport-sticky was and remains rejected because it couples component layout to page-level scroll state, violating the container-first principle; snip container-pinning achieves the same UX goal without that coupling.

See amendment A2 in PR #718 for the full reconciliation recorded in the spec.

The issue's existing citation of the container-first policy as the implementation method is correct and should be preserved.

[WilfordGrimley]

Verification pass against live production (deployed commit 425fab94, the merge of #737): the container-scoped position: sticky; snip top: 16px this issue asked for shipped and is live and correct.

It demonstrably works at Level 2 — clamps at ~y=66px and holds through scrolling, confirmed byte-identically in Chromium and Firefox. It does NOT visibly engage at Level 1: the hero container has only ~12px of scroll slack there (Subject box ~387px vs hero ~400px), so the card scrolls off almost 1:1 with the page instead of pinning. The sticky mechanism itself isn't broken — Level 1's content shape just doesn't give it room to work. Full source-verified writeup with options: #744.