/**
 * Harvest — Forms kit (C8).
 *
 * Inputs, textareas, selects, labels, checkboxes/radios and fieldsets. Styles
 * both the theme's `.hrv-input`/`.hrv-field` classes AND Magento core form
 * controls (`.form input`, `.fieldset .control input`, `select`, etc.) so
 * checkout / account / contact forms inherit the Harvest look with no core edits.
 *
 * Comp reference: 1px border (color-mix text 24%), 8px radius, 12–14px padding,
 * accent focus ring.
 */

.hrv-input,
input[type="text"],
input[type="email"],
input[type="password"],
input[type="search"],
input[type="tel"],
input[type="url"],
input[type="number"],
textarea,
select,
.form-control {
  width: 100%;
  font-family: var(--hrv-font-body);
  font-size: 14px;
  line-height: 1.4;
  color: var(--hrv-text);
  background: var(--hrv-surface);
  border: 1px solid var(--hrv-border-strong);
  border-radius: var(--hrv-radius-md);
  padding: 12px 14px;
  box-sizing: border-box;
  transition: border-color 0.15s ease, box-shadow 0.15s ease;
}
textarea { min-height: 120px; resize: vertical; }

/**
 * NEUTRALISE LUMA'S FIXED `select { height: 32px }`. (Register 19.)
 *
 * The rule above gives every control `font-size: 14px; line-height: 1.4` (a 19.6px line
 * box), `padding: 12px`, `border: 1px` — but never touches `height`, so Blank's
 * `select { height: 32px }` survives underneath it. 32 - 24 - 2 leaves a SIX pixel content
 * box to hold a 19.6px line: headroom -13.60, and the UA-drawn option text is cropped by
 * the box that contains it, theme-wide. Measured on 18 controls across 10 routes.
 *
 * THAT DENOMINATOR WAS FIRST WRITTEN AS "15 controls across 8 routes", AND THE SHORTFALL WAS
 * STRUCTURAL RATHER THAN CARELESS. The sweep was driven from `routes-all.txt`, which sends
 * `/wishlist/` and `/newsletter/manage/` to the login page for a guest — so the census silently
 * measured the LOGIN form twice instead of the two pages it named, and every control behind
 * authentication was outside the denominator by construction. Re-run with a session, three
 * further selects appear: `/customer/address/new/` x2 and `/wishlist/` x1. All three measure
 * 46px at +0.40 headroom, i.e. the fix already covers them and the OUTCOME never changed —
 * but "15 across 8" described a smaller blast radius than the rule actually has, and a
 * denominator that quietly excludes authenticated routes is the kind of figure that is right
 * by luck. A route list is only a denominator for the pages it can actually reach.
 *
 * ONLY `<select>` IS FIXED HERE, and that is deliberate. The identical arithmetic is true of
 * the text inputs above — they are 32px with a 6px content box too — and they DO NOT CLIP: a
 * browser paints an input's value across its full inner height, so for an `<input>` the
 * content box is simply the wrong property to reason from. Verified rather than assumed:
 * with real values typed in, 0 of 9 checkout inputs clipped and 2 of 2 selects did. The
 * inputs' 32-vs-43px delta against the comp is real but is a SIZE-FIDELITY item, recorded at
 * `wheat-T18.json -> C_card_1_contact.email_input.DELTA_RECORDED_S3_F1`; resizing every text
 * field in the theme is not this fix's blast radius.
 *
 * WHY BOTH DECLARATIONS, AND WHY 46 AND NOT THE EXACT MINIMUM.
 *   `min-height` carries it today. The arithmetic minimum is 19.6 + 24 + 2 = 45.6px, and the
 *   exact expression of it — `calc(1.4em + 26px)` — MEASURES -0.006 HEADROOM, not zero:
 *   Chrome lays the derived value out a hair under the declared line box and the control is
 *   still, by measurement, clipped. `height: auto` alone lands in the same trap (-0.01). So
 *   the floor must be a whole pixel above the requirement, and 46px is the SMALLEST one —
 *   chosen to sit as close as possible to the comp (see below) at a measured +0.40.
 *   `height: auto` is not redundant with it: it is what stops the constant from having to
 *   carry future-proofing. Should the padding or font-size here ever grow, `auto` grows the
 *   control with them, where a lone `min-height` would let it silently re-clip.
 *
 * AGAINST THE COMP, ON PURPOSE. `T18 Checkout Shipping.dc.html` renders its controls 43px
 * tall (measured with the rig's `--file` mode, not read off a declaration — the artboard
 * declares no height at all). 46px is 3px over that, and the gap is not a compromise, it is
 * arithmetic: the comp's 43px is an `<input>`'s intrinsic height, whose 17px content box is
 * SMALLER than this theme's own 19.6px line box. No `<select>` can be 43px tall at the
 * comp's 12px padding without clipping. Reaching 43 would mean either cutting the padding
 * below the comp's own figure, or dropping `line-height` to `normal` — and `normal` is
 * precisely the value the headroom probe refuses to score, so that route would buy comp
 * fidelity by making the fix unverifiable by the instrument that found the defect.
 *
 * `select[multiple]` still renders correctly — but the original reason given here covered only
 * half of what this rule declares. It said "Blank already sets it `height: auto`", which is
 * true and explains why the two advanced-search multiselects were the only selects in the
 * theme that never clipped. It does NOT explain `min-height`, which is a NEW declaration that
 * Blank has no counterpart for and which therefore DOES newly apply to them. It is inert for a
 * different reason: a multiple-size select's natural height here is 98px, comfortably above the
 * 46px floor, so the floor never binds. Both halves are needed — "unaffected because a property
 * it does not set is already set elsewhere" would be a false reassurance the moment a
 * multiselect were ever rendered short enough for 46px to bite.
 *
 * 46 IS THIS RULE'S NUMBER, NOT THE THEME'S — AND THE UNSCOPED SELECTOR HID THAT. (S4 MAJOR 1
 * on wheat-T19.) Every input to the 45.6 above comes from the block at the top of this file:
 * 14px type, 1.4 line-height, 12px padding. Anywhere the theme overrides those, the arithmetic
 * changes and this constant is simply the wrong size — it does not become unsafe, it becomes
 * TOO BIG. Measured at 1440 on /accessories.html, /cheese-charcuterie.html and
 * /catalogsearch/result/?q=honey, the PLP/search sort + limit controls (13.5px type, 9px
 * padding, requirement 38.9) were pushed to 46.00 against a comp that draws them at 37.00 —
 * **+9**, where the defect this rule fixes had them at 32.00, **-5**. Two CLOSED pages moved
 * away from their comps because a floor derived here was applied there.
 *
 * SO A FLOOR TRAVELS WITH ITS PADDING CONTEXT. `components/_toolbar.css` now declares
 * `min-height: 39px` for `.toolbar-products select` — derived the same way from ITS OWN
 * padding and type, calibrated the same way (38 measures -0.01 and clips, 39 measures +0.10),
 * and sitting beside the padding it is derived from. If a future rule overrides the padding
 * or font-size of a `<select>` again, it owes a floor too; this one will be too tall for it.
 */
