/* ==========================================================================
T38 — Advanced Search (/catalogsearch/advanced/)
SCOPED ON `.hrv-page-t38`, A DECLARED CLASS, AND THE NATIVE `catalogsearch-advanced-index` IS
ASSERTED SEPARATELY RATHER THAN USED AS THE HOOK.
Both classes are really on — MEASURED on the live page, not reasoned by analogy from
another page, because a reskin scoped to a GUESSED body class is 100% dead CSS while passing
every static review. `catalogsearch-advanced-index` comes from Magento's own layout for this
route; `hrv-page-t38` is declared by this theme's handle
( computes `background-color: rgba(0, 0, 0, 0)` and
`border-radius: 0px` — there is no card on this page at all today.
NOT `display: flex` WITH A `gap`, AND THAT IS THE INTERESTING PART. The comp's panel is drawn as
a flex column with `gap: 18px`, and transcribing that literally would be wrong for THIS markup:
the core template emits `` and a bare ` is the ACCESSIBLE NAME of its : a screen reader announces "Search Settings,
group" on entering it. The comp's card has no visible header, so it is clipped out of view and
left in the accessibility tree. `display: none` would have looked identical and would have
deleted the group's name — the same outcome as removing the element, while appearing to keep it.
Beats `.fieldset .legend { margin-left: 25.8% }` (styles-l.css, (0,2,0), @media min-width 768) —
which is why an un-reset legend is indented to the old label column even when invisible.
The `EUR ` inside `.addon`. So only two things are needed: the comp's
16px gutter, and a currency suffix that stops stealing width.
THE GUTTER GOES INSIDE THE 50%, WHICH IS WHY IT NEEDS NO WIDTH CHANGE AT ALL. styles-m.css
already sets `box-sizing: border-box` on these children, so 8px of padding on the facing edge of
each column subtracts from the 50% rather than adding to it — 16px of visual gap, no `width`
declaration, and nothing to lose an `!important` fight with.
-------------------------------------------------------------------------- */
.hrv-page-t38 .hrv-t38 .fieldset > .field .fields.group.group-2 > .field:first-child {
padding-inline-end: 8px;
}
.hrv-page-t38 .hrv-t38 .fieldset > .field .fields.group.group-2 > .field:last-child {
padding-inline-start: 8px;
}
/*
AND THE ACTUAL CAUSE OF THE UNEQUAL INPUTS, WHICH WAS NEITHER THE CONTAINER NOR THE ADDON.
I blamed the addon twice and was wrong twice. MEASURED with the columns already equal (both
`.field` children 271px) the two inputs were STILL 20px apart, and the reason is one step
further in:
styles-m.css .form.search.advanced .fields.range .field:first-child .control { padding-right: 25px }
styles-m.css .form.search.advanced .fields.range .field.with-addon .control { padding-right: 45px }
Two different paddings on the two `.control` boxes — 25 and 45 — reserving room for a validation
message and for the currency addon respectively. 45 - 25 = 20, which is EXACTLY the spread the
gate reported, unchanged, at every width and through three different container layouts. That
constancy was the clue I kept walking past: a defect caused by the flex addon would have varied
with the column width, and a defect caused by the grid would have changed when the grid did.
Both rules are (0,5,0) and NEITHER carries `!important` — checked explicitly this time, having
already documented one specificity mechanism that turned out to be an `!important` I had not
looked at. This reset is (0,7,0).
WHAT THIS COMMENT USED TO SAY ABOUT THE VALIDATION MESSAGE WAS WRONG. It claimed the message
is placed by mage/validation into the `.range` parent rather than the control, "which is what the
template's errorPlacement callback does". Read the callback: it tests `element.parent()`, and
`element` is the INPUT, whose parent is `.control` (or `.addon` for price-to). `.range` is three
levels up, so `parent.hasClass('range')` is NEVER true here and that branch is dead code on this
page — every message goes through the plain `error.insertAfter(element)` path.
The conclusion survived for a different reason than the one stated: the message is a BLOCK
sibling of the input, so it needs no horizontal reserve at all. But the stated mechanism was
load-bearing for the decision, and it was not what the code does. S1 correctness review.
*/
.hrv-page-t38 .hrv-t38 .form.search.advanced .fields.range .field .control {
padding-inline-end: 0;
}
/* --------------------------------------------------------------------------
6b. AND THE 25px WAS NOT SPARE — IT IS THE GUTTER THE FROM-TO EN DASH SITS IN.
THIS IS THE MOST SERIOUS DEFECT THIS TASK SHIPPED, AND IT WAS MINE. The comment above used to
say the 25px reserved room for a validation message. It does not. The third rule in the same
core block — nested INSIDE the one I did read, which is why my cascade probe never returned it —
is:
_module.less .form.search.advanced .fields.range .field:first-child { position: relative }
_module.less … .field:first-child .control::after {
content: ' \2013 '; position: absolute; right: 0; top: 6px; width: 25px }
That is the en dash between the from and to boxes, absolutely positioned into the gutter the
padding was holding open. `.control` is not positioned, so `right: 0` resolves against
`.field:first-child`, which core DOES position — so removing the control's padding did not move
the dash, it only let the input grow underneath it.
MEASURED on the live page after my change, and this is what makes it a defect rather than an
untidiness: `document.elementFromPoint()` at the from-input's trailing edge returned
**DIV.control, not the INPUT**. The dash's 25px box is painted over the input's last 17px and,
with default pointer-events, swallows clicks there — click the right end of the price-from field
and the caret does not move. A stray hyphen also sits inside the box.
IT IS RE-HOMED RATHER THAN DELETED. Deleting it (`content: none`) was the smaller change and I
rejected it: this page keeps Magento's single "Price" label over two unlabelled inputs (see the
declared divergence), so the dash is the ONLY thing on screen saying which box is from and which
is to. Removing it would trade a click bug for an affordance bug. Instead it moves into the 16px
gutter the columns already have: `right: -8px` puts its 16px box exactly between the two inputs
(MEASURED: they end at 324 and begin at 340 at 1440), and `top: 50%` with a translate centres it
on a 44px input — core's `top: 6px` was calibrated to Blank's 32px one.
`pointer-events: none` regardless, because an ornament must never be a click target.
Core's selector is (0,8,0)+::after; this is (0,10,0).
-------------------------------------------------------------------------- */
.hrv-page-t38 .hrv-t38 .form.search.advanced .fields.range .field:first-child .control::after {
inset-inline-end: -8px;
width: 16px;
top: 50%;
transform: translateY(-50%);
text-align: center;
pointer-events: none;
}
/*
THE CURRENCY SUFFIX IS OVERLAID, AND THIS IS THE ROW'S WHOLE DIFFICULTY.
MEASURED PRE-DEPLOY: the two price inputs are 230.23 and 210.23 wide at 1440 (spread 20) and
197.59 vs 183 at 768 (spread 14.594). They are not unequal by accident — the "to" input sits
inside `.addon` (styles-m.css `.fieldset > .field .addon { display: inline-flex; width: 100% }`)
beside an `EUR `, and as a flex sibling it gives up exactly the
label's width. Two equal COLUMNS therefore still produce two unequal INPUTS, and the comp draws
them equal.
So `.addon` becomes a positioned block, the input fills it, and the suffix is taken out of flow
and placed over the input's trailing end, with `padding-inline-end` reserving room so typed text
never runs under it. Under border-box that padding does not change the rect width, which is what
`price-inputs-are-two-equal-columns` measures.
`display: block` is load-bearing here and not tidying: while `.addon` is a flex container the
input and the label SHARE the box, which is the entire defect. Taking the label out of flow is
not sufficient on its own — a flex container with one in-flow item still shrink-wraps it.
`pointer-events: none` on the suffix: it is a , so without this it would
swallow clicks on the last 52px of the field. Its `for` association — the part that matters to
assistive technology — is unaffected, and clicking anywhere in the input now places the caret.
*/
.hrv-page-t38 .hrv-t38 .fieldset > .field .addon {
display: block;
position: relative;
width: 100%;
}
.hrv-page-t38 .hrv-t38 .fieldset > .field .addon > input.input-text {
width: 100%;
padding-inline-end: 52px;
}
/*
THIS RULE WAS INERT IN ITS FIRST FORM, AND ITS OWN COMMENT DESCRIBED THE MECHANISM IT DID NOT
HAVE. It was written at (0,6,0) and core declares, in the SAME block as everything else this
section fights:
_module.less .form.search.advanced .group.price .addon .addafter {
background: none; border: 0; padding-top: 6px;
position: absolute; right: 0; top: 0 } (0,7,0)
MEASURED afterwards: `top` computed to 0px and `right` to 0px — NOT the 1px/1px this rule
declared — and `padding-top` stayed at core's 6px, which with `align-items: center` pushed the
suffix off the optical centre of a 44px field. Logical properties do not help: `inset-block-start`
and `top` cascade as the same computed property, so the higher-specificity physical declaration
simply wins.
This is now (0,9,0), and `padding` is reset explicitly rather than assumed. Third time in this
task that a cascade comment was more confident than the cascade; all three had the same cause —
the probe returned the rules I asked it about, not the block they live in.
*/
.hrv-page-t38 .hrv-t38 .form.search.advanced .group.price .addon > .addafter {
position: absolute;
inset: 1px 1px 1px auto;
display: flex;
align-items: center;
margin: 0;
padding: 0 12px;
border: 0;
background: none;
font-size: 13px;
font-weight: 600;
color: var(--hrv-text-muted);
pointer-events: none;
}
/*
AND THE VALIDATION MESSAGE HAD TO MOVE WITH IT — a regression this task introduced and the gate
could not see, because no row ever puts the form in an invalid state.
_module.less .form.search.advanced .fields.range .field:last-child { position: relative }
_module.less … .field:last-child div.mage-error { position: absolute; left: 0; top: 32px }
`top: 32px` was calibrated to Blank's 32px input: the message sat flush underneath. Two things
here break it — the 44px floor makes the input taller, and `position: relative` on `.addon`
(added for the currency overlay) makes the ADDON, not `.field:last-child`, the containing block.
MEASURED by actually submitting an inverted range (from=100, to=1) and reading the real
mage/validation output: the message box for the "to" field lands at y=637.9 while its input ends
at y=645.5 — SEVEN AND A HALF PIXELS ON TOP OF THE INPUT, over its border and value. The "from"
field's message, which is static, sits correctly 6px below.
`top: 100%` re-anchors it to the bottom of whatever the containing block turns out to be, so it
cannot drift again if the input height changes. Kept absolute so `.addon` does not grow and drag
the currency suffix down with it. (0,10,1) against core's (0,8,1).
*/
.hrv-page-t38 .hrv-t38 .form.search.advanced .fields.range .field:last-child div.mage-error {
top: 100%;
margin-top: 4px;
}
/* --------------------------------------------------------------------------
7. The submit row
THE TOOLBAR IS INDENTED TO THE OLD LABEL COLUMN AND HAS TO BE PULLED BACK. Read out of the live
page, and it is not an obvious rule to go looking for:
styles-l.css @media (min-width: 768px), print
.abs-margin-for-forms-desktop, .fieldset .legend,
.column:not(.sidebar-main) form .actions-toolbar, … { margin-left: 25.8% }
MEASURED at 1440: the toolbar's computed margin-left is 177.5px and the button starts at x=209.5,
aligned with the control column that this sheet has just removed. Left alone, the page's only
call to action would sit a quarter of the way across a panel whose fields are now full width.
THE SPECIFICITY IS THE TRAP HERE. The matching part of that selector is
`.column:not(.sidebar-main) form .actions-toolbar` = (0,3,1) — three classes AND a type selector.
`.hrv-page-t38 .hrv-t38 .actions-toolbar` is (0,3,0) and LOSES on the tie-break. The extra class
below is what makes this rule apply at all, and it is the reason the template puts
`hrv-t38__actions` on that div rather than the sheet reaching for `.actions-toolbar` alone.
`.actions-toolbar .primary { float: left }` (styles-l.css, (0,2,0), >=768) is reset as well: a
floated child leaves the toolbar zero-height, so the 18px margin below would collapse against
the panel and the button would overlap it.
NOTHING HERE STYLES THE BUTTON. `components/_buttons.css` already owns `.action.primary` — fill,
border, radius, padding, hover, disabled — and it MEASURES 44.8px tall and 5.44:1 today. The
comp's `width: fit-content` is already what a shrink-to-fit button does.
-------------------------------------------------------------------------- */
.hrv-page-t38 .hrv-t38 .actions-toolbar.hrv-t38__actions {
margin: 18px 0 0;
padding: 0;
}
.hrv-page-t38 .hrv-t38 .actions-toolbar.hrv-t38__actions > .primary {
float: none;
margin: 0;
text-align: start;
}
/* --------------------------------------------------------------------------
8. Mobile
Below 768 Blank has already stacked the fields, so nothing here re-does that — this is only the
panel's own rhythm at 375, where 28px of padding on a 343px column leaves too little measure. The
comp is drawn at 1440 and cannot answer what happens below it, so these are the theme's values
and not transcription; `no-horizontal-page-scroll` gates the one property that must hold at every
width regardless, and the two-column price grid is the construct on this page most able to break
it.
The price grid deliberately STAYS two columns at 375. From/to is a pair a shopper reads as one
control, and stacking it would also make `price-inputs-share-one-row` a width-conditional claim
for no benefit. The suffix inset is reduced instead, so the "to" field keeps usable typing room
in a ~145px track.
-------------------------------------------------------------------------- */
@media (max-width: 767px) {
.hrv-page-t38 .hrv-t38 .fieldset.hrv-t38__panel {
padding: 20px 18px;
}
.hrv-page-t38 .hrv-t38 .fieldset > .field .fields.group.group-2 > .field:first-child {
padding-inline-end: 6px;
}
.hrv-page-t38 .hrv-t38 .fieldset > .field .fields.group.group-2 > .field:last-child {
padding-inline-start: 6px;
}
.hrv-page-t38 .hrv-t38 .fieldset > .field .addon > input.input-text {
padding-inline-end: 44px;
}
.hrv-page-t38 .hrv-t38 .form.search.advanced .group.price .addon > .addafter {
padding: 0 8px;
font-size: 12px;
}
/* The dash's gutter is 12px at this width (6px of padding each side), not 16px. */
.hrv-page-t38 .hrv-t38 .form.search.advanced .fields.range .field:first-child .control::after {
inset-inline-end: -6px;
width: 12px;
}
}