/* ========================================================================== T39 — Popular search terms (/search/term/popular/) SCOPED ON `.hrv-page-t39`, A DECLARED CLASS, AND THE NATIVE `search-term-popular` IS ASSERTED SEPARATELY RATHER THAN USED AS THE HOOK. Both classes are really on — MEASURED on the live page with the render rig before a line of this file was written, not reasoned by analogy from `catalogsearch-advanced-index`. Two plausible guesses (`catalogsearch-term-popular`, `search-term-popular-index`) are both wrong, and a reskin scoped to a GUESSED body class is 100% dead CSS that passes every static review — this theme has already lost a stylesheet that way (T14). `hrv-page-t39` is declared by this theme's handle; wheat-T39.json asserts BOTH, so a failure names which hook broke instead of sending every geometry row red at once. THE ROUTE IS `/search/term/popular/`, NOT `/catalogsearch/term/popular/`. The controller lives in module-search (frontName `search`), not module-catalog-search. The natural guess returns 404 — indistinguishable from a handle that never merged. Measured with a known-200 and a known-404 control, plus the without-`X-Forwarded-Proto` case in which every route on this store answers 302. THIS IS A RESKIN OF CORE MARKUP, AND NO TEMPLATE IS FORKED. `Magento_Search::term.phtml` already does the thing that looks bespoke in the artboard: it sizes each term by popularity, emitting `font-size: (ratio*70+75)%` per `li#term-` through `renderStyleAsTag`. Everything below is therefore either UNDOING a default or declaring a look — never reproducing behaviour core already has. The breadcrumb row the comp draws is added from layout via `addCrumb` against core's own site-wide `breadcrumbs` block. COMPONENTS THAT ALREADY OWN ELEMENTS ON THIS PAGE — enumerated with the grep the playbook mandates, before a line was written, because on T15 six of eight elements were already owned and skipping this produced a duplicated card shell and an AA-failing #fff: .breadcrumbs `components/_breadcrumbs.css` owns the whole trail — 12px, muted, flex `.items`, "/" separator, current crumb in `--hrv-text`. THIS FILE DECLARES NOTHING ABOUT IT. The comp draws "›"; the component's docblock records the slash as a deliberate theme-wide decision, and a page task must not fork a component for one glyph. .message.notice `components/_messages.css` owns core's empty-cloud else-branch. Not styled here, and not asserted either — see below. h1 `components/_base.css` (32px, 26px under 768). Magento's own page-title block, outside `.hrv-t39`. Untouched. .search-terms OWNED BY NOBODY. `grep -rln search-terms web/css/components/` returns nothing, and a rule walker over the LIVE page's `document.styleSheets` found no author rule matching it either. Stated because "the theme has no rule for X" is exactly the claim the playbook forbids writing without running the grep. tokens `tokens/_derived.css` owns every colour below. No literal colour appears in this file. WHAT THE CASCADE ACTUALLY CONTAINS, read from the live page rather than assumed — and one correction to my own first reading, recorded because it changed the answer: the bullets and the 40px indent come from the USER-AGENT STYLESHEET, not from Blank. A walker over `document.styleSheets` found exactly ONE author rule matching `ul.search-terms`: `ul, ol { margin-bottom: 2.5rem }` in `styles-m.css` (2.5rem = 25px here, since Magento sets the root to 62.5%). "Blank does it" would have sent the next reader to the wrong file. for the anchors, my first walker reported `a, .alink { color: rgb(25,121,195) }` at (0,1,1) beating `_base.css`'s `a` at (0,0,1) — which would mean the live links were Magento blue. They measure `rgb(192,138,45)`. THE INSTRUMENT WAS WRONG, NOT THE PAGE: specificity is per-selector within a selector list, so for an `` the matching half is `a` at (0,0,1), a tie that source order resolves in `_base.css`'s favour. Written down because the wrong number was nearly recorded here as a fact. ========================================================================== */ /* -------------------------------------------------------------------------- 1. The measure — 900, the comp's own REGISTER #98. The artboard's wrapper is `padding: 32px 40px 0; max-width: 900px` on a CONTENT-BOX document: 900 of content, 980 of border box. Under Harvest's theme-wide `* { box-sizing: border-box }` a literal transcription of BOTH declarations yields 820 of content — 80px short — while `rect.width` still reads a reassuring 900. So the horizontal padding is NOT transcribed: `.page-main` already supplies the comp's gutter (MEASURED 16 / 24 / 24 / 24 / 32 / 32 at the six gated widths), and with no inline padding here `content.width === rect.width` and the trap has nothing to act on. The gate still asserts `content.width` rather than `rect.width`, because that is the property that MOVES if anyone ever adds `padding-inline`, and a row that cannot move is not coverage. NO `margin-inline: auto`. The comp's cloud is left-aligned against the page gutter, flush with the h1 and the breadcrumb above it — not centred. MEASURED `.column.main` content: 343 / 720 / 900 / 901 / 960 / 1376 at 375 / 768 / 948 / 949 / 1024 / 1440. So this cap is satisfied EXACTLY WITHOUT BINDING at 948 and FIRST BINDS at 949 — derived (padding is 24 below 1024, so content = W - 48 first exceeds 900 at W = 949) and then re-measured at both, because below the binding edge a capped and an uncapped wrapper measure identically and a gate that only checked 375/768/1440 would be blind to this rule at most of its widths. -------------------------------------------------------------------------- */ .hrv-page-t39 .hrv-t39 { max-width: 900px; } /* -------------------------------------------------------------------------- 2. The cloud — a wrapping row instead of a bulleted list `display: flex` and `flex-wrap: wrap` are asserted as SEPARATE gate rows on purpose: flex WITHOUT wrap puts 24 terms on one line and shrinks them, which produces horizontal overflow rather than a cloud. The two failures look nothing alike and should not share a row. THE `