select {
  height: auto;
  min-height: 46px;
}

.hrv-input::placeholder,
input::placeholder,
textarea::placeholder { color: var(--hrv-text-subtle); }

.hrv-input:focus,
input:focus,
textarea:focus,
select:focus,
.form-control:focus {
  outline: none;
  border-color: var(--hrv-accent);
  box-shadow: 0 0 0 3px var(--hrv-focus-ring);
}

/* THE SELECT CHEVRON — DRAWN FROM TOKENS, BECAUSE A DATA-URI SVG CANNOT READ ONE.
 *
 * THE COMMENT THIS REPLACES SAID "currentColor-tinted, palette safe" AND WAS FALSE ON BOTH
 * COUNTS. It shipped an inline-SVG data URI whose path carried a URL-ENCODED `#888` fill — a
 * fixed grey. (Written here in words, not as the literal bytes: this file is served to the
 * browser, and a future gate that scans WITHOUT stripping comments would have to special-case
 * a comment that quotes the very pattern it hunts.) An SVG inside a `url()` is a separate
 * document: it does not inherit
 * `currentColor` and it cannot resolve `var(--hrv-*)`, so the arrow on EVERY <select> in the
 * theme was #888 under all five palettes. The comment asserting palette-safety is exactly
 * what stopped anyone reading the line beneath it.
 *
 * It also sat in Gate B's blind spot: the checker matched `#RRGGBB` / `rgb(` / `hsl(` and
 * could not see a hex written `%23`. That hole is now closed in scripts/harvest/hex-check.py
 * (pinned by its own self-test), and this file was the single hit across all 58 Harvest
 * component + page stylesheets when the widened checker was first run over them.
 *
 * TWO LINEAR-GRADIENT TRIANGLES, NOT AN SVG AND NOT A PER-PALETTE URL. The alternatives were
 * weighed rather than defaulted to:
 *   - `mask-image` + `background-color` would tint the arrow, but the mask applies to the
 *     whole element, so it would eat the field's own fill and its text.
 *   - Hoisting the data URI into a custom property and re-declaring it in each of the five
 *     _palette-*.css files works, but it makes the chevron a SIXTH thing every new palette
 *     must remember, duplicating a colour the palette already defines. CLAUDE.md 11.3 wants
 *     "one file, zero component edits" per palette; that route buys the opposite.
 *   - Two gradients resolve `var()` natively, cost nothing, and track the palette with no
 *     palette-file change at all.
 * *** THE COMMENT THAT STOOD HERE CLAIMED A SHAPE CHANGE THAT DOES NOT HAPPEN, AND TWO
 * REVIEWERS DERIVED THE GEOMETRY TO PROVE IT. *** It read: "the shape moves from a solid
 * triangle to a caret. That is a DECLARED, deliberate deviation: a caret is the conventional
 * select affordance." Both halves are wrong. Work the two layers out:
 *     layer A  `45deg, transparent 50%, C 50%`   in a 5x5 box -> the TL-TR-BR half
 *     layer B  `135deg, C 50%, transparent 50%`  in a 5x5 box -> the TL-TR-BL half
 *     positions `right 19px` and `right 14px`, 5px wide each, so the boxes ABUT exactly
 * Their union is one SOLID DOWN-POINTING TRIANGLE, 10px across the top, apex at bottom centre.
 * The SVG it replaces (`width=12 height=8`, `M6 8 0 0h12z`) was the same shape at 12x8.
 * NOTHING ABOUT THE SHAPE CHANGED - the glyph is simply 2px narrower and 3px shorter.
 *
 * So there is no deviation to declare, and the sentence justifying one ("a caret is the
 * conventional affordance") was defending a decision nobody made. Left as a correction rather
 * than deleted: a comment that invents a rationale is worse than no comment, because the next
 * reviewer trusts it instead of re-deriving the geometry - which is exactly what happened until
 * someone did.
 *
 * `--hrv-select-chevron` is CONSUMED WITH A FALLBACK AND NOT DECLARED ON THIS RULE, and the
 * difference is the whole point. Declaring the default here would put it ON THE ELEMENT, so a
 * page setting `--hrv-select-chevron` on an ancestor - `.hrv-page-t43 { --hrv-select-chevron:
 * ... }`, which is how every other --hrv-* token in this theme is set and the first thing anyone
 * would try - would be silently beaten by the local declaration and do nothing. Written as
 * `var(--hrv-select-chevron, var(--hrv-text-muted))` the token is inherited if an ancestor sets
 * it and falls back to the muted text colour if nobody does.
 *
 * The inner fallback matters too: if `--hrv-text-muted` were ever undefined, an unresolvable
 * var() makes the whole `background-image` invalid-at-computed-value, i.e. NO ARROW AT ALL,
 * silently. The old data URI at least degraded to a grey triangle. Any colour given here must
 * be a token.
 *
 * PADDING-RIGHT IS PART OF THE AFFORDANCE, NOT DECORATION. The 36px gutter is what keeps a
 * long option label off the arrow. Anything overriding it — including a `padding:` shorthand
 * written for another reason — takes the arrow's space back, which is half of how this defect
 * happened. `scripts/harvest/select-affordance-check.js` now fails the build on a
 * `background:`/`padding:` SHORTHAND in any rule that targets a <select>, because both of
 * those reset a longhand this rule owns without ever naming it. */
