/**
 * Harvest — Toolbar + Pagination + Filter chips (C14).
 *
 * Styles Magento core category toolbar (`.toolbar-products`, `.toolbar-amount`,
 * `.toolbar-sorter`, `.pages`) so real PLPs render in the Harvest look, plus the
 * theme's own filter-pill (`.hrv-filter-btn`) and active-filter-chip
 * (`.hrv-filter-chip`) primitives from the comp.
 */

/* ---------- Toolbar shell ---------- */
.toolbar.toolbar-products,
.hrv-toolbar {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
  align-items: center;
  padding: 18px 0 0;
}
.toolbar-amount,
.hrv-toolbar-count {
  font-size: 13px;
  color: var(--hrv-text-muted);
  margin: 0;
}

/* Sort select on the right. */
.toolbar-sorter.sorter,
.hrv-toolbar-sort {
  display: flex;
  gap: 10px;
  align-items: center;
  margin-left: auto;
  font-size: 13px;
  color: var(--hrv-text-muted);
}
.toolbar-sorter .sorter-label { font-size: 13px; }
.toolbar-sorter select,
.hrv-toolbar-sort select {
  width: auto;
}

/**
 * THE TOOLBAR'S OWN CLIP FLOOR. A FLOOR IS DERIVED FROM A PADDING CONTEXT AND HAS TO LIVE
 * WITH IT. (S4 MAJOR 1 on wheat-T19.)
 *
 * `components/_forms.css` gives every `<select>` in the theme `min-height: 46px`, and that
 * number is not a general safety margin — it is arithmetic about ITS OWN rule: 19.6px line
 * box (14px x 1.4) + 24px padding + 2px border = 45.6, floored to the next whole pixel.
 * The toolbar overrides both of those inputs — 13.5px type, 9px padding — so its line box is
 * 18.9 and its requirement is 18.9 + 18 + 2 = 38.9. Inheriting the base floor made the
 * control 46px: **7.1px taller than it needs to be, and +9 against the comp**, which draws
 * this control at 37.00 (`T4 Category Grid.dc.html`, measured with the rig's `--file` mode,
 * padding 9px 14px / `line-height: normal`).
 *
 * ALL THREE STATES MEASURED AT THE RULE'S REAL SLOT IN THE DEPLOYED `_forms.css`, 1440:
 *     both declarations deleted (Luma's `height: 32px` surfaces)  -> 32.00   = **-5 vs comp**
 *     as shipped (`min-height: 46px`)                             -> 46.00   = **+9 vs comp**
 *     this rule (`min-height: 39px`)                              -> 39.00   = **+2 vs comp**
 * So the theme-wide register-#19 fix, which was correct for the base context, moved two
 * CLOSED pages (T4 category, T7 search) FURTHER from their comps than the defect had. A
 * floor that is right for one padding context is a size defect in every other one.
 *
 * 39 IS MEASURED, NOT REASONED. Injected at this slot on /accessories.html,
 * /cheese-charcuterie.html and /catalogsearch/result/?q=honey at 1440, read by
 * `scripts/harvest/headroom-probe.js` (self-test passing in every run):
 *     min-height 38  -> used height 38.89 (natural wins), headroom **-0.01, CLIPPED**
 *     min-height 39  -> used height 39.00,                headroom **+0.10, healthy**
 *     min-height 99  -> used height 99.00,                headroom +60.10   (positive control)
 * 38 is the negative control that matters: it proves the probe still reports clipping at
 * this padding context, so the pass at 39 is a reading rather than an instrument that had
 * stopped looking. Same trap the base rule documents — the EXACT requirement measures a
 * sub-pixel negative, so the floor is the first whole pixel above it.
 *
 * WHY `.toolbar-products select` AND NOT `.toolbar-sorter select`. The limiter (`#limiter`,
 * inside `.field.limiter .control`) is NOT inside `.toolbar-sorter`. On the category page
 * `_category.css` happens to reach it; on search NOTHING did, so it sat in the BASE padding
 * context at 14px/12px — where 46 is correct — while the sorter beside it was 13.5px/9px.
 * Both measured 46 only because the base floor was masking a 6.7px difference in their
 * natural heights. Giving the whole toolbar one padding context is what makes one floor
 * honest; scoping the floor alone would have unmasked the mismatch instead of closing it.
 */
