/* ===== 260825_customsearch_v1 — Round 11: custom search widget styling
   Replicates the look of the outgoing Advanced Woo Search (AWS) plugin's
   search box + results dropdown (measured live from the Buy Online page),
   so the visual swap is invisible to shoppers. */

.hpp-search {
	position: relative;
	width: 100%;
	max-width: 360px;
	font-family: Montserrat, Helvetica, Arial, Lucida, sans-serif;
}

.hpp-search-wrapper {
	position: relative;
	display: flex;
	align-items: center;
	width: 100%;
	background: #fff;
	border: 1px solid #e0e0e0;
	border-radius: 999px;
	box-shadow: 0 1px 6px 0 rgba(0, 0, 0, 0.08);
	overflow: hidden;
}

.hpp-search-field {
	flex: 1 1 auto;
	border: 0;
	outline: 0;
	background: transparent;
	font-family: inherit;
	font-size: 14px;
	line-height: 28px;
	font-weight: 500;
	color: #666;
	padding: 8px 8px 8px 20px;
	min-width: 0;
	-webkit-appearance: none;
	appearance: none;
}

.hpp-search-field::-webkit-search-cancel-button {
	-webkit-appearance: none;
}

.hpp-search-field::placeholder {
	color: #999;
}

.hpp-search-btn {
	flex: 0 0 auto;
	display: flex;
	align-items: center;
	justify-content: center;
	width: 40px;
	height: 40px;
	border: 0;
	background: transparent;
	color: #666;
	cursor: pointer;
	padding: 0;
}

.hpp-search-btn svg {
	width: 16px;
	height: 16px;
	fill: none;
	stroke: currentColor;
	stroke-width: 2;
}

.hpp-search-clear {
	flex: 0 0 auto;
	display: none;
	align-items: center;
	justify-content: center;
	width: 24px;
	height: 24px;
	border: 0;
	background: transparent;
	color: #999;
	font-size: 16px;
	line-height: 1;
	cursor: pointer;
	padding: 0;
}

.hpp-search.has-term .hpp-search-clear {
	display: flex;
}

.hpp-search-loader {
	display: none;
	position: absolute;
	right: 46px;
	top: 50%;
	width: 14px;
	height: 14px;
	margin-top: -7px;
	border: 2px solid #e0e0e0;
	border-top-color: #666;
	border-radius: 50%;
	animation: hpp-search-spin 0.6s linear infinite;
}

.hpp-search.is-loading .hpp-search-loader {
	display: block;
}

@keyframes hpp-search-spin {
	to { transform: rotate( 360deg ); }
}

/* ---- results dropdown ---- */

.hpp-search-results {
	display: none;
	position: absolute;
	top: 100%;
	left: 0;
	right: 0;
	margin-top: 4px;
	background: #fff;
	border: 1px solid #ccc;
	max-height: 420px;
	overflow-y: auto;
	z-index: 99999;
	text-align: left;
}

.hpp-search.is-open .hpp-search-results {
	display: block;
}

.hpp-search-result-item {
	display: block;
	padding: 15px;
	border-bottom: 1px solid #ccc;
	text-decoration: none;
	overflow: hidden;
}

.hpp-search-result-item:last-child {
	border-bottom: 0;
}

.hpp-search-result-item:hover,
.hpp-search-result-item.is-active {
	background: #f7f7f7;
}

.hpp-search-result-image {
	float: left;
	width: 60px;
	height: 60px;
	margin-right: 15px;
	overflow: hidden;
}

.hpp-search-result-image img {
	width: 60px;
	height: 60px;
	object-fit: cover;
	display: block;
}

.hpp-search-result-content {
	display: block;
	margin-left: 75px;
}

.hpp-search-result-head {
	display: flex;
	justify-content: space-between;
	align-items: baseline;
	gap: 10px;
}