select {
  appearance: none;
  -webkit-appearance: none;
  background-image:
    linear-gradient(45deg, transparent 50%,
      var(--hrv-select-chevron, var(--hrv-text-muted)) 50%),
    linear-gradient(135deg, var(--hrv-select-chevron, var(--hrv-text-muted)) 50%,
      transparent 50%);
  /* One value per property: CSS replicates it across both layers. The doubled forms said
     nothing extra and invited a mismatch the day a third layer is added. */
  background-repeat: no-repeat;
  background-position: right 19px center, right 14px center;
  background-size: 5px 5px;
  padding-right: 36px;
}

/* Labels / fields. */
.hrv-label,
.field > .label,
.fieldset > .field > .label {
  display: inline-block;
  font-size: 13px;
  font-weight: 600;
  color: var(--hrv-text);
  margin-bottom: 6px;
}
.hrv-field { margin-bottom: 18px; }
.hrv-field-note,
.field .note {
  font-size: 12.5px;
  color: var(--hrv-text-muted);
  margin-top: 6px;
}
.hrv-field--required .hrv-label::after,
._required > .label::after,
.required > .label::after {
  content: " *";
  color: var(--hrv-error);
}

/* Invalid state (Magento adds .mage-error + input.mage-error). */
input.mage-error,
select.mage-error,
textarea.mage-error,
.hrv-input--error {
  border-color: var(--hrv-error);
}
div.mage-error,
.hrv-field-error {
  color: var(--hrv-error);
  font-size: 12.5px;
  margin-top: 6px;
}

/* Checkboxes & radios — accent-tinted via accent-color (falls back gracefully). */
input[type="checkbox"],
input[type="radio"] {
  width: auto;
  accent-color: var(--hrv-accent);
  margin-right: 8px;
}

/* Inline field group: input + attached button (search bar, newsletter). */
.hrv-input-group {
  display: flex;
  align-items: stretch;
}
.hrv-input-group .hrv-input {
  border-top-right-radius: 0;
  border-bottom-right-radius: 0;
  border-right: none;
}
.hrv-input-group .hrv-btn {
  border-top-left-radius: 0;
  border-bottom-left-radius: 0;
  white-space: nowrap;
}

fieldset { border: none; margin: 0; padding: 0; }