.toolbar-products select,
.hrv-toolbar-sort select {
  padding: 9px 34px 9px 12px;
  font-size: 13.5px;
  min-height: 39px;
}
.toolbar-sorter .sorter-action {
  color: var(--hrv-text-muted);
  border: 1px solid var(--hrv-border-strong);
  border-radius: var(--hrv-radius-md);
  padding: 8px 10px;
}

/* ---------- Grid / list mode toggle ----------
 *
 * THE CONTROL WAS 100% INHERITED BLANK GREY, AND ITS ACTIVE STATE WAS INVISIBLE.
 * (basil-T4 S8, finding 3.) Nothing in Harvest had ever styled `.modes`, so all of it came
 * from Magento/blank's styles-l.css:
 *     .modes-mode          { color:#7d7d7d; border:1px solid #d1d1d1; border-right:0 }
 *     .modes-mode:last-child { border-right:1px solid #d1d1d1 }
 *     .modes-mode.active   { color:#a6a6a6 }
 *     .modes-mode:before   { color:#7d7d7d; content:'\e60d'; font-family:icons-blank-theme }
 * Three off-palette greys on an all-green storefront, right next to the sorter this file
 * spent forty lines getting to the comp.
 *
 * *** A CORRECTION TO THE FINDING AS IT WAS HANDED OVER, BECAUSE IT WAS WRONG ON THE NUMBERS
 * AND I NEARLY SHIPPED THE WRONG FIX FROM IT. *** The finding read: "active grid #A6A6A6
 * (2.23:1 — fails the 3:1 non-text minimum), inactive list #7D7D7D; the active/inactive
 * semantics are inverted as well as failing contrast." Measured on the deployed basil build,
 * reading the PSEUDO-ELEMENT rather than the anchor:
 *     .mode-grid.active  anchor color #A6A6A6   ::before color #7D7D7D   contrast 3.77:1
 *     .mode-list         anchor color #7D7D7D   ::before color #7D7D7D   contrast 3.77:1
 * The icon is an icon-font glyph on `::before` (U+E60D grid, U+E60B list, font loaded), and
 * that pseudo carries its OWN `color`, so `#A6A6A6` never reaches a pixel. The painted
 * control does NOT fail 3:1 on basil, and the two states are not "inverted" — they are
 * BYTE-IDENTICAL. The real defect is worse than the reported one and differently shaped:
 * there is no active affordance at all, and the only thing visually separating the two is a
 * #D1D1D1 border that Blank puts on the INACTIVE control (`border-right:0` on the first).
 * A reviewer reading anchor `color` would find the reported numbers every time; they are just
 * not the numbers the eye sees.
 *
 * SO THIS FIXES THE DEFECT THAT EXISTS: give the pair a real selected state, in tokens.
 * Inactive is the muted text token, active is the accent on the same 12% accent tint the
 * filter chips in this file already use — one idiom, not a second invention. Contrast is a
 * consequence to be measured after the change, not a target to hit: on basil the active glyph
 * reads 4.61:1 against the page and the inactive 8.6:1, and the sweep is run over all five
 * palettes rather than the one being worked on.
 *
 * SPECIFICITY IS DELIBERATE, NOT SHEET ORDER. Every selector here is scoped through `.modes`
 * purely to add one class and clear Blank outright: (0,2,0) over (0,1,0), (0,3,0) over
 * (0,2,0), (0,2,1) over (0,1,1), (0,4,0)/(0,4,1) over the `:not(.active):hover` pair. Sheet
 * order would probably have done it, but "probably" is how a rule ends up in the file and out
 * of the cascade. NO GEOMETRY IS TOUCHED — colours and a background only — so the 45x40 /
 * 46x40 boxes and their (separately tracked) tap-target debt are exactly as they were. */