/* ---- Round 17: force the dropdown's own type sizes to win on WooCommerce shop-type
   pages ----
   Every property below now carries !important. Root cause (see the round 17 comment
   further down this file for the full writeup): the Divi child theme's general
   stylesheet carries ".woocommerce-shop .et_pb_column span { font-size: 22px; }" —
   a generic rule aimed at ordinary shop-page text, which also matches every plain
   <span> our JS renders inside the dropdown (the whole widget lives inside a Divi
   .et_pb_column on the Buy Online page). That selector's specificity (two classes +
   a tag) beats our own single-class selectors below, even though ours load later, so
   the dropdown's title/price text was rendering at 22px instead of 12px — wrapping
   across multiple lines and colliding with the price. !important settles it outright,
   regardless of what other page-type-scoped span rules exist now or get added later. */
.hpp-search-result-title {
	font-size: 12px !important;
	font-weight: 700;
	line-height: 16px;
	color: #000;
}

.hpp-search-result-title mark {
	background: none;
	color: inherit;
	font-weight: 700;
	padding: 0;
}

.hpp-search-result-price {
	font-size: 12px !important;
	font-weight: 700;
	color: #000;
	white-space: nowrap;
}

/* ---- Round 19/20: the price's nested spans still rendered oversized
   Feedback (round 19): "the font of the price still looks too large to me and not
   the same as My Account results". Feedback (round 20, immediately after 19 shipped):
   the digits were fixed but the "$" currency symbol was still oversized.

   Root cause. wc_price() wraps the number in nested markup —
   <span class="woocommerce-Price-amount amount"><bdi><span
   class="woocommerce-Price-currencySymbol">$</span>180.00</bdi></span> — nested
   INSIDE .hpp-search-result-price, TWO levels deep for the currency symbol. Round 17
   put font-size:12px !important on the OUTER .hpp-search-result-price span — but that
   12px only reaches descendant text by INHERITANCE, and the same
   ".woocommerce-shop .et_pb_column span { font-size: 22px; }" rule from Round 17 also
   matches EVERY plain <span> at EVERY nesting depth directly, including
   .woocommerce-Price-amount (round 19) and, one level deeper still,
   .woocommerce-Price-currencySymbol (round 20) — both are spans in their own right. A
   rule written directly against an element always overrides a value the element would
   otherwise inherit from its parent, regardless of how strongly an ancestor's own value
   is set — the same "direct declaration beats inheritance" pattern hit repeatedly in
   this build (Round 13 h3 text-align, Round 17 title/price, Round 19 price amount, and
   now Round 20 currency symbol), because each fix only ever reached the specific span it
   named, not any further-nested span the 22px rule could also reach directly. Confirmed
   live via getComputedStyle after Round 19 shipped: .hpp-search-result-price and its
   child .woocommerce-Price-amount (and the bare digits, which inherit from it) all
   correctly computed 12px, but .woocommerce-Price-currencySymbol — the "$" span nested
   one level deeper again, inside the bdi — still computed 22px.
   Fix. Added .woocommerce-Price-currencySymbol to the same font-size:inherit !important
   rule as .woocommerce-Price-amount, so every nesting level of the price now explicitly
   inherits from .hpp-search-result-price's own 12px rather than relying on inheritance
   alone — closing off the "shop span" rule at every depth this markup can nest to,
   rather than patching one more specific selector each time WooCommerce's own price
   markup adds another wrapping span. */
.hpp-search-result-price .woocommerce-Price-amount {
	font-weight: 700;
	font-size: inherit !important;
}
.hpp-search-result-price .woocommerce-Price-currencySymbol {
	font-size: inherit !important;
}

.hpp-search-result-excerpt {
	display: block;
	margin-top: 4px;
	font-size: 12px !important;
	line-height: 18px;
	color: #313131;
}

.hpp-search-result-type {
	display: inline-block;
	margin-top: 3px;
	font-size: 10px !important;
	line-height: 1;
	text-transform: uppercase;
	letter-spacing: 0.04em;
	color: #999;
}

