/*
 * Desktop-only header restructure (matches the min-width:769px gate in
 * header.js) — Storefront's own mobile header/handheld footer bar is left
 * untouched below that width.
 */
@media (min-width: 769px) {
	/* Original site-title + search row, hidden — content is relocated by
	   header.js, not duplicated, so nothing is lost, just repositioned.
	   Direct-child combinator between #masthead and .col-full is load-
	   bearing here: the nav row below is ALSO a .col-full inside
	   #masthead (just nested one level deeper, inside
	   .storefront-primary-navigation), so a plain descendant selector
	   would re-hide .site-search again after JS moves it there. */
	#masthead > .col-full > .site-branding,
	#masthead > .col-full > .site-search {
		display: none;
	}

	/* Storefront's .site-header padding-top (1.618em) was sized for the
	   original two-row header (site-title+search row above the nav row).
	   With that row hidden above, the padding was left behind as empty
	   space above the now-single nav row. #masthead.site-header (id+class)
	   outranks Storefront's own bare ".site-header" rule, so this wins
	   without !important. */
	#masthead.site-header {
		padding-top: 0;
	}

	/* Storefront's .col-full is a centered max-width column (matches the
	   rest of the page's content width) — fine for a normal content row,
	   but it left the logo sitting ~484px from the true left edge on a
	   wide screen instead of at the far left of the (now full-bleed,
	   position:fixed) header bar. max-width:none + margin:0, scoped to
	   this row only, makes it span the bar's full width so flex-start
	   content (the logo) actually lands at the edge. */
	.storefront-primary-navigation .col-full {
		display: flex;
		align-items: center;
		flex-wrap: nowrap;
		max-width: none;
		margin: 0;
	}

	/* Storefront's nav/cart use float + fixed percentage widths (old
	   float-based layout); floats are ignored once the parent is flex, but
	   the percentage widths still apply and would otherwise leave no room
	   for the logo/search now sharing this row. */
	.storefront-primary-navigation .main-navigation,
	.storefront-primary-navigation .site-header-cart {
		width: auto;
		flex: 0 0 auto;
		margin-right: 0;
	}

	/* Explicit flex order across all four items in this row: logo and nav
	   stay put on the left; search and cart form the right-hand cluster,
	   with search now visually BEFORE the cart icon (order, not DOM order
	   — header.js still appends search after the cart in the markup). */
	.storefront-primary-navigation .main-navigation {
		order: 2;
	}

	.storefront-primary-navigation .site-header-cart {
		order: 4;
	}

	.davimo-header-logo {
		order: 1;
		flex: 0 0 auto;
		margin-right: 2rem;
		font-size: 2.5rem; /* doubled from 1.25rem */
		font-weight: 800;
		letter-spacing: 0.06em;
		color: var(--davimo-green);
		text-decoration: none;
	}

	/* width:auto here doesn't reliably shrink to the field's actual width
	   (same non-shrinking behavior documented above for .cart-contents/
	   .site-header-cart — a block-level width:auto element nested inside
	   a flex item, several attempts at display:flex/inline-flex included,
	   still measured its old ~231px box, some rule elsewhere kept
	   resolving it to flex regardless). Sidestepping the fight entirely: a
	   DEFINITE pixel width here, matching the field's own width below
	   (nothing else in this wrapper — the visually-hidden 1x1 submit
	   button aside — takes horizontal space), makes every block
	   descendant's default width:auto resolve to "100% of a 180px box"
	   deterministically, no shrink-to-fit ambiguity involved. Keep this in
	   sync with .search-field's width below if either changes. */
	/* #masthead-prefixed: Storefront's style.css has
	   ".woocommerce-active .site-header .site-search { margin-right: 0 }"
	   — 3 classes vs. this rule's 2, so it silently won the margin-right
	   fight (order/display/width above were untouched by it, only this
	   one property lost) and the search-to-cart gap stayed 0 regardless
	   of what was set here. #masthead adds an ID, beating any number of
	   classes outright. */
	#masthead .davimo-header-search.site-search {
		order: 3;
		display: block;
		width: 180px !important; /* reverted — 140px was too narrow */
		flex: 0 0 auto;
		margin-left: auto; /* pushes the search+cart cluster (order 3 & 4) right */
		margin-right: 18px; /* real visible gap to the cart icon, was 0 */
		margin-bottom: 0;
	}

	.davimo-header-search .widget_product_search {
		margin: 0;
	}

	/* Narrower, fully-rounded search field (was a plain 231px square-
	   cornered box reusing Storefront's default input styling).
	   !important: WooCommerce's own compound selector
	   (".widget_product_search form:not(.wp-block-search)
	   input[type=search] { width: 100% }") outranks a 2-class selector
	   here on raw specificity, and 100% just re-fills whatever width the
	   parent form ends up with — needs to lose outright, not just tie. */
	.davimo-header-search .search-field {
		width: 180px !important; /* reverted to the original reduced width */
		border-radius: 999px;
	}

	/* Cart link keeps its existing Font Awesome basket icon
	   (.cart-contents::after, from Storefront's own markup) — only the
	   price amount and item-count text next to it are removed. */
	.site-header-cart .cart-contents .woocommerce-Price-amount,
	.site-header-cart .cart-contents .count {
		display: none;
	}

	/* Cart link's width was previously driven by its price/count text.
	   Storefront's woocommerce.css has ".site-header-cart .cart-contents
	   { display:block; width:auto }" — an exact selector tie with a plain
	   copy of that selector here, and woocommerce.css's <link> loads AFTER
	   header.css's, so the tie went to Storefront. #masthead prefixed onto
	   our copy outranks it outright (extra ID) rather than relying on load
	   order. Switching block -> inline-flex makes the link size to just
	   its visible content (the icon) once it actually wins the cascade. */
	#masthead .site-header-cart .cart-contents {
		display: inline-flex;
		align-items: center;
		width: auto;
	}

	/* The icon glyph itself (.cart-contents::after) wasn't centered
	   within its own box, even though the box IS correctly centered in
	   the link above it. Storefront's icons.css sets height:1em but
	   line-height:1.618 on this pseudo-element — in its original
	   float:right/inline-block design that oversized line-height was
	   intentional breathing room, but our inline-flex change above
	   blockifies this pseudo (a flex item), so its line box (25.89px,
	   from line-height:1.618 × 16px font-size) starts at the box's own
	   top edge and overflows downward past the declared 16px (1em)
	   height — the glyph's visual center ends up ~5px (half the 9.9px
	   difference) below the box's geometric center that align-items:
	   center on the parent actually centers. Resetting line-height to 1
	   makes the line box match the declared height exactly, so the glyph
	   centers on the same point the flex centering already uses. */
	#masthead .site-header-cart .cart-contents::after {
		line-height: 1;
	}

	/* The <a> shrinking to the icon's width doesn't shrink its <li>/<ul>
	   ancestors along with it — same block-in-flex-item non-shrinking
	   behavior as above, one level up. Left unfixed, the icon sits at the
	   left edge of a ~231px invisible box (the old text+icon width) that
	   overflows past the row's own right edge — a dead click zone, and on
	   narrower viewports an actual overflow/scrollbar risk. */
	#masthead .site-header-cart {
		display: inline-flex;
		align-items: center;
		width: auto;
	}

	/* #masthead pinned via plain CSS position:sticky — no JS, no
	   transition, no hide/show class, just permanently stuck once
	   scrolled to. Two prior approaches here (sticky with an unfixed
	   body-overflow bug, then fixed+JS scroll-direction-tracking with
	   translateY hide/show) both regressed; this replaces both entirely
	   rather than leaving either dormant. Stacks directly below the
	   announcement bar: top offset is that bar's own height (2.3rem —
	   0.5rem padding × 2 + a ~1.29rem text line at this font-size, a
	   literal value now, not JS-measured, since there's no JS left to
	   measure with) plus the WordPress admin bar's real height on the
	   rare logged-in view (selected via the html.admin-bar class WP core
	   itself adds — no JS needed for that either). position:sticky's
	   containing block is the nearest ancestor that's a scroll container
	   per spec, which used to be <body> here (Storefront's own
	   body{overflow-x:hidden} auto-upgrades overflow-y to "auto" too,
	   per the CSS Overflow spec's visible+non-visible-axis quirk — see
	   the body{overflow:clip} override below, which is what actually
	   makes position:sticky engage against the true viewport instead). */
	#masthead.site-header {
		position: sticky;
		top: 2.3rem;
		z-index: 9998;
		background: #fff;
	}

	html.admin-bar #masthead.site-header {
		top: calc(2.3rem + 32px);
	}
}