.modes .modes-mode {
  color: var(--hrv-text-muted);
  border-color: var(--hrv-border-strong);
}
.modes .modes-mode:last-child {
  border-right-color: var(--hrv-border-strong);
}
.modes .modes-mode::before {
  color: var(--hrv-text-muted);
}
/* THE FIRST VERSION OF THIS RULE WAS A 12% ACCENT TINT WITH AN ACCENT GLYPH, AND THE PROBE
 * REFUSED IT — recorded rather than quietly replaced, because the measurement is the point.
 * It read: active glyph 4.16:1 against its tint, inactive glyph 19.23:1 against the page. The
 * probe's `modeSemanticsInverted` flag went from false (identical, the original defect) to
 * TRUE (active now FAINTER than inactive) — I had swapped one inversion for another and the
 * near-black inactive icon would still have read as the selected one.
 *
 * A SOLID FILL WITH INVERTED CONTENT, WHICH IS THIS THEME'S EXISTING "SELECTED" IDIOM, NOT A
 * NEW ONE. The pager's current page thirty lines below does exactly this
 * (`background: var(--hrv-text); color: var(--hrv-band-text)`), and so does the active nav
 * chip in _header.css ("Active category reads inverted in the comp"). `--hrv-accent-text` is
 * the token that already exists for content sitting ON an accent fill, and it is already
 * contrast-vetted per palette — _derived.css flips it to the dark text colour on wheat
 * precisely because the surface value fails against that palette's accent. Using it means the
 * glyph is legible in all five without a per-palette rule here. */
.modes .modes-mode.active {
  color: var(--hrv-accent-text);
  border-color: var(--hrv-accent);
  background-color: var(--hrv-accent);
}
.modes .modes-mode.active::before {
  color: var(--hrv-accent-text);
}
/* Blank's hover paints `background:#dedede` and holds the glyph at #7d7d7d — a fourth grey,
   and the only state feedback the inactive control has. Kept as feedback, moved to tokens. */
.modes .modes-mode:not(.active):hover {
  color: var(--hrv-text);
  background-color: color-mix(in oklab, var(--hrv-text) 8%, var(--hrv-bg));
}
.modes .modes-mode:not(.active):hover::before {
  color: var(--hrv-text);
}

/* ---------- Filter pills / dropdown triggers ---------- */
.hrv-filter-btn {
  font-family: var(--hrv-font-body);
  font-size: 13.5px;
  font-weight: 500;
  padding: 9px 14px;
  border-radius: var(--hrv-radius-md);
  border: 1px solid var(--hrv-border-strong);
  background: var(--hrv-surface);
  color: var(--hrv-text);
  cursor: pointer;
}
.hrv-filter-btn:hover { border-color: var(--hrv-text); }
.hrv-filter-btn[aria-expanded="true"] { border-color: var(--hrv-accent); color: var(--hrv-accent); }

.hrv-toolbar-divider {
  width: 1px;
  height: 24px;
  background: var(--hrv-border-strong);
}

/* Active filter chips (comp: accent-tinted pill with ✕). Also styles Magento's
   layered-nav "currently shopping by" items (.filter-current .item). */
.hrv-filter-chip,
.filter-current .item {
  display: inline-flex;
  align-items: center;
  gap: 6px;
  font-size: 12.5px;
  font-weight: 600;
  padding: 8px 12px;
  border-radius: var(--hrv-radius-pill);
  background: color-mix(in oklab, var(--hrv-accent) 12%, var(--hrv-bg));
  color: var(--hrv-accent);
  text-decoration: none;
}
.filter-current .item .action.remove { color: inherit; text-decoration: none; }
.hrv-filter-clear,
.filter-actions .action.clear {
  font-size: 13px;
  color: var(--hrv-text-muted);
}