.hpp-search-no-results,
.hpp-search-view-all {
	display: block;
	padding: 15px;
	font-size: 12px;
	color: #666;
	text-align: center;
}

.hpp-search-view-all {
	font-weight: 600;
	text-decoration: none;
	border-top: 1px solid #ccc;
	color: #016087;
}

.hpp-search-view-all:hover {
	background: #f7f7f7;
}

@media ( max-width: 480px ) {
	.hpp-search {
		max-width: 100%;
	}
}

/* ---- sitewide search — pages/articles results section on the full results page ---- */

.hpp-sitewide-pages-results {
	width: 100%;
	max-width: 1080px;
	margin: 0 0 30px;
	box-sizing: border-box;
	font-family: Montserrat, Helvetica, Arial, Lucida, sans-serif;
}

.hpp-sitewide-pages-results__title {
	text-align: left;
	font-size: 1.3em;
	margin: 0 0 15px;
}

.hpp-sitewide-pages-results__list {
	display: grid;
	width: 100%;
	box-sizing: border-box;
	grid-template-columns: repeat( auto-fill, minmax( 240px, 1fr ) );
	gap: 15px;
}

.hpp-sitewide-pages-results__item {
	display: block;
	padding: 15px;
	border: 1px solid #e0e0e0;
	border-radius: 8px;
	text-decoration: none;
	color: inherit;
	box-sizing: border-box;
	transition: box-shadow 0.15s ease;
}

.hpp-sitewide-pages-results__item:hover {
	box-shadow: 0 2px 10px rgba( 0, 0, 0, 0.08 );
}

.hpp-sitewide-pages-results__item-title {
	display: block;
	font-weight: 700;
	font-size: 14px;
	color: #000;
}

.hpp-sitewide-pages-results__item-type {
	display: inline-block;
	margin-top: 3px;
	font-size: 10px;
	text-transform: uppercase;
	letter-spacing: 0.04em;
	color: #999;
}

.hpp-sitewide-pages-results__item-excerpt {
	display: block;
	margin-top: 6px;
	font-size: 12px;
	line-height: 1.5;
	color: #313131;
}

/* ---- widen the Search Results template's title row ----
   Divi's builder-generated CSS pins .et_pb_row_0_tb_body to width:90%;max-width:300px
   (it originally held only a slim search input). That same row now also carries our
   "Pages & articles" grid, so it needs real width — override with !important since the
   Divi rule ships with #et-boc-scoped specificity but no !important of its own.
   Round 13 update: raised max-width from 900px to 1080px to MATCH the product-results
   row below it (.et_pb_row_1_tb_body, a separate Divi row/section that Divi/WooCommerce
   centres at max-width:1080px — confirmed live via getBoundingClientRect on all three
   results-page entry points). Both rows are centred with the same auto margins inside a
   full-width section, so giving them the same max-width makes their left edges coincide
   — this is what actually left-justifies the title row's content (heading, "Go back"
   link, "Pages & articles" grid) flush with the product grid underneath, rather than
   leaving it centred in its own narrower box.
   Round 17 update: scoped to body.search-results — see the round 17 comment further
   down this file for why (this selector was colliding with an unrelated page). */
body.search-results .et_pb_row_0_tb_body.et_pb_row {
	width: 90% !important;
	max-width: 1080px !important;
}

/* ---- fix the Buy Online page search dropdown rendering behind the product grid ----
   The Buy Online landing page's search box lives inside a Divi Theme Builder column
   (.et_pb_column_3_tb_body) that Divi itself gives an explicit z-index:2. That creates
   a new stacking context, trapping our dropdown's z-index:99999 inside it — so no matter
   how high we set the dropdown's own z-index, the product-category rows further down the
   page (later in DOM order, part of a different stacking context) still paint on top of
   it. Raising the column's own z-index lifts its whole stacking context above those rows. */
.et_pb_column_3_tb_body {
	z-index: 999999 !important;
}