/* overflow-x ONLY, not the "overflow" shorthand — the shorthand used
   here previously set BOTH overflow-x and overflow-y to the same value,
   which silently clipped overflow-y too and disabled vertical scrolling
   for the ENTIRE PAGE (overflow:clip, unlike hidden/auto, genuinely
   disallows scrolling on the axis it's applied to — a real, site-
   breaking regression, confirmed and reverted). overflow-y is
   intentionally left untouched.
   This was originally added on the theory that Storefront's own
   body{overflow-x:hidden} makes <body> a sticky-positioning containing
   block instead of the true viewport, breaking position:sticky
   elsewhere on the site. Kept (harmless — same visual clipping as
   Storefront's own rule) since it matches what was asked, but empirical
   testing during this fix found position:sticky works correctly even
   with body forced back to Storefront's untouched overflow-x:hidden/
   overflow-y:auto, and this rule doesn't even win the specificity tie
   against Storefront's own (computed overflow-x still reads "hidden",
   not "clip") — so whatever actually made sticky work, it isn't this
   rule. Not removed pre-emptively, since it costs nothing and confirming
   what to strip out is a separate, non-urgent task from the scroll fix
   this comment is attached to. */
body {
	overflow-x: clip;
}

/* #page (the theme's outer wrapper, "#page.hfeed.site") carries
   Storefront's own .site{overflow-x:hidden} rule — under the CSS Overflow
   spec, setting overflow-x to anything other than visible/clip forces the
   other axis to compute as "auto" if it was visible, so #page silently
   becomes a real scroll container (confirmed live: overflow-y read "auto"
   here despite no explicit rule setting it) even though it never actually
   scrolls itself. That promotes #page to the nearest scrolling ancestor
   for position:sticky's purposes instead of the true viewport, which
   stops #masthead/.davimo-announcement-bar from sticking at all — measured
   live on the shop page: #masthead's top tracked raw scroll position
   (105.5px at scroll 0, 5.5px at scroll 100, -194.5px at scroll 300 —
   i.e. never clamping to its own `top` value) while the PDP, unaffected,
   correctly held at a constant 36.79px throughout.
   This was previously only fixed with `body.single-product #page{overflow:
   visible!important}` in product-page.css — silently leaving every other
   page, including the shop page, broken. Generalized here (header.css,
   loaded site-wide) instead of widening that page-specific selector, since
   the sticky header/announcement bar apply everywhere, not just the PDP. */
#page {
	overflow: visible !important;
}