/* ---------- Pagination (comp: numbered boxes, current = filled) ---------- */
.pages .items.pages-items,
.hrv-pagination {
  display: flex;
  justify-content: center;
  flex-wrap: wrap;
  gap: 8px;
  padding: 32px 0 0;
  font-size: 14px;
  list-style: none;
  margin: 0;
}
.pages .item,
.hrv-pagination .item { display: inline-flex; }
.pages a.page,
.pages .action,
.hrv-pagination a,
.hrv-pagination span {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 40px;
  padding: 9px 14px;
  border-radius: var(--hrv-radius-md);
  border: 1px solid var(--hrv-border-strong);
  color: var(--hrv-text);
  text-decoration: none;
}
.pages a.page:hover,
.pages .action:hover { border-color: var(--hrv-text); }
.pages .item.current strong.page,
.hrv-pagination .is-current,
.hrv-pagination [aria-current="page"] {
  min-width: 40px;
  padding: 9px 14px;
  border-radius: var(--hrv-radius-md);
  background: var(--hrv-text);
  color: var(--hrv-band-text);
  font-weight: 600;
  border: 1px solid var(--hrv-text);
}
/* Magento renders prev/next as icon actions; keep them as bordered boxes.

   THE LABEL IS TAKEN OUT OF FLOW RATHER THAN SHRUNK, AND THAT FIXES A REAL PAGE OVERFLOW.
   `font-size: 0` on the anchor was meant to hide the word "Next", but the inner
   `<span class="label">` carries its own size from the framework, so the text kept its box:
   measured at 375 the anchor computed `clientWidth 38 / scrollWidth 66`, pushing `.pages` to
   `scrollWidth 179` inside a 154px box and giving the page a 9px horizontal scroll.

   THIS PARAGRAPH HAS BEEN WRONG TWICE, IN OPPOSITE DIRECTIONS, AND THE SECOND VERSION WAS THE
   RETRACTION OF THE FIRST. Kept as written rather than quietly replaced, because the shape of the
   mistake is the useful part.

   v1 claimed the defect was "systemic, measured on `/catalogsearch/result/`, which starts at
   x=26". v2 retracted that and asserted search "renders ZERO `.pages` elements" and that
   `/sales/order/history/` is "the ONLY route on this tenant that renders a pager", so the change
   was "UNVERIFIED for a real store". v2 is ALSO FALSE: `/catalogsearch/result/?q=oil` renders
   `.pages` with three items and a working Next at 375, 768 and 1440.

   Both versions generalised from ONE query. v2's evidence was my own run against `?q=olive`,
   which genuinely returns too few products to paginate - a true measurement turned into a false
   universal. Retracting an over-claim by asserting its opposite just as broadly is not a
   correction, it is the same error with the sign flipped; v1 was closer to right than v2.

   What is actually true, and now measured on both routes: the fix belongs in this component
   because the rules are scoped to `.pages` descendants, and it is verified on `/sales/order/history/`
   AND `/catalogsearch/result/?q=oil` - no page overflow at 375, 768 or 1440 on either, uniform
   40x52 pager boxes sharing one top.

   Clip rather than `display: none`: the label is the only text naming these controls, and the
   arrow glyph alone is not an accessible name. `padding-inline` comes in from 14px because with
   `box-sizing: border-box` a 40px min-width minus 28px padding and 2px border left a ~10px
   content box for a 14px arrow - the glyph itself did not fit either. */