/* ---- Search Results page polish (260825 round 12) ----
   1. "Go back" link, top-left of the results header row, injected via JS (see the
      matching functions.php block) — reuses the same pink link colour as the existing
      "Go back to My Account" link on Partner Product pages, for visual consistency.
   2. Left-justify the "Default sorting" dropdown next to the result count. WooCommerce's
      own stylesheet floats .woocommerce-ordering to the right of the row with nothing
      else near it, which reads as disconnected/orphaned on a single-row results count.
      Scoped to body.search-results only (the WordPress-core body class on every one of
      our search results pages) so the plain Shop and category archive pages, which
      weren't part of this request, are left exactly as they were.
   Round 17 update: the row-positioning rule below was also scoped to body.search-results
   — see the round 17 comment further down this file. */
body.search-results .et_pb_row_0_tb_body.et_pb_row {
	position: relative;
}
.hpp-search-back-link {
	position: absolute;
	top: 0;
	left: 0;
	display: inline-flex;
	align-items: center;
	gap: 6px;
	font-size: 0.85rem;
	font-weight: 600;
	color: #d200be;
	text-decoration: none;
	line-height: 1.3;
}
.hpp-search-back-link:hover {
	color: #a5009a;
	text-decoration: underline;
}
@media ( max-width: 480px ) {
	.hpp-search-back-link {
		position: static;
		display: inline-flex;
		margin-bottom: 10px;
	}
}

body.search-results p.woocommerce-result-count {
	float: left !important;
	margin: 0 16px 20px 0 !important;
}
body.search-results form.woocommerce-ordering {
	float: left !important;
	clear: none !important;
	margin: 0 0 20px !important;
}

/* ---- Search Results page polish round 13 — left-justify + font-size consistency
   Feedback: "Can we left justify this?" (x4, on the Go back link, the "Search Results"
   heading, the "Pages & articles" heading, and its results grid) plus "font size is
   different to other results pages so make them all consistent."
   1+2 (Go back link, Pages & articles grid/heading) are handled above/below via the
   row's widened max-width and the two text-align changes on .hpp-sitewide-pages-results*
   already edited earlier in this file.
   3. The "Search Results" heading and its placeholder paragraph live inside a Divi text
      module that Divi itself centres via its own et_pb_text_align_center class (added
      in the Theme Builder, not by us) — override it back to left, scoped to just this
      template's title row so no other page's centred text modules are affected.
   4. Font-size fix: confirmed live via getComputedStyle that the "Search Results" H3
      renders at 34px on the My Account (partner) and header-search (sitewide) results
      pages, but only 28px on the Buy Online (product/category) results page. Root cause
      is Divi's own page-level "H3" typography setting for WooCommerce archive pages,
      which applies a bare `h3 { font-size: 28px }` rule that our heading — being a plain
      h3 with no distinguishing class — inherits on that page type only. Locked to the
      larger 34px value (already correct on 2 of the 3 entry points). First attempt
      used the selector ".et_pb_row_0_tb_body h3 { font-size: 34px !important; }" —
      still lost on the Buy Online page, because the Divi child theme's own general
      stylesheet carries ".woocommerce-shop h3 { font-size: 28px !important; }" (same
      0,0,1,1 specificity, also !important, but loaded later in the cascade, so it won
      the tie on source order). Fixed by raising our selector's specificity above that
      rule (adding the body.search-results class) so it wins outright regardless of
      load order, rather than relying on being the last matching rule in the cascade.
      Separately, the H3 itself still rendered centred even after the module-wrapper
      text-align:left fix below, because Divi's own Theme Builder CSS carries a rule
      written against the h3 element directly — ".et-db #et-boc .et-l .et_pb_text_0_tb_body
      h3 { text-align: center; }" — and a direct declaration on an element always wins
      over an inherited value from an ancestor, no matter how the ancestor's own
      text-align was set. Fixed by adding text-align:left !important directly on the h3
      selector too (folded into the same rule as the font-size fix below), which beats
      that ID-selector rule outright since it carries no !important of its own.
   Round 17 update: the module-wrapper text-align rule below was scoped to
   body.search-results — see the round 17 comment further down this file for why. */
