What's That: the Level 1 Yes button is still visually dominant — block width and accent colour, not font size

[WilfordGrimley]

Live-production verification pass, driven against deployed commit 425fab94 (merge of PR #737, "layout pass reclaiming desktop/mobile space") on https://proxyprints.ca/whatsthat, in both Chromium and Firefox at 390px/800px/1600px viewports. No browser-engine divergence was found on any claim below — Chromium and Firefox behaved pixel-identically.

Symptom. At Level 1, the "Yes — that's the one" button still reads as visually dominant over its "Not sure" / "No, different printing" siblings, despite #737 shipping a real fix.

What #737 actually fixed. PR #737 dropped the .big modifier from the Level 1 Yes button. That part genuinely shipped: computed font-size is 15px and padding is 6px 16px in live production — identical to its siblings — confirmed in both Chromium and Firefox. Source: frontend/src/features/questionFeed/QuestionFeed.tsx:1364 — the button's className is "primary block" (no .big). The base Btn style (QuestionFeed.tsx:378-397) sets font-size: 15px; padding: 6px 16px; for every button; the .big modifier (QuestionFeed.tsx:399-403, font-size: 17px; font-weight: 800; padding: 10px 20px;) is not applied here.

What's still live. Two properties #737 never touched keep the button visually dominant:

1. Full-width block class. The button retains .block (QuestionFeed.tsx:1364, CSS at QuestionFeed.tsx:405-407: width: 100%). Its "Not sure"/"No, different printing" siblings (QuestionFeed.tsx:1376, 1384, both className="secondary", no .block) do not have this. Measured live: 494px wide vs 243px for "Not sure" at an 800px viewport, and 1190px wide at a 1600px viewport.
2. Sole coloured control in the row. The button is the only button in the answer row carrying a colour token distinct from the neutral "secondary"/"ghost" styling. Correction to the wording used to scope this pass: the colour comes from the .primary class (QuestionFeed.tsx:1364, CSS at QuestionFeed.tsx:409-413: background: var(--primary)), not from a class literally named .accent. A separate .accent class does exist in this same file (QuestionFeed.tsx:421-426) but is not applied to this button. Token values, confirmed at the audited sha in frontend/src/pages/whatsthat.tsx:47-48: --primary: var(--bs-primary, #ff9e64) (orange) vs --accent: var(--theme-accent, #bb9af7) (purple/lavender) — two genuinely different tokens. The Yes button is orange via --primary; nothing in the row uses --accent. "Not sure"/"No, different printing" use .secondary (QuestionFeed.tsx:415-419: background: var(--raised), neutral), so the Yes button is still the only coloured control in the row — that substantive claim holds, just under the .primary/--primary name rather than .accent.

Root-cause note. The original report (#711) was written in terms of the mechanism — "drop the oversized modifier" (i.e. .big) — rather than the outcome (the button reading as dominant). A correct, literal implementation of that request (removing .big) left the symptom in place because .big was never the only thing driving the button's dominance.

What done looks like. The Yes button should read as one option among peers in the answer row, with its priority expressed by position (it's listed first) rather than by size or by being the sole coloured control. Whether it keeps .block, keeps the .primary colour, or keeps neither is an open design decision — options, not a prescription:

• Drop .block, keep .primary colour — button sized to content, colour still marks it as the primary action.
• Drop .primary colour, keep .block — full-width for a larger tap target, but visually matched to its siblings.
• Drop both — the button becomes indistinguishable from "Not sure"/"No, different printing" except by position and label.
• Keep both, but reduce all three buttons' visual weight together, so the differential (not the absolute size) shrinks.

Cross-reference: #711 (original report), #737 (the PR that shipped the .big removal).

Audited sha: 425fab94 (origin/master at time of this pass).