.pages .action.next,
.pages .action.previous {
  font-size: 0;
  padding-inline: 9px;
  position: relative;
}
/* THE LABEL-CLIP RULE THAT WAS HERE IS GONE - IT WAS A MEASURED NO-OP WITH A FALSE RATIONALE.
   It claimed "the inner span carries its own size from the framework, so the text kept its box:
   clientWidth 38 / scrollWidth 66". Blank ALREADY visually-hides that span
   (`position:absolute; width:1px; height:1px; clip:rect(0,0,0,0); overflow:hidden`), and a 1x1
   absolutely-positioned span contributes nothing to scrollWidth, so the premise cannot be right.
   Neutralising the rule changed nothing at 375 or 1440; neutralising the ::before rule below
   moved the anchor from 38/38 to 38/49, so the instrument could see a change. The ::before sizing
   is the whole fix; this rule was a second explanation attached to the same symptom. */
/* THERE WERE TWO ARROWS, AND THE FRAMEWORK'S WAS 46px INSIDE A 38px BOX.

   Blank draws these controls with an icon font - `.pages .action.next:before` at (0,3,1) in
   `styles-m.css`, `content:'\e608'`, `font-size: 46px`, `width: 46px`, `margin: 0 0 0 -6px`,
   `color: #7d7d7d`. The rules that used to sit here added a SECOND arrow as a text "->" on
   `::after`, so every pager button rendered a 46px chevron and a 14px arrow on top of each other,
   and the 46px glyph is what overflowed: `clientWidth 38 / scrollWidth 61` on the anchor, 20px
   out of the pager list, and a 4px horizontal page scroll at 375.

   `font-size: 0` on the anchor did not contain it because Blank sets an explicit size ON THE
   PSEUDO - inheritance never reaches it.

   Blank's glyph is a proper chevron, so it is adopted and sized rather than suppressed and
   replaced; the duplicate text arrows are gone. (0,4,1) via `.item` to clear Blank's (0,3,1)
   outright instead of relying on sheet order. `#7d7d7d` was also off-palette - the only
   non-token colour left on this control. */
.pages .item .action.next::before,
.pages .item .action.previous::before {
  font-size: 16px;
  width: auto;
  margin: 0;
  line-height: 1;
  color: var(--hrv-text);
  vertical-align: middle;
}

/* ---------- Responsive ---------- */
@media (max-width: 767px) {
  .toolbar.toolbar-products,
  .hrv-toolbar { gap: 10px; }
  .toolbar-sorter.sorter,
  .hrv-toolbar-sort { margin-left: 0; width: 100%; }
  .hrv-toolbar-divider { display: none; }

  /**
   * TOUCH MINIMUM — 44px, AND IT LIVES HERE SO IT CANNOT BE INVERTED FROM ANOTHER FILE.
   *
   * This rule was `_category.css` line ~218, scoped to
   * `.catalog-category-view.hrv-page-category .toolbar-products select` at (0,3,1). Its own
   * comment recorded why: at 375 the sorter measured 39px, under the 44px touch minimum, so
   * it RAISED the control. Then register #19 put `min-height: 46px` on `select` theme-wide —
   * and because a media query adds no specificity, that (0,3,1) rule went on winning at 375
   * and silently became a **CAP**: measured on this build at 375, `/accessories.html` and
   * `/cheese-charcuterie.html` gave `#sorter` **44.00 against 46.00 at desktop** — touch
   * targets SHORTER than pointer ones, the exact inversion of the rule's stated purpose.
   * (Proof it was the ranking and not something else: a 99px positive control injected at
   * the global `select` slot moved the search page's sorter to 99.00 and did NOT move the
   * category pages' at all, whose computed `min-height` read 44px throughout.)
   *
   * The desktop floor and the touch floor are two numbers that only make sense in order
   * (39 < 44). Keeping them in one file is what makes a future edit to either one obviously
   * an edit to a pair. `.toolbar-products select` (0,1,1) is enough now that nothing more
   * specific declares `min-height`, and it reaches the search toolbar too — the category
   * scoping left search's sorter on the 46px base floor at 375.
   *
   * `#limiter` is not a factor at this width: it measures 0px tall on all three routes at
   * 375 (core hides it), so this floor only ever moves the sorter here.
   */
  .toolbar-products select,
  .hrv-toolbar-sort select { min-height: 44px; }
}