body.search-results .et_pb_row_0_tb_body .et_pb_text_align_center {
	text-align: left !important;
}
body.search-results .et_pb_row_0_tb_body h3 {
	font-size: 34px !important;
	text-align: left !important;
}

/* ---- Search Results page polish round 14 — "Go back" link overlapping the heading
   Feedback: "weird formatting in results" on all three results-page entry points.
   Confirmed live via getBoundingClientRect that the "Go back" link and the "Search
   Results" H3 shared the exact same top/left coordinate (top:204.99px, left:616.36px
   on both) and visibly overlapped. This was invisible before Round 13: the back link
   is deliberately position:absolute (so inserting it via JS never disturbs the Theme
   Builder row's own layout — see the Round 12 comment above), anchored to the row's
   top-left corner, while the H3 was still centred — so the two never occupied the same
   space. Round 13 left-justified the H3 to the same left edge as the back link, which
   is what actually caused the collision (both now start at the same x AND y). Fixed by
   pushing the H3 down with margin-top, sized to clear the back link's own rendered
   height (~17.7px at 0.85rem/1.3 line-height) plus a clean gap, without touching the
   back link's own positioning or the Round 13 alignment fix. */
body.search-results .et_pb_row_0_tb_body h3 {
	margin-top: 30px !important;
}

/* ---- Search Results page polish round 15 — "Go back" link not clickable
   Feedback: "url for go back doesn't work on any of the results pages". Confirmed live
   via document.elementFromPoint() at the link's own on-screen centre that
   .et_pb_column_0_tb_body — the Theme Builder column wrapping the whole title row —
   was the element actually receiving the click, not the link sitting visibly on top of
   it. Root cause: that column carries Divi's own position:relative; z-index:2 (the same
   pattern already fixed once before, on the Buy Online page's search column — see the
   .et_pb_column_3_tb_body rule above). z-index:2 on the column establishes a stacking
   context with a POSITIVE stack level, which paints after (i.e. above) our link: the
   link is position:absolute with no z-index of its own, so it defaults to stack level 0
   and paints earlier/lower than any positioned sibling carrying an explicit positive
   z-index — even though the column has no visible background, so the link's own text
   still rendered on screen while an invisible layer above it silently absorbed every
   click. This was never noticed before Round 13, because the link previously sat
   outside the row's actual content width (before the row was widened to 1080px) and
   happened to fall over an area the column didn't extend into. Fixed by giving the
   link its own explicit z-index, comfortably above the column's 2, so it now wins the
   stacking-context paint order regardless of what the column carries. */
.hpp-search-back-link {
	z-index: 10;
}

/* ---- Search Results page polish round 17 — Buy Online page regressions from Round 13
   Feedback: on the Buy Online page itself (not a results page), the "Buy Online" title
   was off-centre, and the search dropdown's preview results looked wrong (oversized,
   wrapping) compared to the clean My Account preview.

   Root cause (both issues): Divi's Theme Builder generates row/column/module class
   names by POSITION WITHIN A TEMPLATE (row 0, column 0, text module 0, …), not by a
   globally-unique ID. The Buy Online page is itself built from a Theme Builder body
   template whose own title row happens to be its first row, first column, first text
   module too — so it carries the exact same generated classes
   (.et_pb_row_0_tb_body / .et_pb_column_0_tb_body / .et_pb_text_0_tb_body
   .et_pb_text_align_center) as the *unrelated* Search Results template's title row.
   Every Round 12/13 rule written against those bare classes — meant only for the
   Search Results template — was therefore ALSO landing on the Buy Online page's own
   "Buy Online" heading: forcing its wrapping row to the results page's 1080px width
   and forcibly left-aligning its centred title text. Confirmed live via
   getComputedStyle/getBoundingClientRect: on Buy Online, .et_pb_row_0_tb_body computed
   to exactly max-width:1080px, and its .et_pb_text_align_center title module computed
   text-align:left — i.e. our own override, not Divi's original centred design.
   Fixed by scoping every one of those bare .et_pb_row_0_tb_body-based selectors to
   body.search-results (the same guard already used elsewhere in this file), so they
   only ever match the actual Search Results template and can no longer collide with
   any other page's Theme Builder template that happens to reuse the same row/column/
   module index numbers.

   Root cause (dropdown preview). The Buy Online page's search widget lives inside a
   Divi .et_pb_column (see the .et_pb_column_3_tb_body z-index fix above), and that
   page's <body> carries WooCommerce's own "woocommerce-shop" class. The Divi child
   theme's general stylesheet carries a broad rule for that combination —
   ".woocommerce-shop .et_pb_column span { font-size: 22px; }" — written for ordinary
   shop-page text, but it also matches every plain <span> our JS renders inside the
   dropdown (result titles, prices, excerpts, type labels), because they're plain spans
   with no other qualifying wrapper. Its selector (two classes + a tag) out-specifies
   our own single-class selectors (e.g. .hpp-search-result-title), even though ours
   load later in the file — same "more specific beats more recent" pattern already hit
   twice before in this build (see the .woocommerce-shop h3 write-up in round 13).
   Confirmed live via getComputedStyle: .hpp-search-result-title and
   .hpp-search-result-price both computed to 22px instead of the intended 12px on Buy
   Online, which is what caused titles to wrap across 2–3 lines and collide with the
   price — the My Account preview isn't inside a "woocommerce-shop"-classed page, so it
   never hit this rule and always rendered correctly. Fixed with !important on the
   dropdown's own font-size declarations (above, in place, rather than duplicated here)
   so they win outright regardless of what other page-type-scoped span rules exist. */

/* ---- Search Results page polish round 18 — Buy Online preview still cramped after
   round 17's font-size fix
   Feedback: "heading is fixed but preview is still not right" — screenshot showed
   "Emotional Intelligence EIQ 360" and "Leadership Effectiveness 360" wrapping across
   3 tight lines and crowding the price, even with the correct 12px font-size now in
   place.

   Root cause. This was never a font-size problem — it's a WIDTH problem specific to
   this page. .hpp-search has "width:100%; max-width:360px", so it fills whatever
   column it sits in, UP TO 360px. On My Account that column is wide enough for the
   widget to reach its full 360px (confirmed live via getBoundingClientRect). On Buy
   Online the widget instead sits in a narrower Divi column and renders at only
   ~332px — and because .hpp-search-results (the dropdown) is positioned with
   "left:0; right:0" relative to that same box, it inherits the same shrunk width.
   With the image column (60px + 15px margin) and the item's own 15px+15px padding
   subtracted, the title+price row is left with only ~210px of content width on Buy
   Online vs ~253px on My Account — and since .hpp-search-result-head lays title and
   price out side-by-side (flex, space-between), a ~90px-wide price like "$250.00"
   eats into that, leaving the title as little as ~110px to work with. That's what
   squeezed longer titles into a cramped 3-line wrap, not the font-size.

   Fix. Rather than resize the visible input pill (which correctly matches its
   column everywhere else), let the dropdown PANEL be wider than the input that
   opens it — a common, unsurprising pattern for this kind of widget. Giving
   .hpp-search-results its own min-width restores it to the same ~360px the widget
   already reaches naturally on My Account, regardless of how narrow the column
   underneath happens to be; the browser resolves the left:0/right:0/min-width
   over-constraint by extending the right edge outward, so the panel simply grows
   past the input's own right edge rather than shifting left. Gated to non-mobile
   (matching the existing max-width:480px breakpoint elsewhere in this file) so the
   dropdown still just fills the screen width on phones, where a min-width would
   otherwise force horizontal overflow. */
@media ( min-width: 481px ) {
	.hpp-search-results {
		min-width: 360px;
	}
}