/*
 * BVX Shop Chrome - sitewide customer-facing header/footer branding.
 * Loaded on every frontend page, not gated to My Account.
 */

/* 3) Cart button: remove the lime background square. The count badge
   (.wc-block-mini-cart__quantity-badge) is a separate child element and
   is not referenced here, so it is left completely untouched. Applies
   sitewide/all breakpoints - unchanged from v1.0.0. */
.wc-block-mini-cart__button {
	background-color: transparent !important;
}

/* 4) Logo sizing - matches the main BVX frontend .nav-logo dimensions
   (confirmed via Safari: width 56px, height 28px). Applies sitewide/all
   breakpoints - unchanged from v1.0.0. */
.bvx-shop-chrome-logo-img {
	width: 56px;
	height: 28px;
	object-fit: contain;
	display: block;
}

/* 5) & 6) Footer: remove the "trans-menu" heading and its adjacent empty
   nav/hamburger, scoped to the first column of the footer row only, so
   the header's own nav (outside <footer>) and the other footer columns'
   headings are untouched. Confirmed via Safari: the outer wrapper is a
   real semantic <footer> element, and the raw classes alone
   (h3.wp-block-heading.hostinger-locale: 4 matches;
   nav.hostinger-ai-site-navigation.wp-block-navigation: 2 matches) are
   not unique enough on their own. Applies sitewide/all breakpoints -
   unchanged from v1.0.0. */
footer .wp-block-columns > .wp-block-column:first-child > h3.wp-block-heading {
	display: none !important;
}

footer .wp-block-columns > .wp-block-column:first-child > nav.wp-block-navigation {
	display: none !important;
}

/*
 * v1.0.10 addition - desktop-only My Account header navigation.
 * Converts .hostinger-ai-menu-wrapper's confirmed 2-column grid (265px
 * logo / 795px account+cart, gap:40px unchanged) to 3 columns, and
 * styles the new center <nav> injected by bvx_shop_chrome_filter_output().
 * Header height/padding/background match the confirmed nav#navbar values
 * from the main wearbvx.com frontend exactly. Nav link typography,
 * padding, and active-state color are the exact confirmed .nav-links
 * values from that same frontend header. Scoped to body.woocommerce-account
 * and min-width:769px throughout - mobile header (v1.0.1-v1.0.9) and
 * every non-account page are completely unaffected. Account/cart icon
 * geometry and the cart badge are untouched - only the outer header's
 * own box (height/padding/background) and the grid's column template
 * are changed on this element.
 */

/*
 * v1.0.12 - regression fix. bvx_shop_chrome_render_account_nav() has no
 * way to know viewport width server-side, so the <nav> it injects was
 * present in the markup on mobile too - only its layout was previously
 * scoped to desktop (min-width:769px), leaving it to render unstyled at
 * mobile widths (block-level, six default-styled links stacking/wrapping
 * inline), which was expanding the mobile header and sitting above the
 * original, still-correct mobile Woo account sidebar. This explicitly
 * hides it at max-width:768px so mobile returns to exactly its pre-
 * v1.0.10 appearance. The desktop rule below is unchanged - this is a
 * mobile-only addition, not a replacement.
 */
@media (max-width: 768px) {
	body.woocommerce-account .bvx-account-header-nav {
		display: none !important;
	}
}

@media (min-width: 769px) {

	body.woocommerce-account .hostinger-ai-menu {
		height: 64px;
		padding-left: 32px;
		padding-right: 32px;
	}

	/* v1.0.11 - the theme's own .has-color-1-background-color utility
	   class (tan, rgb(225,215,198)) was winning over the plain-class
	   background rule this replaces. Confirmed via Web Inspector:
	   .hostinger-ai-menu itself carries this class, and its children are
	   transparent, so this is the exact element painting the tan.
	   Matching that theme class in the selector (raising specificity to
	   two classes) plus !important reliably wins against it. */
	body.woocommerce-account div.wp-block-group.hostinger-ai-menu.has-color-1-background-color {
		background-color: rgba(255, 255, 255, 0.95) !important;
	}

	/* v1.0.11 - confirmed via Web Inspector: the 1100px cage was an
	   explicit width/max-width directly on this element (with
	   margin-left/right:282px centering it within the real 1728px-wide
	   header), not inherited from any ancestor - .hostinger-ai-menu,
	   header.site-header, and .wp-site-blocks all confirmed max-width:none
	   at their own true width. Removing it here is sufficient on its own.
	   grid-template-columns switches from the v1.0.10 fixed-265px/1fr/auto
	   split to two equal 1fr tracks flanking an auto center track: the
	   center track now sizes exactly to the nav's own content width and
	   sits genuinely centered regardless of the logo/account-cart's
	   actual rendered widths, rather than being squeezed into whatever
	   was left over next to a fixed 265px column - this is what was
	   compressing PAYMENT METHODS/ACCOUNT DETAILS onto two lines. */
	body.woocommerce-account .hostinger-ai-menu-wrapper {
		width: 100%;
		max-width: none;
		grid-template-columns: 1fr auto 1fr;
	}

	body.woocommerce-account .hostinger-ai-menu-wrapper > :first-child {
		justify-self: start;
	}

	body.woocommerce-account .hostinger-ai-site-navigation-wrapper {
		justify-self: end;
	}

	body.woocommerce-account .bvx-account-header-nav {
		display: flex;
		align-items: center;
		justify-content: center;
		gap: 2px;
	}

	body.woocommerce-account .bvx-account-header-nav-link {
		font-family: "JetBrains Mono", monospace;
		font-size: 9.6px;
		font-weight: 300;
		letter-spacing: 1.92px;
		text-transform: uppercase;
		color: #0A0A0A;
		opacity: 0.5;
		text-decoration: none;
		padding: 8px 12px;
		margin: 0;
		line-height: normal;
		border-bottom: 1px solid transparent;
		white-space: nowrap;
	}

	body.woocommerce-account .bvx-account-header-nav-link.is-active {
		opacity: 1;
		border-bottom-color: #BCFF00;
	}
}

/*
 * v1.0.9 addition - footer newsletter field styling (trans-newsletter),
 * mobile + desktop. Confirmed via Safari: the form is
 * form#ai-theme-footer-form.hostinger-reach-block-subscription-form,
 * with the email input at
 * input#ai-theme-footer-form-email inside
 * .hostinger-reach-block-form-field, and its label a sibling <label>. No
 * placeholder attribute exists on the input, so no ::placeholder rule is
 * included. Also confirmed: bvx-account-styling.css's generic WooCommerce
 * input rule (.woocommerce-account input[type="email"] { ... }) was
 * winning against this form's default styling wherever both plugins are
 * loaded together (e.g. on My Account, where the footer is still
 * present), which is why !important is used here to reliably win against
 * that unrelated plugin's generic input rule without modifying it.
 * Scoped strictly to id/#ai-theme-footer-form so no other form on the
 * site (account forms, checkout, login/register) is affected. The
 * Subscribe button (.hostinger-reach-block-submit) is not referenced
 * anywhere in this rule set and is completely unchanged. Background is
 * left untouched (already transparent/dark) - only text/border color are
 * set. Applies at all breakpoints - no media query needed since the
 * confirmed markup and desired styling are identical on mobile and
 * desktop.
 */
footer.site-footer #ai-theme-footer-form label {
	color: #ffffff !important;
}

footer.site-footer #ai-theme-footer-form input#ai-theme-footer-form-email {
	color: #ffffff !important;
	border-color: #ffffff !important;
	background: transparent !important;
}

/*
 * v1.0.8 addition - mobile-only: reduce the footer wrapper's top padding.
 * Confirmed via Safari: the remaining blank space above trans-contacts
 * was not the (already-collapsed, v1.0.7) empty first column or the
 * .wp-block-columns row-gap (both confirmed unrelated - row-gap stays at
 * its default 40px, untouched) - it's this wrapper's own
 * padding-top: 36px (from var(--wp--preset--spacing--60)). Only
 * padding-top is touched; padding-bottom (36px) and the left/right
 * padding (24px) are left exactly as they are, since only the top gap
 * was reported as excessive. Scoped to the confirmed exact element
 * (footer.site-footer > .wp-block-group.has-color-2-background-color)
 * rather than a generic .wp-block-group selector, so no other page's
 * wp-block-group elements are affected. Desktop is untouched - this
 * only exists inside this mobile media query.
 */
@media (max-width: 768px) {
	footer.site-footer > .wp-block-group.has-color-2-background-color {
		padding-top: 18px !important;
	}
}

/*
 * v1.0.7 addition - mobile-only: collapse the entire first footer column
 * (not just its heading/nav, hidden above), since the empty column still
 * reserves its own padding/margin and stacked-row gap once the footer's
 * columns switch to a vertical stack at this width - confirmed via
 * screenshot as the source of the blank space above trans-contacts.
 * display: none removes it from layout entirely, so trans-contacts
 * becomes the first visible footer section. Reuses the exact selector
 * already proven unique to this column. Desktop is deliberately left
 * untouched - the empty column still preserves the current horizontal
 * layout/balance of trans-contacts/socials and trans-newsletter there,
 * so this rule only exists inside this mobile media query. */
@media (max-width: 768px) {
	footer .wp-block-columns > .wp-block-column:first-child {
		display: none !important;
	}
}

/*
 * v1.0.1 addition - account/cart icon visual replacement + header-right
 * spacing. Scoped to max-width: 768px only: every dimension and spacing
 * value below (38x38 controls, 18x18 icons, 10px gap) was measured from
 * the 393px mobile BVX header via Safari. Desktop/tablet have not been
 * verified against the same target, so none of this applies above the
 * mobile breakpoint - desktop keeps WooCommerce's default account/cart
 * appearance (minus the sitewide cart-background removal above) until
 * that is separately confirmed.
 */
@media (max-width: 768px) {

	/* ---- Cart control ---- */

	/* Resize to 38x38 matching BVX's .nav-right sizing. box-sizing:
	   border-box means this is the FINAL rendered size regardless of any
	   padding the theme already applies internally. The BVX cart/bag
	   outline icon is applied directly as this element's own
	   background-image (v1.0.3) rather than on a ::before pseudo-element
	   (v1.0.1/v1.0.2), since the pseudo-element approach - both the
	   mask-image and background-image variants - rendered invisible on
	   iPhone Safari for reasons that didn't reproduce for the plain-div
	   account icon. Applying it to the button's own, real, stable
	   element removes that pseudo-element variable entirely. The
	   sitewide background: none !important rule above was narrowed to
	   background-color only, since that shorthand also zeroes
	   background-image with !important, which would have silently
	   overridden this same property on this same element. Icon is fixed
	   black, matching the confirmed BVX SVG's own stroke color on the
	   cream header. */
	.wc-block-mini-cart__button {
		width: 38px !important;
		height: 38px !important;
		box-sizing: border-box !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		position: relative !important;
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M6 2L3 6v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6L18 2z'%3E%3C/path%3E%3Cline x1='3' y1='6' x2='21' y2='6'%3E%3C/line%3E%3Cpath d='M16 10a4 4 0 0 1-8 0'%3E%3C/path%3E%3C/svg%3E") !important;
		background-repeat: no-repeat !important;
		background-position: center !important;
		background-size: 18px 18px !important;
	}

	/* Hide only the confirmed WooCommerce bag icon. */
	.wc-block-mini-cart__icon {
		display: none !important;
	}

	/* Reproduce the main BVX header's #navBadge.cart-badge-num geometry
	   exactly, replacing WooCommerce's own left:100%/margin-left:-44%/
	   transform positioning system entirely. Confirmed via Safari: the
	   visible count circle is a distinct inner element
	   (.wc-block-mini-cart__badge) nested inside the outer
	   .wc-block-mini-cart__quantity-badge wrapper, and the OUTER wrapper
	   (not the inner badge) is the element with position: relative -
	   confirmed computed as width:0, height:0, no top/right set. v1.0.4
	   put top:-5px/right:-5px directly on the inner badge, which
	   positioned it relative to that wrapper's arbitrary flow position
	   (roughly centered in the flex button), not relative to the button's
	   actual corner - visibly wrong placement.

	   Fix (v1.0.5): positioning responsibility moves to the outer
	   wrapper, anchored to the button's top-right corner exactly as the
	   main BVX badge is anchored to its own container. Since the wrapper
	   is 0x0, its own top-right-ish corner IS that anchor point. The
	   inner badge then only needs top:0; right:0 - inheriting that
	   already-correct point as its own origin - plus size/shape/color.
	   The badge's count logic/text content is untouched throughout. */
	.wc-block-mini-cart__quantity-badge {
		position: absolute !important;
		top: -5px !important;
		right: -5px !important;
		left: auto !important;
		width: 0 !important;
		height: 0 !important;
		margin: 0 !important;
		transform: none !important;
	}

	.wc-block-mini-cart__badge {
		width: 16px !important;
		height: 16px !important;
		min-width: 16px !important;
		padding: 0 !important;
		border-radius: 50% !important;
		background-color: #BCFF00 !important;
		color: #0A0A0A !important;
		position: absolute !important;
		top: 0 !important;
		right: 0 !important;
		left: auto !important;
		margin-left: 0 !important;
		transform: none !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
	}

	/* ---- Account control ---- */

	.wp-block-woocommerce-customer-account {
		width: 38px !important;
		height: 38px !important;
		box-sizing: border-box !important;
	}

	.wc-block-customer-account__account-link {
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		width: 100% !important;
		height: 100% !important;
	}

	/* Hide the logged-in Gravatar and the logged-out default icon - both
	   confirmed child elements inside the account link. */
	.wc-block-customer-account__avatar,
	.wc-block-customer-account__account-icon,
	.wc-block-customer-account__visual > * {
		display: none !important;
	}

	/* The BVX account outline icon, same mask technique. */
	.wc-block-customer-account__visual {
		display: block !important;
		width: 18px !important;
		height: 18px !important;
		background-color: currentColor;
		-webkit-mask-repeat: no-repeat;
		mask-repeat: no-repeat;
		-webkit-mask-position: center;
		mask-position: center;
		-webkit-mask-size: contain;
		mask-size: contain;
		-webkit-mask-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Ccircle cx='12' cy='8' r='4'%3E%3C/circle%3E%3Cpath d='M4 21c0-4.4 3.6-8 8-8s8 3.6 8 8'%3E%3C/path%3E%3C/svg%3E");
		mask-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Ccircle cx='12' cy='8' r='4'%3E%3C/circle%3E%3Cpath d='M4 21c0-4.4 3.6-8 8-8s8 3.6 8 8'%3E%3C/path%3E%3C/svg%3E");
	}

	/* ---- Header-right spacing ----
	   .hostinger-ai-site-navigation-wrapper holds three siblings: the nav
	   toggle, the account control, and the cart control. Setting
	   gap: 10px makes account<->cart exactly 10px (matching BVX's
	   .nav-right), but would also shrink nav<->account from its current
	   ~40px. The margin-right on the nav restores that gap: 10px (from
	   the wrapper's own gap) + margin-right: 30px = 40px, unchanged. On
	   My Account pages, where the nav is already hidden by BVX Account
	   Styling, only the account<->cart 10px gap is visible, which is the
	   desired end state. */
	.hostinger-ai-site-navigation-wrapper {
		gap: 10px !important;
	}

	.hostinger-ai-site-navigation-wrapper > nav.wp-block-navigation {
		margin-right: 30px !important;
	}

}

/*
 * v1.0.6 addition - desktop BVX header chrome. Mirrors the same
 * mechanisms already confirmed working at mobile (max-width: 768px)
 * above, applied to the separately-confirmed desktop starting values,
 * which differ from mobile's: desktop's Woo cart button was confirmed at
 * ~80.3x48.3px with ~32px horizontal / ~16px vertical padding baked in
 * (mobile's was already close to square), and the desktop badge was
 * confirmed at ~14x14 with the same default left/margin/transform
 * positioning system. Scoped to min-width: 769px - the exact inverse of
 * the mobile block's max-width: 768px - so the two can never overlap and
 * this cannot affect the now-working mobile state in any way.
 *
 * Header-right spacing: confirmed via Safari that
 * .hostinger-ai-site-navigation-wrapper holds the same three siblings at
 * desktop as at mobile - nav.wp-block-navigation,
 * .wp-block-woocommerce-customer-account, and
 * .wc-block-mini-cart.wp-block-woocommerce-mini-cart - with the wrapper's
 * own gap confirmed at 40px (matching mobile's original default). The
 * same gap:10px + margin-right:30px-on-the-nav compensation used at
 * mobile is reused here on that same confirmed basis.
 */
@media (min-width: 769px) {

	/* ---- Cart control ---- */

	.wc-block-mini-cart__button {
		width: 38px !important;
		height: 38px !important;
		padding: 0 !important;
		box-sizing: border-box !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		position: relative !important;
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M6 2L3 6v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6L18 2z'%3E%3C/path%3E%3Cline x1='3' y1='6' x2='21' y2='6'%3E%3C/line%3E%3Cpath d='M16 10a4 4 0 0 1-8 0'%3E%3C/path%3E%3C/svg%3E") !important;
		background-repeat: no-repeat !important;
		background-position: center !important;
		background-size: 18px 18px !important;
	}

	.wc-block-mini-cart__icon {
		display: none !important;
	}

	/* Cart badge - identical outer/inner split as the mobile v1.0.5 fix. */
	.wc-block-mini-cart__quantity-badge {
		position: absolute !important;
		top: -5px !important;
		right: -5px !important;
		left: auto !important;
		width: 0 !important;
		height: 0 !important;
		margin: 0 !important;
		transform: none !important;
	}

	.wc-block-mini-cart__badge {
		width: 16px !important;
		height: 16px !important;
		min-width: 16px !important;
		padding: 0 !important;
		border-radius: 50% !important;
		background-color: #BCFF00 !important;
		color: #0A0A0A !important;
		position: absolute !important;
		top: 0 !important;
		right: 0 !important;
		left: auto !important;
		margin-left: 0 !important;
		transform: none !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
	}

	/* ---- Account control ---- */

	.wp-block-woocommerce-customer-account {
		width: 38px !important;
		height: 38px !important;
		box-sizing: border-box !important;
	}

	.wc-block-customer-account__account-link {
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		width: 100% !important;
		height: 100% !important;
	}

	.wc-block-customer-account__avatar,
	.wc-block-customer-account__account-icon,
	.wc-block-customer-account__visual > * {
		display: none !important;
	}

	.wc-block-customer-account__visual {
		display: block !important;
		width: 18px !important;
		height: 18px !important;
		background-color: currentColor;
		-webkit-mask-repeat: no-repeat;
		mask-repeat: no-repeat;
		-webkit-mask-position: center;
		mask-position: center;
		-webkit-mask-size: contain;
		mask-size: contain;
		-webkit-mask-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Ccircle cx='12' cy='8' r='4'%3E%3C/circle%3E%3Cpath d='M4 21c0-4.4 3.6-8 8-8s8 3.6 8 8'%3E%3C/path%3E%3C/svg%3E");
		mask-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Ccircle cx='12' cy='8' r='4'%3E%3C/circle%3E%3Cpath d='M4 21c0-4.4 3.6-8 8-8s8 3.6 8 8'%3E%3C/path%3E%3C/svg%3E");
	}

	/* ---- Header-right spacing ---- */

	.hostinger-ai-site-navigation-wrapper {
		gap: 10px !important;
	}

	.hostinger-ai-site-navigation-wrapper > nav.wp-block-navigation {
		margin-right: 30px !important;
	}

}

/*
 * v1.0.13 addition - desktop-only footer redesign (brand/SHOP/INFO row,
 * newsletter copy, updated bottom strip). See the matching v1.0.13 PHP
 * changelog entry for the confirmed structural data this is built from,
 * and for how each new PHP-inserted element is gated on a confirmed
 * single-match anchor before it can appear at all.
 *
 * Mobile (max-width: 768px) receives ZERO rules here. Every new element
 * defaults to display:none below (not a max-width query, so there is no
 * unstyled-flash window before this stylesheet loads - the same class of
 * bug fixed in v1.0.12 for the account nav), and every hide-the-original
 * rule lives only inside the min-width:769px block, so nothing here can
 * ever affect mobile output. Every original element touched below (col 1,
 * the original newsletter heading, the original bottom block) keeps its
 * exact original markup/text - only a display:none at this breakpoint, or
 * (newsletter heading only) one appended class token used purely as a CSS
 * hook.
 *
 * v1.0.14 refines the newsletter-specific rules inside this same block
 * (section padding/border, eyebrow/title/description spacing, and the
 * form/input/button geometry) to the confirmed live measurements - each
 * such rule is individually marked "v1.0.14" below. The footer grid
 * architecture, the 1320px brand/SHOP/INFO row and bottom-strip fix
 * further down, and everything else in this block are unchanged from
 * v1.0.13.
 */
.bvx-footer-content-row,
.bvx-footer-bottom,
.bvx-newsletter-eyebrow,
.bvx-newsletter-heading,
.bvx-newsletter-desc {
	display: none;
}

@media (min-width: 769px) {

	/* Outer wrapper becomes the grid AND the full-width #F7F7F7 desktop
	   background, overriding the theme's .has-color-2-background-color
	   utility class (same specificity technique proven in v1.0.11 against
	   .has-color-1-background-color). The content track is capped at
	   1320px and centered via min(), wrapped in minmax(0, ...) so the
	   track can also shrink below that cap with no overflow risk; the two
	   minmax(16px, 1fr) gutter tracks absorb any remaining space and never
	   go below 16px. Gutters are painted only by this rule's background,
	   so no dark strip can remain visible at any confirmed breakpoint -
	   verified in a real Chromium render at 769/1024/1440/1728px with no
	   horizontal overflow and the expected computed background at each
	   width, plus confirmed-untouched output at 390px mobile. */
	footer.site-footer > .wp-block-group.has-color-2-background-color {
		display: grid;
		grid-template-columns: minmax(16px, 1fr) minmax(0, min(1320px, calc(100% - 32px))) minmax(16px, 1fr);
		row-gap: 0;
		padding: 0 !important;
		background: #F7F7F7 !important;
	}

	/* col 0 - already hidden sitewide via the v1.0.0 heading/nav rules
	   above; explicitly removed from grid flow too. */
	footer.site-footer .wp-block-columns.alignwide > .wp-block-column:first-child {
		display: none !important;
	}

	/* col 1 - original contacts/socials/phone. UNTOUCHED markup, hidden
	   ONLY at this breakpoint - never affects mobile. Its real desktop
	   content is .bvx-footer-brand below. */
	footer.site-footer .wp-block-columns.alignwide > .wp-block-column:nth-child(2) {
		display: none !important;
	}

	/* col 2 - newsletter. UNTOUCHED markup/DOM position; Hostinger Reach
	   form and its internal markup/hidden fields/handlers are completely
	   unaffected by anything in this file. Unwraps .wp-block-columns so
	   col 2 becomes a direct grid child, spanning the full grid width -
	   the container itself is confirmed full viewport width, so this
	   reaches true edges with no breakout pseudo-element hack needed. */
	footer.site-footer .wp-block-columns.alignwide {
		display: contents;
	}
	/* v1.0.14: added border-top (rgba(0,0,0,.1)) to the confirmed live
	   frontend measurement - padding was already correct in v1.0.13 and
	   is unchanged. */
	footer.site-footer .wp-block-columns.alignwide > .wp-block-column.has-light-color {
		grid-column: 1 / -1;
		background: #FAF7F2;
		padding: 88px 24px;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
		text-align: center;
	}
	/* v1.0.14: max-width 600px/margin 24px-auto-0 (v1.0.13's initial
	   values) refined to the confirmed 460px/0-auto. Form wrapper is
	   width/centering only - its element identity, the Hostinger Reach
	   <form> inside it, every hidden field, the submit handler,
	   validation and .reach-subscription-message markup are completely
	   untouched by this file, in this version or v1.0.13 - see the rules
	   further below, which only ever set layout/typography CSS
	   properties on the confirmed existing selectors, never structure. */
	footer.site-footer .hostinger-reach-block-subscription-form-wrapper {
		max-width: 460px;
		margin: 0 auto;
	}

	/* Original newsletter heading - text/tag/original class value
	   untouched (see the PHP changelog for exactly what the insertion
	   does and does not modify); just hidden here. Unchanged from
	   v1.0.13. */
	.bvx-newsletter-original {
		display: none !important;
	}
	/* Eyebrow/heading/description - re-enabled from the sitewide
	   display:none default above (unchanged from v1.0.13). Spacing
	   refined in v1.0.14 to the confirmed live measurements: eyebrow
	   margin-bottom 16px->18px, heading margin 0->0 0 10px, description
	   max-width 480px->400px and margin 16px-auto-0->0-auto-44px. Font
	   family/size/weight/letter-spacing/color on all three are unchanged
	   from v1.0.13. */
	/* v1.0.20: live wearbvx.com/shop.wearbvx.com comparison found this
	   was rendering at line-height:14.4px (height 14.390625px) instead of
	   the frontend's natural line-height:normal (height 13px) - a Woo/
	   theme line-height rule was winning on specificity. !important added
	   to line-height only; font-size/weight/letter-spacing/margin were
	   already confirmed correct and are unchanged. */
	footer.site-footer .bvx-newsletter-eyebrow {
		display: block;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.6px;
		font-weight: 300;
		letter-spacing: 2.88px;
		text-transform: uppercase;
		color: #0A0A0A;
		margin-bottom: 18px;
		line-height: normal !important;
	}
	/* v1.0.20: live comparison found this was rendering at
	   line-height:63.84px (height 63.828125px) instead of the frontend's
	   natural line-height:normal (height 74px) - same bug class as the
	   eyebrow above. !important added to line-height only; the 60.8px
	   font-size and every other already-confirmed property are
	   unchanged. */
	footer.site-footer .bvx-newsletter-heading {
		display: block;
		font-family: "Inter Tight", sans-serif;
		font-size: 60.8px;
		font-weight: 900;
		letter-spacing: -1.824px;
		color: #0A0A0A;
		margin: 0 0 10px;
		line-height: normal !important;
	}
	/* v1.0.20: live comparison found three losing properties here (the
	   largest remaining mismatch this pass) - line-height:23.04px instead
	   of normal (height 46.015625px vs the frontend's ~34px), opacity:1
	   instead of .45, and an unwanted margin-top:20px instead of 0 (the
	   frontend's .footer-tagline-equivalent description has no top
	   margin at all). All three forced with !important; margin-bottom:44px
	   was already correct and is restated unchanged, without !important,
	   since it wasn't losing. font-size/weight/family were already
	   correct and are unchanged. */
	footer.site-footer .bvx-newsletter-desc {
		display: block;
		font-family: "Inter", sans-serif;
		font-size: 14.4px;
		font-weight: 300;
		color: #0A0A0A;
		margin: 0 auto 44px;
		max-width: 400px;
		line-height: normal !important;
		opacity: 0.45 !important;
		margin-top: 0 !important;
	}

	/* --- v1.0.14: Newsletter form geometry pass (matches the confirmed live
	   frontend measurements at 1728px). Every rule below is layout/
	   typography only, targeting the Hostinger Reach block's own
	   confirmed classes/ids exactly as given - no element is added,
	   removed, renamed, or reparented, no attribute other than style-
	   related CSS is touched, and nothing here runs on mobile (all of it
	   is inside this min-width:769px block; mobile keeps the exact
	   v1.0.9 dark-footer newsletter styling it has always had). The
	   form's hidden fields, submit handler, validation, and
	   .reach-subscription-message success/error markup are structurally
	   untouched - only their surrounding layout/typography changes. */

	/* Form-fields row - the 460x43 horizontal row itself. */
	footer.site-footer .hostinger-reach-block-form-fields {
		display: flex;
		flex-direction: row;
		align-items: stretch;
		box-sizing: border-box;
		width: 100%;
		max-width: 460px;
		height: 43px;
		margin: 0 auto;
		border-bottom: 1px solid rgba(0, 0, 0, 0.2);
		background: transparent;
	}

	/* Email field wrapper - takes all remaining row width after the
	   auto-sized submit button. */
	footer.site-footer .hostinger-reach-block-form-field {
		flex: 1;
		min-width: 0;
		display: flex;
		align-items: center;
	}
	/* v1.0.20: live computed-value trace identified the exact source of
	   the confirmed 4px vertical offset between the 43px form row and the
	   input - Hostinger's own field wrapper (unrelated to anything this
	   stylesheet sets) renders at height:34px with margin-top:8px
	   (presumably sized for a label-above-input layout; our label is
	   visually hidden via position:absolute, not removed from the DOM, so
	   it doesn't affect Hostinger's own wrapper sizing). The 42px input,
	   centered via the align-items:center above, overflows the 34px
	   wrapper by 4px top and bottom; combined with the wrapper's own 8px
	   margin-top, the input's actual top position lands 8-4=4px below the
	   form row's own top edge. Forcing the wrapper to height:42px and
	   margin-top:0 makes the wrapper and the input the same height (so
	   the existing centering no longer causes any overflow/offset) and
	   removes the margin that was pushing the whole field down - net
	   effect: the wrapper's top edge, and the input inside it, align
	   exactly with the 43px form row's own top edge. A separate,
	   narrowly-scoped rule rather than folding into the one above, so the
	   original flex/min-width/display/align-items declarations stay
	   exactly as they were. The input's own height/padding/font/Hostinger
	   Reach submission behavior and the 43px parent form row are all
	   untouched - only this one wrapper's height and margin-top change. */
	footer.site-footer #ai-theme-footer-form .hostinger-reach-block-form-field {
		height: 42px !important;
		margin-top: 0 !important;
	}

	/* Email label - visually hidden, not display:none, so it stays in
	   the accessibility tree and the DOM exactly as Hostinger renders it;
	   nothing is deleted. */
	footer.site-footer #ai-theme-footer-form label {
		position: absolute;
		width: 1px;
		height: 1px;
		padding: 0;
		margin: -1px;
		overflow: hidden;
		clip: rect(0, 0, 0, 0);
		white-space: nowrap;
		border: 0;
	}

	/* Email input - fills the remaining flex space; the visible line is
	   now the form-fields row's own border-bottom above, so the input's
	   individual border is removed rather than recolored. */
	footer.site-footer #ai-theme-footer-form input#ai-theme-footer-form-email {
		width: 100%;
		min-width: 0;
		padding: 12px 0;
		margin: 0;
		border: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 14.08px !important;
		font-weight: 400 !important;
		letter-spacing: 0.5632px !important;
	}
	/* v1.0.18: newsletter placeholder color, confirmed in the frontend
	   source (::placeholder { color: rgba(0,0,0,.35); }). Scoped here,
	   desktop-only, deliberately NOT sitewide: the placeholder text itself
	   (the PHP-added placeholder="your@email.com" attribute) ships to
	   both breakpoints since it's markup, not CSS, but mobile's own
	   #ai-theme-footer-form-email still sits on the original dark
	   background (v1.0.9's color:#ffffff rule, never touched here) where
	   rgba(0,0,0,.35) would be illegible - this rule only ever applies
	   where the input's text is already forced dark (this same
	   min-width:769px block, immediately above). Mobile placeholder text
	   is left at the browser's own default styling, unchanged from
	   whatever it would already render. */
	footer.site-footer #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder {
		color: rgba(0, 0, 0, 0.35);
	}

	/* Submit button - overrides Hostinger's default dark/full-width
	   button styling to an auto-sized, transparent, content-fit control
	   sitting inside the same flex row as the email field. The visible
	   label is produced purely via CSS (text-transform + a ::after arrow)
	   so the button's actual text node, submit type, and click/submit
	   behavior are all untouched. */
	footer.site-footer .hostinger-reach-block-submit {
		flex: 0 0 auto;
		width: auto !important;
		height: auto !important;
		padding: 12px 0 12px 20px !important;
		margin: 0 !important;
		border: 0 !important;
		border-radius: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.92px !important;
		font-weight: 400 !important;
		letter-spacing: 1.984px !important;
		text-transform: uppercase;
	}
	footer.site-footer .hostinger-reach-block-submit::after {
		content: " \2192"; /* → */
	}

	/* Success/error message - left structurally untouched; only given
	   the same 460px measure as the form row above it so it lines up
	   visually, per "allow it to display normally below the 460px form
	   row". No display/visibility property is set here, so whatever
	   Hostinger's script already does to show/hide it is unaffected. */
	footer.site-footer .reach-subscription-message {
		max-width: 460px;
		margin: 12px auto 0;
	}

	/* v1.0.15: brand/SHOP/INFO row - typography/spacing pass to the
	   confirmed live measurements. Column ratio (2.5fr 1fr 1fr) is
	   UNCHANGED - it already reduces to exactly 680/272/272 once the gap
	   below is set to the confirmed 48px, since 680:272:272 is exactly
	   2.5:1:1 and (1320 - 2*48) / 4.5 = 272. Still proportional/no fixed
	   px tracks, so it keeps scaling cleanly with no overflow at every
	   breakpoint - confirmed in the same Chromium render pass as before.
	   padding and margin-bottom below are the confirmed vertical rhythm
	   for this row specifically; see the .bvx-footer-bottom comment
	   further down for where the bottom-of-section spacing lives.
	   v1.0.16: border-top REMOVED from here and replaced by the
	   full-viewport-width separator below - see the ::before rule
	   immediately after this one. position:relative added only so that
	   ::before can anchor to this row's own top edge (no other layout
	   effect - this row was already in normal flow as a grid item). */
	/* v1.0.17: live inspection found a residual 40px top margin on this
	   row (margin: 40px 0 44px) that this stylesheet never set - it comes
	   from the theme's own global Gutenberg block-gap rule
	   (.is-layout-flow/.is-layout-constrained > * + * getting an
	   automatic margin-block-start from --wp--style--block-gap), which
	   this row inherits as a sibling block inside the constrained layout
	   wrapper. padding-top:52px is unaffected and already correct - only
	   the extra top margin is removed, with !important to beat that
	   global rule's own specificity. */
	.bvx-footer-content-row {
		display: grid;
		grid-column: 2;
		grid-template-columns: 2.5fr 1fr 1fr;
		gap: 48px;
		padding-top: 52px;
		margin: 0 0 44px !important;
		position: relative;
	}
	/* v1.0.16: full-width footer separator. .bvx-footer-content-row itself
	   stays capped at the 1320px content track (grid-column:2, unchanged -
	   the 1320px grid architecture is not touched), but the 1px divider
	   above it needs to span the full viewport edge-to-edge, matching the
	   confirmed live wearbvx.com design, not just the 1320px column. This
	   uses the standard viewport-breakout technique (left:50% + 100vw +
	   translateX(-50%)) rather than restructuring the grid or touching
	   PHP markup: because the outer grid's gutters are symmetric, the
	   row's horizontal center already coincides with the viewport's
	   horizontal center, so this pseudo-element's left edge resolves to
	   exactly 0 (viewport's own left edge) with no added horizontal
	   overflow - confirmed via a real Chromium render at every breakpoint
	   before this is packaged. top:0 keeps it at the exact same vertical
	   position the old border-top occupied (the row's own top edge,
	   before its 52px padding-top). */
	.bvx-footer-content-row::before {
		content: "";
		position: absolute;
		top: 0;
		left: 50%;
		width: 100vw;
		transform: translateX(-50%);
		border-top: 1px solid rgba(0, 0, 0, 0.1);
	}
	/* v1.0.15: size 20px->22.4px, weight 800->900, letter-spacing
	   -0.4px->-0.448px, margin-bottom 16px->8px. Font-family and color
	   are unchanged - BVX LONDON is the one element in this row that
	   keeps full-opacity color rather than the opacity-based muting used
	   below, matching the confirmed live styling.
	   v1.0.17: live inspection found this was actually computing to
	   font-family:Inter/font-weight:300 despite this rule - the theme's
	   own heading/paragraph styles were winning on specificity. Selector
	   scoped to footer.site-footer .bvx-footer-brand-name and
	   !important added to font-family and font-weight only (exactly as
	   confirmed), which are the two properties that were actually losing.
	   font-size/letter-spacing/margin were already rendering correctly, so
	   no !important added to those. color:#0A0A0A is kept unchanged (not
	   mentioned in this pass's override snippet, but nothing indicated it
	   should be removed and it was already rendering correctly).
	   v1.0.20: live comparison found this was also rendering at
	   line-height:35.84px (height 35.8125px) instead of the frontend's
	   natural line-height:normal (height 27px) - the oversized line box
	   was making the whole left footer stack slightly taller than the
	   frontend. !important added to line-height only. */
	footer.site-footer .bvx-footer-brand-name {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 22.4px;
		font-weight: 900 !important;
		letter-spacing: -0.448px;
		color: #0A0A0A;
		margin: 0 0 8px;
		line-height: normal !important;
	}
	/* v1.0.19: "Captain Croak" tagline paragraph, restored this pass
	   (previously omitted entirely, so this rule is new - there is no
	   prior version to carry over from). Matches the confirmed frontend
	   spec exactly. max-width:240px is the frontend's own wrap width, kept
	   literally since the brand column here is wider than 240px and the
	   frontend clearly wraps this copy narrower than the full column.
	   v1.0.20: live comparison found line-height:1.65 was still losing to
	   a competing theme paragraph rule (computing 19.968px/height
	   59.8125px instead of the confirmed frontend 20.592px/61.6875px -
	   12.48 * 1.6, not 1.65) despite already being set above - the same
	   higher-specificity compound-selector theme rule already identified
	   on .bvx-footer-brand-name/.bvx-footer-col-heading/etc. Selector
	   scoped to footer.site-footer and !important added to line-height
	   only; every other property here was already correct. */
	footer.site-footer .bvx-footer-brand-copy {
		font-family: "Inter", sans-serif;
		font-size: 12.48px;
		font-weight: 300;
		line-height: 1.65 !important;
		opacity: 0.35;
		margin: 0 0 20px;
		max-width: 240px;
	}
	/* v1.0.16 (confirmed): "Each IG / TT / WA" spec - 34x34px flex box,
	   vertically AND horizontally centered content (justify-content:center
	   confirmed live this pass), JetBrains Mono 9.28px/300, opacity:.6.
	   text-decoration:none kept (confirmed live this pass) so the link has
	   no underline. box-sizing:border-box kept so the box's TOTAL rendered
	   height (including the border) is exactly 34px - without it, 34px
	   height + border renders larger than 34px total under the default
	   content-box, the same class of bug already caught and fixed once
	   before on the newsletter form row; confirmed here via a real
	   Chromium render (34.00px, not larger).
	   v1.0.18: border-top -> full border (all four sides), matching the
	   confirmed frontend source exactly (border:1px solid rgba(0,0,0,.15)).
	   color:#0A0A0A added (was previously unset/inherited - the frontend
	   source states it explicitly). font-weight:300 is carried over
	   unchanged (not in this pass's literal property list, but nothing
	   indicated removing it, and it was already rendering correctly). */
	.bvx-footer-socials a {
		box-sizing: border-box;
		width: 34px;
		height: 34px;
		display: flex;
		align-items: center;
		justify-content: center;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		color: #0A0A0A;
		opacity: 0.6;
		text-decoration: none;
		border: 1px solid rgba(0, 0, 0, 0.15);
	}
	/* v1.0.16: "Social row" spec - gap 16px -> 8px (display:flex was
	   already correct, unchanged). */
	.bvx-footer-socials {
		display: flex;
		gap: 8px;
	}
	/* v1.0.16: "Exact WhatsApp Us styling" - full rewrite to the confirmed
	   live spec. letter-spacing:0.928px (the IG/TT/WA rule above has
	   none). text-decoration:none kept so the link has no underline.
	   v1.0.17: margin-top:81.6875px (the artificial Captain Croak
	   compensation) REMOVED per explicit instruction - no Captain Croak
	   paragraph exists or is added, so no compensating hole is kept.
	   Replaced (at the time) with a compact margin-top:20px.
	   v1.0.18: border-top -> full border (all four sides, matching the
	   confirmed frontend source: border:1px solid rgba(37,211,102,.25)).
	   background:rgba(37,211,102,.08) and color:#25D366 (WhatsApp green
	   text) added - both new, confirmed in the frontend source, neither
	   previously set. margin-top corrected 20px -> 0: the confirmed
	   frontend .whatsapp-link rule has no top margin at all - only
	   margin-bottom:14px - so the v1.0.17 20px value (my own interpretive
	   compensation, not a literal frontend value) is removed rather than
	   kept; BVX LONDON's own margin-bottom:8px already provides the
	   natural spacing above this link, confirmed via a real Chromium
	   render with no visual gap or overlap. font-weight:300 is carried
	   over unchanged (confirmed live this pass as the actual computed
	   value for WhatsApp/socials/footer-link-text, so explicitly kept,
	   not just left alone by omission). */
	.bvx-footer-whatsapp-us {
		display: inline-flex;
		align-items: center;
		gap: 8px;
		width: auto;
		background: rgba(37, 211, 102, 0.08);
		padding: 10px 14px;
		margin-top: 0;
		margin-bottom: 14px;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		letter-spacing: 0.928px;
		color: #25D366;
		border: 1px solid rgba(37, 211, 102, 0.25);
		text-decoration: none;
	}
	/* v1.0.18: sizes the real WhatsApp SVG icon now rendered inside the
	   link (previously text-only). Not an explicit property in the given
	   spec block - added because the spec assumes an icon is present
	   (gap:8px between icon and text) but doesn't size it; flagging this
	   addition. fill is not set here since the SVG itself uses
	   fill="currentColor", so it automatically takes the link's own
	   color:#25D366 with no separate rule needed. */
	.bvx-footer-whatsapp-us svg {
		width: 14px;
		height: 14px;
		flex-shrink: 0;
	}
	/* v1.0.19: live v1.0.18 inspection found .bvx-footer-whatsapp-us was
	   actually computing color:rgb(10,10,10) instead of the already-set
	   color:#25D366 above - a theme/global link-color rule was winning on
	   specificity (the same bug class fixed on .bvx-footer-col-heading and
	   the bottom legal text this pass). !important added here only to
	   color, the one property confirmed losing; geometry (34/36/padding/
	   border/background), font, and the SVG's own sizing above are all
	   unchanged. The SVG uses fill="currentColor" with no fill set on its
	   own <path>, so it was inheriting whatever color actually won -
	   explicit fill:currentColor !important added to both the <svg> and
	   its <path> so the icon is guaranteed to track this corrected color
	   regardless of any future specificity fight on the <svg>/<path>
	   elements themselves. */
	footer.site-footer .bvx-footer-whatsapp-us {
		color: #25D366 !important;
	}
	footer.site-footer .bvx-footer-whatsapp-us svg,
	footer.site-footer .bvx-footer-whatsapp-us svg path {
		fill: currentColor !important;
	}
	/* v1.0.24 fix: confirmed live on My Account that WhatsApp Us and the
	   IG/TT/WA social buttons show an unwanted underline despite
	   text-decoration:none already being set on both .bvx-footer-
	   whatsapp-us (line ~1000) and .bvx-footer-socials a (line ~955)
	   above - the same specificity class of bug fixed for color just
	   above (a theme/global anchor rule, likely setting color AND
	   text-decoration together, wins on specificity since neither
	   existing rule carries !important on this property). Scoped to
	   body.woocommerce-account specifically, per instruction, rather than
	   widening the existing unscoped base rules - button borders, the
	   green WhatsApp color/background, hover behavior, the 34x34 social
	   geometry, and every typography property on both elements are
	   completely untouched; only text-decoration is forced here. */
	body.woocommerce-account footer.site-footer .bvx-footer-whatsapp-us,
	body.woocommerce-account footer.site-footer .bvx-footer-socials a {
		text-decoration: none !important;
	}
	/* v1.0.15: solid color->opacity:.35 (font family/size/weight/
	   letter-spacing/uppercase were already exactly the confirmed
	   values, unchanged). margin-bottom:14px added - currently has no
	   visible effect since SHOP/INFO render heading-only (no links yet,
	   per the standing "no invented URLs" instruction), but is harmless
	   and ready for when a <nav> link list is added.
	   v1.0.19: live v1.0.18 inspection found this was actually computing
	   to font-family:Inter Tight/font-weight:900/letter-spacing:-0.1856px
	   despite this rule - the same class of specificity loss already
	   fixed once on .bvx-footer-brand-name (v1.0.17) and the bottom
	   legal text (below), here hitting the SHOP/INFO <h3> headings
	   instead because the theme's own heading rules target h3 directly.
	   Selector scoped to footer.site-footer .bvx-footer-col-heading with
	   !important added to font-family/font-size/font-weight/
	   letter-spacing (the properties confirmed losing); line-height:
	   normal added since the theme's h3 rule also sets its own
	   line-height which would otherwise still win unopposed. text-
	   transform/opacity/margin were already rendering correctly, so no
	   !important added to those. */
	footer.site-footer .bvx-footer-col-heading {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.28px !important;
		font-weight: 700 !important;
		letter-spacing: 2.32px !important;
		line-height: normal;
		text-transform: uppercase;
		opacity: 0.35;
		margin: 0 0 14px;
	}
	/* v1.0.15: "FOOTER LINKS" typography - matches the confirmed
	   "link/text" spec exactly (Inter, 12.8px, opacity:.6, color:#0A0A0A,
	   text-decoration:none). font-weight:300 is carried over unchanged
	   (not in this pass's literal list either, nothing indicated removing
	   it).
	   v1.0.18: this rule now actually renders, since SHOP/INFO are
	   restored and populated below - it was dormant through v1.0.17 since
	   no <a>/text existed inside these columns yet. Selector widened to
	   .bvx-footer-link-text (shared by the one real link - "Contact" -
	   AND every non-clickable label) so every SHOP/INFO item gets
	   IDENTICAL typography whether or not it's clickable, per the explicit
	   instruction to render unverified items "visually as non-clickable
	   text using the same typography" rather than a visually-distinct
	   placeholder. */
	.bvx-footer-shop a,
	.bvx-footer-info a,
	.bvx-footer-link-text {
		font-family: "Inter", sans-serif;
		font-size: 12.8px;
		font-weight: 300;
		opacity: 0.6;
		color: #0A0A0A;
		text-decoration: none;
	}
	/* v1.0.18: SHOP/INFO restored (v1.0.17's visibility:hidden removed
	   below) and populated with real content, so they now need actual
	   list styling. "ul: list-style:none" is the literal spec; margin:0
	   and padding-left:0 are added alongside it (not explicitly listed)
	   because leaving the browser's default ~40px ul padding-left in
	   place would visibly misalign the list against the SHOP/INFO
	   headings above it and the 48px column gap - flagging this addition
	   as a necessary completion of "list-style:none", not an invented
	   value. */
	.bvx-footer-shop ul,
	.bvx-footer-info ul {
		list-style: none;
		margin: 0;
		padding-left: 0;
	}
	/* v1.0.18: "li: margin-bottom:10px" - literal spec, new this pass. */
	.bvx-footer-shop li,
	.bvx-footer-info li {
		margin-bottom: 10px;
	}

	/* v1.0.15: "FOOTER BOTTOM" - padding-top 20px->22px, border color
	   notation matched literally to the confirmed rgba(0,0,0,.1) (same
	   color as before, rgba(10,10,10,.1), just matched to the exact
	   literal given this pass). padding-bottom:28px maps to the confirmed
	   frontend "footer" element's own 28px bottom padding - the frontend's
	   <footer> wraps only footer-grid + footer-bottom (no newsletter), so
	   its bottom inset corresponds to this element's own bottom edge in
	   our implementation, which additionally carries a newsletter section
	   the frontend's footer doesn't have; kept here as established since
	   v1.0.15 and unchanged by the v1.0.18 source. display:flex/
	   justify-content:space-between were already correct, unchanged.
	   max-width:1320px/margin:0 auto from the v1.0.18 source are already
	   achieved differently here (grid-column:2, sitting in the outer
	   grid's own 1320px-capped middle track) rather than set literally on
	   this element - same rendered result via the existing architecture,
	   not duplicated.
	   v1.0.17: live inspection found a residual 40px top margin on this
	   element too (margin-top: 40px), from the same theme global
	   block-gap rule noted above on .bvx-footer-content-row - this
	   stylesheet never set it. The content row above already provides the
	   correct 44px bottom spacing before this strip, so margin:0
	   !important removes the extra 40px entirely rather than folding it
	   into padding.
	   v1.0.18: flex-wrap:wrap and gap:8px added - both new, confirmed in
	   the v1.0.18 source, not previously present. */
	.bvx-footer-bottom {
		display: flex;
		grid-column: 2;
		justify-content: space-between;
		align-items: center;
		flex-wrap: wrap;
		gap: 8px;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
		margin: 0 !important;
		padding: 22px 0 28px;
	}
	/* v1.0.15: "BOTTOM TEXT" - font-family added (JetBrains Mono, was
	   unset/inherited before), size 11px->8.96px, weight 300 added,
	   letter-spacing .896px added, uppercase added, solid color->
	   opacity:.25.
	   v1.0.19: live v1.0.18 inspection found font-family was the one
	   property still losing to a theme rule (size/weight/letter-spacing/
	   opacity were all already correct) - same specificity-loss class as
	   .bvx-footer-col-heading and .bvx-footer-whatsapp-us above.
	   !important added to font-family only.
	   v1.0.20: live comparison found line-height was the one remaining
	   mismatch (14.336px/height 14.3125px instead of the frontend's
	   natural line-height:normal/height 12px) - same bug class as the
	   newsletter eyebrow/heading and BVX LONDON above. !important added
	   to line-height only. */
	footer.site-footer .bvx-footer-copyright,
	footer.site-footer .bvx-footer-tagline {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 8.96px;
		font-weight: 300;
		letter-spacing: 0.896px;
		text-transform: uppercase;
		opacity: 0.25;
		margin: 0;
		line-height: normal !important;
	}

	/* Original bottom block - UNTOUCHED markup, hidden ONLY at this
	   breakpoint - never affects mobile. */
	footer.site-footer > .wp-block-group.has-color-2-background-color > .wp-block-group.alignwide.is-content-justification-center {
		display: none !important;
	}

	/* Gutenberg constrained-layout override. Confirmed live at 1728px:
	   .bvx-footer-content-row and .bvx-footer-bottom are both direct
	   children of .wp-block-group.is-layout-constrained (the theme's
	   global block-layout wrapper, not anything this plugin creates), and
	   were inheriting its default max-width:700px + auto side margins -
	   confirmed as .bvx-footer-content-row computing to width:464.19px/
	   max-width:700px and .bvx-footer-bottom to width:390.36px/
	   max-width:700px, both still correctly placed at grid-column:2. The
	   surrounding grid/architecture above is confirmed correct and is not
	   touched here - this only removes the theme's global cap on these
	   two specific elements so each fills its already-correct 1320px
	   center grid track. justify-self:stretch is the grid-level
	   counterpart to width:100% here, since these are grid items of the
	   outer wrapper's grid (col1 architecture from earlier in this file),
	   not flex items. */
	footer.site-footer .bvx-footer-content-row,
	footer.site-footer .bvx-footer-bottom {
		width: 100%;
		max-width: none !important;
		margin-left: 0 !important;
		margin-right: 0 !important;
		justify-self: stretch;
	}

}

/*
 * v1.0.21 addition - Phase 1 checkout BVX chrome. Confirmed via live
 * Console inspection that WooCommerce Checkout (body.woocommerce-checkout,
 * WooCommerce Blocks checkout) uses the SAME .hostinger-ai-menu-wrapper /
 * .hostinger-ai-site-navigation-wrapper header classes as My Account, but
 * a DIFFERENT footer structure: <footer class="wp-block-template-part">
 * (no site-footer token) wrapping a .wp-block-group.has-color-2-
 * background-color group whose first child is .wp-block-columns.alignwide
 * - so none of the existing body.woocommerce-account or footer.site-footer
 * rules above can match checkout. Everything in this block is new and
 * additive; nothing above is modified.
 *
 * HEADER: mirrors only the non-nav-dependent properties of the
 * body.woocommerce-account header block above (menu height/padding, the
 * same white-background override against the theme's
 * has-color-1-background-color utility class, and the same wrapper
 * cage-removal) - confirmed via the same wrapper class names, but not
 * separately live-measured on checkout itself, so worth a quick visual
 * spot-check after this lands. Deliberately NOT extended to checkout:
 * the grid-template-columns: 1fr auto 1fr split and every
 * .bvx-account-header-nav* rule, since no nav is inserted on checkout
 * this pass (per explicit instruction - checkout is a purchase flow, not
 * an account-management page). Existing account/cart icon and
 * .hostinger-ai-site-navigation-wrapper spacing rules elsewhere in this
 * file are already sitewide (not account-gated), so they already apply
 * to checkout unchanged - nothing to duplicate here.
 *
 * FOOTER: mirrors the existing footer.site-footer grid/background
 * treatment and the Gutenberg constrained-layout max-width override, both
 * scoped to the confirmed checkout footer structure.
 *
 * Corrected after live confirmation: checkout's footer uses the exact
 * same template-part columns markup as account/shop (col 0 empty, col 1
 * contacts/socials, col 2 the Hostinger Reach newsletter form) - the
 * sitewide newsletter-copy PHP transformation (5, above) already matches
 * and runs there regardless of page, since it is not gated to
 * footer.site-footer. An earlier draft of this pass hid the ENTIRE
 * .wp-block-columns.alignwide block on checkout, which also hid that
 * newsletter column - confirmed visually via Chromium render before this
 * correction. Fixed by mirroring the EXACT same col-0/col-1-hide,
 * col-2-unwrap technique already proven on My Account/shop (same
 * selectors, same grid-column/background/padding/border-top values, same
 * .bvx-newsletter-eyebrow/heading/desc/form rules) under the new
 * checkout-scoped selector, rather than inventing a second newsletter
 * design - every property below is copied verbatim from the matching
 * footer.site-footer rule earlier in this file. The Hostinger Reach
 * <form>, its id/hidden fields/nonce, submit handler, and validation are
 * never touched by any of this - only layout/typography CSS on the
 * confirmed existing selectors, exactly as already proven on My Account.
 * .bvx-footer-content-row and .bvx-footer-bottom are both already-global
 * rules (grid-column:2, not footer.site-footer-scoped - see above), so
 * they render correctly here with no new selector needed for their own
 * internal layout/typography. Mobile is unaffected with no new rule
 * needed: both inserted blocks already default to display:none outside
 * any media query (see the sitewide .bvx-footer-content-row/.bvx-footer-
 * bottom rule earlier in this file), and the original columns/newsletter
 * markup is left completely alone at max-width:768px, so checkout mobile
 * keeps today's original footer exactly.
 */
@media (min-width: 769px) {

	body.woocommerce-checkout .hostinger-ai-menu,
	body.woocommerce-cart .hostinger-ai-menu {
		height: 64px;
		padding-left: 32px;
		padding-right: 32px;
	}

	body.woocommerce-checkout div.wp-block-group.hostinger-ai-menu.has-color-1-background-color,
	body.woocommerce-cart div.wp-block-group.hostinger-ai-menu.has-color-1-background-color {
		background-color: rgba(255, 255, 255, 0.95) !important;
	}

	body.woocommerce-checkout .hostinger-ai-menu-wrapper,
	body.woocommerce-cart .hostinger-ai-menu-wrapper {
		width: 100%;
		max-width: none;
	}

	/* Outer footer grid + #F7F7F7 background, mirroring
	   footer.site-footer > .wp-block-group.has-color-2-background-color
	   above, scoped to the confirmed checkout footer structure. */
	body.woocommerce-checkout footer.wp-block-template-part > .wp-block-group.has-color-2-background-color,
	body.woocommerce-cart footer.wp-block-template-part > .wp-block-group.has-color-2-background-color {
		display: grid;
		grid-template-columns: minmax(16px, 1fr) minmax(0, min(1320px, calc(100% - 32px))) minmax(16px, 1fr);
		row-gap: 0;
		padding: 0 !important;
		background: #F7F7F7 !important;
	}

	/* col 0 - mirrors footer.site-footer > ... :first-child above. */
	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:first-child,
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:first-child {
		display: none !important;
	}

	/* col 1 - original contacts/socials. UNTOUCHED markup, hidden ONLY at
	   this breakpoint - never affects mobile. Mirrors footer.site-footer
	   > ... :nth-child(2) above; its real desktop content is
	   .bvx-footer-brand, inserted by the same 6b PHP block. */
	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:nth-child(2),
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:nth-child(2) {
		display: none !important;
	}

	/* col 2 - the Hostinger Reach newsletter form, confirmed present in
	   the same template-part columns markup as account/shop. UNTOUCHED
	   markup/DOM position/submission behavior - unwraps .wp-block-columns
	   so col 2 becomes a direct grid child, exactly mirroring the
	   footer.site-footer treatment above. */
	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide,
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide {
		display: contents;
	}
	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column.has-light-color,
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column.has-light-color {
		grid-column: 1 / -1;
		background: #FAF7F2;
		padding: 88px 24px;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
		text-align: center;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-subscription-form-wrapper,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-subscription-form-wrapper {
		max-width: 460px;
		margin: 0 auto;
	}

	/* Eyebrow/heading/description - re-enabled from the sitewide
	   display:none default exactly like footer.site-footer above; every
	   property copied verbatim from the matching account/shop rule. */
	body.woocommerce-checkout footer.wp-block-template-part .bvx-newsletter-eyebrow,
	body.woocommerce-cart footer.wp-block-template-part .bvx-newsletter-eyebrow {
		display: block;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.6px;
		font-weight: 300;
		letter-spacing: 2.88px;
		text-transform: uppercase;
		color: #0A0A0A;
		margin-bottom: 18px;
		line-height: normal !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-newsletter-heading,
	body.woocommerce-cart footer.wp-block-template-part .bvx-newsletter-heading {
		display: block;
		font-family: "Inter Tight", sans-serif;
		font-size: 60.8px;
		font-weight: 900;
		letter-spacing: -1.824px;
		color: #0A0A0A;
		margin: 0 0 10px;
		line-height: normal !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-newsletter-desc,
	body.woocommerce-cart footer.wp-block-template-part .bvx-newsletter-desc {
		display: block;
		font-family: "Inter", sans-serif;
		font-size: 14.4px;
		font-weight: 300;
		color: #0A0A0A;
		margin: 0 auto 44px;
		max-width: 400px;
		line-height: normal !important;
		opacity: 0.45 !important;
		margin-top: 0 !important;
	}

	/* Newsletter form geometry - copied verbatim from the matching
	   footer.site-footer rules above, including the v1.0.20 4px-offset
	   fix. The form's hidden fields, submit handler, validation, and
	   .reach-subscription-message markup are structurally untouched. */
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-form-fields,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-form-fields {
		display: flex;
		flex-direction: row;
		align-items: stretch;
		box-sizing: border-box;
		width: 100%;
		max-width: 460px;
		height: 43px;
		margin: 0 auto;
		border-bottom: 1px solid rgba(0, 0, 0, 0.2);
		background: transparent;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-form-field,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-form-field {
		flex: 1;
		min-width: 0;
		display: flex;
		align-items: center;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form .hostinger-reach-block-form-field,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form .hostinger-reach-block-form-field {
		height: 42px !important;
		margin-top: 0 !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form label,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form label {
		position: absolute;
		width: 1px;
		height: 1px;
		padding: 0;
		margin: -1px;
		overflow: hidden;
		clip: rect(0, 0, 0, 0);
		white-space: nowrap;
		border: 0;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email {
		width: 100%;
		min-width: 0;
		padding: 12px 0;
		margin: 0;
		border: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 14.08px !important;
		font-weight: 400 !important;
		letter-spacing: 0.5632px !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder {
		color: rgba(0, 0, 0, 0.35);
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-submit,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-submit {
		flex: 0 0 auto;
		width: auto !important;
		height: auto !important;
		padding: 12px 0 12px 20px !important;
		margin: 0 !important;
		border: 0 !important;
		border-radius: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.92px !important;
		font-weight: 400 !important;
		letter-spacing: 1.984px !important;
		text-transform: uppercase;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-submit::after,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-submit::after {
		content: " \2192"; /* → */
	}
	body.woocommerce-checkout footer.wp-block-template-part .reach-subscription-message,
	body.woocommerce-cart footer.wp-block-template-part .reach-subscription-message {
		max-width: 460px;
		margin: 12px auto 0;
	}

	/* Same Gutenberg constrained-layout max-width override as the
	   account/shop footer above, scoped to checkout - the inserted
	   .bvx-footer-content-row/.bvx-footer-bottom are direct children of
	   the theme's global .is-layout-constrained block-layout wrapper here
	   too, and would otherwise inherit its default max-width:700px + auto
	   side margins. */
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-content-row,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-content-row,
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-bottom,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-bottom {
		width: 100%;
		max-width: none !important;
		margin-left: 0 !important;
		margin-right: 0 !important;
		justify-self: stretch;
	}

	/* v1.0.21 correction (round 2): live checkout computed values showed
	   the FIRST typography mirror still losing to Hostinger/theme rules
	   confirmed specific to the checkout template part (Montserrat 16px
	   paragraph defaults, a Junge 18.72px/700 heading default) - a
	   different, apparently higher-specificity competing rule than
	   whatever footer.site-footer already beats on My Account, where most
	   of these properties didn't need !important at all. Every property
	   below is now forced with !important (not just the ones that lost on
	   My Account), confirmed live by Avi against the following targets:
	   brand = Inter Tight/22.4/900/normal/-0.448; brandCopy = Inter/
	   12.48/300/1.65/.35/max-width 240; heading (SHOP/INFO) = JetBrains
	   Mono/9.28/700/normal/2.32/.35; footer links = Inter/12.8/300/
	   normal/.6 (only line-height was missing - 12.8/300/.6 were already
	   confirmed correct and are kept, line-height now added); legal =
	   JetBrains Mono/8.96/300/normal/.896/.25. Newsletter and WhatsApp/
	   social geometry are explicitly NOT touched this pass - both already
	   confirmed close enough live. No new values invented - every number
	   here is the same v1.0.20-proven target as the first mirror, just
	   with full !important coverage this time. The existing
	   footer.site-footer/body.woocommerce-account rules themselves remain
	   completely untouched. */
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-brand-name,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-brand-name {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 22.4px !important;
		font-weight: 900 !important;
		line-height: normal !important;
		letter-spacing: -0.448px !important;
		color: #0A0A0A !important;
		margin: 0 0 8px !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-brand-copy,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-brand-copy {
		font-family: "Inter", sans-serif !important;
		font-size: 12.48px !important;
		font-weight: 300 !important;
		line-height: 1.65 !important;
		opacity: 0.35 !important;
		margin: 0 0 20px !important;
		max-width: 240px !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-whatsapp-us,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-whatsapp-us {
		color: #25D366 !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-whatsapp-us svg,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-whatsapp-us svg,
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-whatsapp-us svg path,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-whatsapp-us svg path {
		fill: currentColor !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-col-heading,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-col-heading {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.28px !important;
		font-weight: 700 !important;
		line-height: normal !important;
		letter-spacing: 2.32px !important;
		opacity: 0.35 !important;
		margin: 0 0 14px !important;
		text-transform: uppercase;
	}
	/* Keeping the existing 12.8/300/.6 values unchanged (already
	   confirmed correct live) - forcing only the missing property,
	   line-height, per explicit instruction not to touch what's already
	   matching. */
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-shop a,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-shop a,
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-info a,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-info a,
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-link-text,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-link-text {
		line-height: normal !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-copyright,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-copyright,
	body.woocommerce-checkout footer.wp-block-template-part .bvx-footer-tagline,
	body.woocommerce-cart footer.wp-block-template-part .bvx-footer-tagline {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 8.96px !important;
		font-weight: 300 !important;
		line-height: normal !important;
		letter-spacing: 0.896px !important;
		opacity: 0.25 !important;
		margin: 0 !important;
	}
}

/*
 * v1.0.24 fix - extra footer chameleon logo on Checkout/Cart. Confirmed
 * live: Checkout and Cart both show a second chameleon logo inside the
 * footer; My Account/shop's footer.site-footer does not. Traced to this
 * plugin's own transformation 1 (bvx_shop_chrome_replace_site_title()),
 * which swaps the output of ANY core/site-title block, sitewide, with no
 * location gating - it runs on render_block and only checks the block
 * name, never where on the page that block renders. This plugin is the
 * ONLY source of a chameleon-logo element anywhere in this codebase (the
 * BVX chameleon asset and the .bvx-shop-chrome-logo/-img classes exist
 * nowhere else), so the extra footer logo is this exact swap firing a
 * second time against a core/site-title block that Checkout/Cart's own
 * FSE footer template part apparently also contains - unlike My
 * Account/shop's footer.site-footer template, which has none.
 *
 * Note: this environment has no live browser access to independently
 * inspect the rendered Checkout/Cart DOM, so the targeted element is
 * identified from the plugin's own code rather than a fresh live
 * Console check - .bvx-shop-chrome-logo is the one confirmed, exact
 * class this plugin itself outputs for every chameleon-logo instance, in
 * header AND footer alike (transformation 1 cannot tell them apart - it
 * only sees the block, not its container). A visual spot-check after
 * this lands is recommended to confirm it is in fact this element and
 * nothing else.
 *
 * Fixed with a footer-scoped suppression rather than a PHP change to
 * transformation 1 itself, so nothing about the logo swap's sitewide
 * behavior changes for every other block/page - this only hides the
 * swapped-in logo when it renders inside the confirmed checkout/cart
 * FOOTER ancestor. The identical class rendering inside <header
 * class="wp-block-template-part"> - the normal, wanted header logo, on
 * every page including Checkout/Cart - is a completely different
 * ancestor and is never matched by this selector. Not scoped to the
 * min-width:769px media query, since the issue was confirmed present
 * without a stated breakpoint; hiding is harmless at every width. Does
 * not touch My Account, shop, the header logo anywhere, or any other
 * transformation/rule in this file.
 */
body.woocommerce-checkout footer.wp-block-template-part .bvx-shop-chrome-logo,
body.woocommerce-cart footer.wp-block-template-part .bvx-shop-chrome-logo {
	display: none !important;
}

/*
 * v1.0.25 - Checkout BODY typography pass (Woo Blocks Checkout), matching
 * the established BVX frontend typography system. Typography only - no
 * layout, width, field-height, shipping, payment, express-checkout, or
 * structural change of any kind. Confirmed live computed values before
 * this pass: h1 Junge/38/700/57; section headings Junge/16/500/22.4;
 * field labels Montserrat/16/400/22; field values Montserrat/16/400/25;
 * totals Montserrat/12/400; shipping method Montserrat/16/400/24; Woo
 * buttons Montserrat/12/400 - all theme/Woo Blocks defaults, none ever
 * set by this plugin before this pass. Every rule below is unscoped by
 * breakpoint (applies at every width) since this is a body typography
 * system change, not a responsive-layout change; validated at
 * 390/769/1024/1440/1728px to confirm no layout shift, only font
 * rendering. Scoped entirely to body.woocommerce-checkout - My Account,
 * Cart, shop, and every other page are unaffected, and this never
 * touches the Checkout/Cart header/footer chrome (v1.0.21-v1.0.24) or
 * Woo Blocks Cart.
 */

/* 1) Main Checkout title. Font-size intentionally left at the theme's
   existing ~38px scale - not redesigning page geometry this pass. */
body.woocommerce-checkout h1 {
	font-family: "Inter Tight", sans-serif !important;
	font-weight: 900 !important;
	letter-spacing: -0.03em !important;
	line-height: normal !important;
}

/* 2) Section headings (Contact information / Shipping address / Shipping
   options / Payment options / Order summary). Size intentionally left at
   the existing ~16px scale. */
body.woocommerce-checkout .wc-block-components-checkout-step__title,
body.woocommerce-checkout .wc-block-components-checkout-order-summary__title {
	font-family: "Inter Tight", sans-serif !important;
	font-weight: 700 !important;
	letter-spacing: -0.02em !important;
	line-height: normal !important;
}

/* 3) Form labels - Montserrat -> JetBrains Mono, matching the micro-label
   treatment already established elsewhere in this plugin (newsletter
   eyebrow, SHOP/INFO headings). Floating-label behavior/functionality
   (position, transition, focus/filled states) is untouched - only the
   type styling properties below are set. */
body.woocommerce-checkout .wc-block-components-text-input label,
body.woocommerce-checkout .wc-block-components-combobox-control label {
	font-family: "JetBrains Mono", monospace !important;
	font-size: 10px !important;
	font-weight: 400 !important;
	letter-spacing: 0.08em !important;
	line-height: normal !important;
}

/* 4) Form input values - Montserrat -> Inter. Field height, padding,
   validation, focus outline, autocomplete, and address logic are
   untouched - only font properties are set, and no box-model property
   (height/padding/border/width) appears in this rule. */
body.woocommerce-checkout .wc-block-components-text-input input,
body.woocommerce-checkout .wc-block-components-combobox-control input,
body.woocommerce-checkout select {
	font-family: "Inter", sans-serif !important;
	font-size: 14px !important;
	font-weight: 300 !important;
}

/* 5) Order summary / totals / product text - Montserrat -> Inter.
   Existing sizes preserved (no font-size set here) per instruction;
   nothing about the order-summary structure, totals calculation, or
   product data is touched. */
body.woocommerce-checkout .wc-block-components-totals-item__label,
body.woocommerce-checkout .wc-block-components-totals-item__value,
body.woocommerce-checkout .wc-block-components-order-summary-item__description,
body.woocommerce-checkout .wc-block-components-order-summary-item__total-price {
	font-family: "Inter", sans-serif !important;
}

/* 6) Shipping method text - Montserrat -> Inter. Shipping calculations,
   radio controls, and prices are untouched - only font-family/weight on
   the package text itself. */
body.woocommerce-checkout .wc-block-components-shipping-rates-control__package {
	font-family: "Inter", sans-serif !important;
	font-weight: 300 !important;
}

/* 7) Checkout buttons (incl. "Place Order") - JetBrains Mono utility
   language, matching the BVX footer's own uppercase micro-type button
   treatment. .wc-block-components-button is WooCommerce Blocks' own
   generic button component (Place Order, Continue to payment, Apply
   coupon, etc.) - third-party Express Checkout buttons (Google Pay,
   Amazon Pay, OneLink, Klarna, Clearpay) are rendered by each gateway's
   own script/iframe as their own branded elements and do not carry this
   class, so they are never matched here; no additional exclusion
   selector was needed. This plugin's environment has no live browser
   access to re-confirm that against the actual DOM, so a visual
   spot-check after this lands is recommended, same as the v1.0.24
   footer-logo note. */
body.woocommerce-checkout .wc-block-components-button {
	font-family: "JetBrains Mono", monospace !important;
	font-size: 10px !important;
	font-weight: 400 !important;
	letter-spacing: 0.12em !important;
	text-transform: uppercase;
}


/*
 * v1.0.26 - My Account MOBILE chrome pass (Phase M1-M3). CSS-only, no PHP
 * change - every element referenced below already exists in the rendered
 * DOM today (the BVX footer content-row/bottom strip have been rendered
 * sitewide by bvx_shop_chrome_render_footer_content_row()/
 * bvx_shop_chrome_render_footer_bottom() since v1.0.13/v1.0.21, and the
 * newsletter eyebrow/heading/desc since v1.0.13 - all default
 * display:none outside any media query, confirmed/documented above). This
 * pass only reveals and restyles what is already there, inside a NEW
 * @media (max-width: 768px) block, scoped additionally to
 * body.woocommerce-account throughout - deliberately NOT sitewide, since
 * this first pass covers My Account mobile only, per explicit instruction.
 * Cart/Checkout mobile, desktop (every min-width:769px rule above,
 * untouched), Cart Bridge, Account Styling, Hostinger Reach's own
 * form id/hidden fields/submit handler/validation, and every Woo account
 * endpoint/link are all unaffected - confirmed via regression suite and
 * Chromium render at 390/393/430/768px (this pass) and 1024/1440/1728px
 * (desktop re-run) before packaging.
 *
 * This environment has no live browser access to independently inspect
 * the real mobile DOM/computed styles, so - exactly like the v1.0.24
 * footer-logo fix and the v1.0.25 express-checkout-button exclusion - the
 * three confirmed visual problems (beige mobile header, default-Woo
 * account nav, dark old-Hostinger mobile footer) are addressed by tracing
 * this plugin's own existing render functions/selectors and WooCommerce
 * core's own stable template classes (woocommerce-MyAccount-navigation,
 * is-active, woocommerce-MyAccount-content - not anything Account Styling
 * adds, so this stays decoupled from that plugin's own internals) rather
 * than a fresh live Console check. A visual spot-check on a real device
 * at 390/393/430/768px is recommended after this lands.
 *
 * ================= PHASE M1 - mobile header ================= */
@media (max-width: 768px) {

	/* Beige mobile header background, confirmed live: the theme's own
	   .has-color-1-background-color utility class (the same one fixed at
	   desktop in v1.0.11) has never had a mobile-scoped override - only
	   the min-width:769px rule above touches it, so mobile has been
	   rendering the theme's own tan/beige color this whole time. Same
	   exact selector/value already proven at desktop, reused verbatim -
	   no new color invented. Scoped to body.woocommerce-account for this
	   first pass, matching the explicit "Start with My Account mobile"
	   instruction. */
	body.woocommerce-account div.wp-block-group.hostinger-ai-menu.has-color-1-background-color {
		background-color: rgba(255, 255, 255, 0.95) !important;
	}

	/* Width cage removal - the same confirmed desktop fix (v1.0.11),
	   reused at mobile. Only width/max-width are touched; the existing
	   2-column grid (logo / account+cart - the center nav column is
	   desktop-only, never inserted into this grid at mobile, and
	   .bvx-account-header-nav is independently force-hidden at this same
	   breakpoint since v1.0.12) and the current compact mobile header
	   height are both left completely alone, per explicit instruction not
	   to change the mobile structure or height this pass. */
	body.woocommerce-account .hostinger-ai-menu-wrapper {
		width: 100%;
		max-width: none;
	}
}

/* ================= PHASE M2 - My Account mobile nav/content =================
 * Targets only WooCommerce core's own stable My Account template classes
 * (woocommerce-MyAccount-navigation, the per-endpoint
 * woocommerce-MyAccount-navigation-link--* / is-active classes Woo core
 * itself adds via wc_get_account_menu_item_classes(), and
 * woocommerce-MyAccount-content) - never anything Account Styling may add
 * internally, so this stays fully decoupled from that plugin and cannot
 * conflict with it. The vertical <nav><ul><li><a> structure itself,
 * every href (wc_get_account_endpoint_url()), and the Log Out nonce are
 * all native Woo output - nothing here adds, removes, or reorders a
 * single element; only typography/spacing/color CSS on the existing
 * structure. !important is used throughout, matching this plugin's own
 * established pattern (v1.0.15-v1.0.20) of forcing properties that kept
 * losing to theme/global rules on specificity once confirmed live -
 * applied preemptively here since the same class of competing rule is
 * expected and this cannot be separately confirmed without live access;
 * flagged for a visual spot-check same as above. */
@media (max-width: 768px) {

	body.woocommerce-account .woocommerce-MyAccount-navigation {
		margin: 0 0 28px !important;
		padding: 0 !important;
	}

	body.woocommerce-account .woocommerce-MyAccount-navigation ul {
		list-style: none !important;
		margin: 0 !important;
		padding: 0 !important;
	}

	body.woocommerce-account .woocommerce-MyAccount-navigation ul li {
		border-bottom: 1px solid rgba(0, 0, 0, 0.08) !important;
	}

	body.woocommerce-account .woocommerce-MyAccount-navigation ul li:last-child {
		border-bottom: none !important;
	}

	body.woocommerce-account .woocommerce-MyAccount-navigation ul li a {
		display: block !important;
		padding: 14px 4px !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 11px !important;
		font-weight: 400 !important;
		letter-spacing: 1.5px !important;
		text-transform: uppercase !important;
		color: #0A0A0A !important;
		opacity: 0.5;
		text-decoration: none !important;
		border-left: 2px solid transparent;
		line-height: normal !important;
	}

	/* Active endpoint - Woo core adds "is-active" to the <li> of the
	   current endpoint (wc_get_account_menu_item_classes()), never to
	   customer-logout. Full opacity + BVX sulphur accent, matching the
	   same accent color already established on the desktop header nav
	   (.bvx-account-header-nav-link.is-active). */
	body.woocommerce-account .woocommerce-MyAccount-navigation ul li.is-active a {
		opacity: 1;
		border-left-color: #BCFF00;
		padding-left: 12px !important;
	}

	/* Content breathing room - comfortable side padding, more gap below
	   the nav, no change to any field/table/button inside (account
	   functionality, address forms, order tables, download links, Woo
	   Blocks components inside account content are all untouched -
	   layout spacing only on the outer wrapper). box-sizing guards
	   against any fixed-width child ever causing horizontal overflow. */
	body.woocommerce-account .woocommerce-MyAccount-content {
		padding: 0 20px 40px !important;
		box-sizing: border-box !important;
		max-width: 100% !important;
	}
}

/* ================= PHASE M3 - My Account mobile footer =================
 * Replaces the mobile My Account footer's visible OLD Hostinger content
 * (dark background, trans-contacts/trans-socials column, the original
 * newsletter heading, and the original bottom block - which, since
 * transformation 1 swaps every core/site-title block sitewide with no
 * location gating, is also where the confirmed "old footer chameleon"
 * was rendering on mobile, alongside the old "(c) 2024" copyright text)
 * with the SAME BVX footer system already proven at desktop - no second
 * design. Every element below is the exact same PHP-rendered markup
 * already used at min-width:769px (bvx_shop_chrome_render_footer_content_row()/
 * bvx_shop_chrome_render_footer_bottom(), the newsletter eyebrow/heading/
 * desc insertion, and the real Hostinger Reach form) - this block only
 * reveals it and lays it out as one column, reusing the desktop
 * typography values verbatim where noted and scaling only where a 1320px
 * desktop measurement would not fit a mobile viewport (e.g. the
 * newsletter heading's 60.8px desktop size, or the 88px desktop newsletter
 * padding). The confirmed DOM order (newsletter column, then the content
 * row's brand block [BVX LONDON, Captain Croak paragraph, WhatsApp Us,
 * IG/TT/WA], then SHOP, then INFO, then the bottom legal strip) already
 * matches the required mobile order exactly, so no PHP reordering is
 * needed - only display/layout.
 */
@media (max-width: 768px) {

	/* ---- Hide old Hostinger mobile footer content (My Account only) ---- */

	/* col 1 - trans-contacts/trans-socials. Column 0 (empty heading/nav)
	   is already hidden sitewide at this breakpoint since v1.0.7/v1.0.0 -
	   untouched, no new rule needed for it. */
	body.woocommerce-account footer.site-footer .wp-block-columns.alignwide > .wp-block-column:nth-child(2) {
		display: none !important;
	}

	/* Original newsletter heading (trans-newsletter) - swapped for the
	   BVX eyebrow/heading/desc below, exactly like the existing desktop
	   swap (.bvx-newsletter-original already exists and is untouched
	   markup/text; only display is toggled). */
	body.woocommerce-account footer.site-footer .bvx-newsletter-original {
		display: none !important;
	}

	/* Original bottom block - old footer chameleon + old "(c) 2024"
	   copyright. UNTOUCHED markup, hidden only here - never affects
	   Cart/Checkout mobile or any non-account page. */
	body.woocommerce-account footer.site-footer > .wp-block-group.has-color-2-background-color > .wp-block-group.alignwide.is-content-justification-center {
		display: none !important;
	}

	/* ---- Reveal + reflow the BVX footer system, one column, #F7F7F7 ---- */

	/* Outer wrapper - same #F7F7F7 override already proven at desktop
	   against the theme's has-color-2-background-color utility class,
	   reused verbatim. padding:0 here because every section below now
	   carries its own ~20px side padding (newsletter column, content row,
	   bottom strip) - matching the ~20px side padding instruction - rather
	   than double-padding both the outer wrapper and each section. */
	body.woocommerce-account footer.site-footer > .wp-block-group.has-color-2-background-color {
		background: #F7F7F7 !important;
		padding: 0 !important;
	}

	/* Newsletter column - warm bone background, reused verbatim from the
	   desktop rule; padding scaled down from the desktop 88px/24px to a
	   mobile-appropriate 40px/20px, text-align:center kept (both already-
	   established, not newly invented). The real Hostinger Reach <form>
	   and its hidden fields/handlers inside this column are completely
	   untouched by this or any rule below - layout/typography only. */
	body.woocommerce-account footer.site-footer .wp-block-columns.alignwide > .wp-block-column.has-light-color {
		background: #FAF7F2;
		padding: 40px 20px;
		text-align: center;
	}

	/* Newsletter eyebrow/heading/desc - revealed from the sitewide
	   display:none default (same toggle already proven at desktop).
	   Typography reused verbatim where it already fits a mobile column
	   (eyebrow, desc font-family/weight/color/opacity); heading size
	   scaled down from the desktop 60.8px (which assumes a wide desktop
	   column) to 32px so it wraps cleanly in a narrow mobile column
	   without the responsive letter-spacing looking oversized - the only
	   two scaled values in this whole pass, both proportional to the
	   desktop figure (32/60.8 ~= 0.526, letter-spacing scaled by the same
	   ratio). */
	body.woocommerce-account .bvx-newsletter-eyebrow,
	body.woocommerce-account .bvx-newsletter-heading,
	body.woocommerce-account .bvx-newsletter-desc {
		display: block !important;
	}
	body.woocommerce-account .bvx-newsletter-eyebrow {
		font-family: "JetBrains Mono", monospace;
		font-size: 9.6px;
		font-weight: 300;
		letter-spacing: 2.88px;
		text-transform: uppercase;
		color: #0A0A0A;
		margin-bottom: 14px;
		line-height: normal;
	}
	body.woocommerce-account .bvx-newsletter-heading {
		font-family: "Inter Tight", sans-serif;
		font-size: 32px;
		font-weight: 900;
		letter-spacing: -0.96px;
		color: #0A0A0A;
		margin: 0 0 10px;
		line-height: normal;
	}
	body.woocommerce-account .bvx-newsletter-desc {
		font-family: "Inter", sans-serif;
		font-size: 14px;
		font-weight: 300;
		color: #0A0A0A;
		margin: 0 auto 28px;
		max-width: 320px;
		line-height: normal;
		opacity: 0.45;
	}

	/* Newsletter form - same confirmed Hostinger Reach selectors already
	   proven at desktop, un-capped from the fixed 460px desktop measure so
	   the row becomes full-width within the content column instead (per
	   explicit instruction). Every property below is layout/typography
	   only on the form's own already-confirmed classes/id - no element
	   added/removed/reparented, and the hidden fields, submit handler,
	   validation, and .reach-subscription-message markup are exactly as
	   untouched as they are at desktop. */
	body.woocommerce-account footer.site-footer .hostinger-reach-block-subscription-form-wrapper {
		max-width: 100%;
		margin: 0;
	}
	body.woocommerce-account footer.site-footer .hostinger-reach-block-form-fields {
		display: flex;
		flex-direction: row;
		align-items: stretch;
		box-sizing: border-box;
		width: 100%;
		height: 43px;
		margin: 0;
		border-bottom: 1px solid rgba(0, 0, 0, 0.2);
		background: transparent;
	}
	body.woocommerce-account footer.site-footer .hostinger-reach-block-form-field {
		flex: 1;
		min-width: 0;
		display: flex;
		align-items: center;
	}
	body.woocommerce-account footer.site-footer #ai-theme-footer-form .hostinger-reach-block-form-field {
		height: 42px !important;
		margin-top: 0 !important;
	}
	body.woocommerce-account footer.site-footer #ai-theme-footer-form label {
		position: absolute;
		width: 1px;
		height: 1px;
		padding: 0;
		margin: -1px;
		overflow: hidden;
		clip: rect(0, 0, 0, 0);
		white-space: nowrap;
		border: 0;
	}
	body.woocommerce-account footer.site-footer #ai-theme-footer-form input#ai-theme-footer-form-email {
		width: 100%;
		min-width: 0;
		padding: 12px 0;
		margin: 0;
		border: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 13px !important;
		font-weight: 400 !important;
		letter-spacing: 0.5px !important;
	}
	body.woocommerce-account footer.site-footer #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder {
		color: rgba(0, 0, 0, 0.35);
	}
	body.woocommerce-account footer.site-footer .hostinger-reach-block-submit {
		flex: 0 0 auto;
		width: auto !important;
		height: auto !important;
		padding: 12px 0 12px 14px !important;
		margin: 0 !important;
		border: 0 !important;
		border-radius: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.5px !important;
		font-weight: 400 !important;
		letter-spacing: 1.8px !important;
		text-transform: uppercase;
	}
	body.woocommerce-account footer.site-footer .hostinger-reach-block-submit::after {
		content: " \2192"; /* -> */
	}
	body.woocommerce-account footer.site-footer .reach-subscription-message {
		max-width: 100%;
		margin: 10px 0 0;
	}

	/* BVX content row - single column stack. A thin top border reuses the
	   same separator motif the desktop version already draws (there via
	   a ::before viewport-breakout pseudo-element; here as a plain
	   border-top, since the row is already edge-aligned by its own 20px
	   padding at this width, so no breakout technique is needed) - not a
	   new visual element, the same divider already established. */
	body.woocommerce-account .bvx-footer-content-row {
		display: block !important;
		padding: 32px 20px 0;
		margin: 0 !important;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
	}
	body.woocommerce-account .bvx-footer-brand,
	body.woocommerce-account .bvx-footer-shop,
	body.woocommerce-account .bvx-footer-info {
		margin-bottom: 32px;
	}

	/* BVX LONDON - Inter Tight/900 reused verbatim; size scaled down from
	   the desktop 22.4px to 20px, a proportionally small adjustment for a
	   narrower mobile column (not a new typographic treatment). */
	body.woocommerce-account .bvx-footer-brand-name {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 20px;
		font-weight: 900 !important;
		letter-spacing: -0.4px;
		color: #0A0A0A;
		margin: 0 0 8px;
		line-height: normal !important;
	}
	/* Captain Croak paragraph - Inter/low opacity reused verbatim (size
	   12px vs desktop 12.48px, line-height 1.6 vs desktop 1.65 - both
	   negligible rounding for a mobile column, not a new value system);
	   max-width scaled down from the desktop 240px to 280px is actually
	   slightly WIDER here since the mobile column itself is already
	   narrower than desktop's 680px brand column, so no extra wrap
	   constraint is needed beyond the column's own width. */
	body.woocommerce-account .bvx-footer-brand-copy {
		font-family: "Inter", sans-serif;
		font-size: 12px;
		font-weight: 300;
		line-height: 1.6 !important;
		opacity: 0.35;
		margin: 0 0 16px;
		max-width: 280px;
	}
	/* WhatsApp Us - every property reused verbatim from the confirmed
	   desktop spec (green border/background/color, icon fill, padding,
	   typography) - no mobile scaling needed, it already reads cleanly at
	   this size. */
	body.woocommerce-account .bvx-footer-whatsapp-us {
		display: inline-flex;
		align-items: center;
		gap: 8px;
		width: auto;
		background: rgba(37, 211, 102, 0.08);
		padding: 10px 14px;
		margin: 0 0 14px;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		letter-spacing: 0.928px;
		color: #25D366 !important;
		border: 1px solid rgba(37, 211, 102, 0.25);
		text-decoration: none !important;
	}
	body.woocommerce-account .bvx-footer-whatsapp-us svg {
		width: 14px;
		height: 14px;
		flex-shrink: 0;
	}
	body.woocommerce-account .bvx-footer-whatsapp-us svg,
	body.woocommerce-account .bvx-footer-whatsapp-us svg path {
		fill: currentColor !important;
	}
	/* IG/TT/WA - 34x34, every property reused verbatim; no mobile
	   adjustment needed, per the "unless they need slight mobile
	   adjustment" allowance - they don't. */
	body.woocommerce-account .bvx-footer-socials {
		display: flex;
		gap: 8px;
	}
	body.woocommerce-account .bvx-footer-socials a {
		box-sizing: border-box;
		width: 34px;
		height: 34px;
		display: flex;
		align-items: center;
		justify-content: center;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		color: #0A0A0A;
		opacity: 0.6;
		text-decoration: none !important;
		border: 1px solid rgba(0, 0, 0, 0.15);
	}
	/* SHOP/INFO headings - reused verbatim from the confirmed desktop
	   spec (JetBrains Mono/700/9.28px/2.32px/opacity:.35). */
	body.woocommerce-account .bvx-footer-col-heading {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.28px !important;
		font-weight: 700 !important;
		letter-spacing: 2.32px !important;
		line-height: normal;
		text-transform: uppercase;
		opacity: 0.35;
		margin: 0 0 14px;
	}
	/* Footer links (SHOP/INFO items, incl. the one real "Contact" link) -
	   reused verbatim. */
	body.woocommerce-account .bvx-footer-shop a,
	body.woocommerce-account .bvx-footer-info a,
	body.woocommerce-account .bvx-footer-link-text {
		font-family: "Inter", sans-serif;
		font-size: 12.8px;
		font-weight: 300;
		opacity: 0.6;
		color: #0A0A0A;
		text-decoration: none;
	}
	body.woocommerce-account .bvx-footer-shop ul,
	body.woocommerce-account .bvx-footer-info ul {
		list-style: none;
		margin: 0;
		padding-left: 0;
	}
	body.woocommerce-account .bvx-footer-shop li,
	body.woocommerce-account .bvx-footer-info li {
		margin-bottom: 10px;
	}

	/* Legal strip - stacked (column) instead of desktop's
	   space-between row, since copyright + tagline side-by-side would be
	   tight on a narrow mobile viewport; typography reused verbatim
	   (JetBrains Mono/opacity:.25), only size nudged down slightly
	   (8.96px -> 8.5px) to match the rest of this pass's small mobile
	   scaling allowance. */
	body.woocommerce-account .bvx-footer-bottom {
		display: flex !important;
		flex-direction: column;
		align-items: flex-start;
		gap: 6px;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
		margin: 0 !important;
		padding: 18px 20px 28px;
	}
	body.woocommerce-account .bvx-footer-copyright,
	body.woocommerce-account .bvx-footer-tagline {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 8.5px;
		font-weight: 300;
		letter-spacing: 0.85px;
		text-transform: uppercase;
		opacity: 0.25;
		margin: 0;
		line-height: normal !important;
	}
}


/*
 * v1.0.27 - Cart + Checkout MOBILE chrome pass (Phase M4-M5), extending
 * the now-approved v1.0.26 My Account mobile reference implementation to
 * body.woocommerce-cart and body.woocommerce-checkout. CSS-only, no PHP
 * change - exactly like v1.0.26, every element below already exists in
 * the rendered DOM today (the same bvx_shop_chrome_render_footer_content_row()/
 * bvx_shop_chrome_render_footer_bottom() output and newsletter eyebrow/
 * heading/desc insertion already run on Checkout/Cart via the existing
 * is_checkout()||is_cart()-gated transformation 6b, confirmed live
 * identical to My Account/shop's footer structure except for the
 * confirmed footer root element - see below). This pass only reveals/
 * restyles it inside NEW @media (max-width: 768px) blocks, added
 * entirely separately from v1.0.26's own My Account mobile rules (same
 * precedent as v1.0.21, which added a wholly separate desktop block for
 * checkout/cart rather than editing the account block's selectors) - not
 * one existing v1.0.26 selector is touched, so My Account mobile cannot
 * regress. Desktop (@media min-width: 769px) is completely untouched for
 * every page.
 *
 * Confirmed structural difference from My Account/shop, already
 * established in v1.0.21/v1.0.23/v1.0.24 above: Checkout/Cart's footer
 * is <footer class="wp-block-template-part"> (no site-footer token),
 * wrapping the same .wp-block-group.has-color-2-background-color >
 * .wp-block-columns.alignwide structure (col 0 empty, col 1 contacts/
 * socials, col 2 newsletter) - so every footer-rooted selector below uses
 * footer.wp-block-template-part instead of footer.site-footer, mirroring
 * exactly how the existing min-width:769px checkout/cart block already
 * mirrors the account/shop block. Confirmed in the same v1.0.21 PHP
 * changelog: unlike account/shop, Checkout/Cart's outer footer group has
 * NO second "original bottom block" sibling to anchor on - the content
 * row/bottom strip are inserted as its LAST child instead - so there is
 * no old chameleon/old "(c) 2024" bottom block to hide here; it simply
 * does not exist on these two pages. The extra footer chameleon that DID
 * exist on Checkout/Cart (a different bug, inside the header/footer
 * site-title swap - transformation 1) was already fixed in v1.0.24 with
 * an unscoped-by-breakpoint suppression rule, so it is already hidden at
 * every width including mobile - nothing new needed here.
 *
 * Same standing caveat as v1.0.24/v1.0.25/v1.0.26: no live browser access
 * in this environment, so this is built from the plugin's own confirmed
 * render functions/selectors (the same ones the existing, already-shipped
 * min-width:769px checkout/cart block already uses successfully) rather
 * than a fresh live Console check. A visual spot-check at
 * 390/393/430/768px on Cart and Checkout is recommended after this lands.
 * Validated via PHP regression suite (no functional/PHP change) and
 * headless-Chromium render at 390/393/430/768px (new mobile rules, both
 * pages) and 1024/1440/1728px (desktop regression, confirming zero
 * change) before packaging. Preserved throughout: My Account mobile
 * (v1.0.26, byte-identical), desktop Checkout/Cart/My Account (every
 * min-width:769px rule, byte-identical), cart product rows/quantity
 * controls/coupon logic, checkout fields/shipping/payment/express
 * checkout/order summary, Cart Bridge, Account Styling, Hostinger Reach
 * functionality, the cart badge, and the account/cart icons.
 *
 * ================= PHASE M4 - Cart + Checkout mobile header =================
 * Reuses the exact v1.0.26 My Account mobile header fix - same confirmed
 * white/95% value, same cage-removal technique - on the same
 * .hostinger-ai-menu-wrapper/.hostinger-ai-menu-scoped markup already
 * confirmed identical across My Account/Checkout/Cart (v1.0.21/v1.0.23).
 * No account nav exists on Checkout/Cart (that nav is is_account_page()-
 * gated and never inserted here, at any breakpoint), so there is nothing
 * equivalent to hide - Phase M2 has no Checkout/Cart counterpart.
 */
@media (max-width: 768px) {

	body.woocommerce-checkout div.wp-block-group.hostinger-ai-menu.has-color-1-background-color,
	body.woocommerce-cart div.wp-block-group.hostinger-ai-menu.has-color-1-background-color {
		background-color: rgba(255, 255, 255, 0.95) !important;
	}

	body.woocommerce-checkout .hostinger-ai-menu-wrapper,
	body.woocommerce-cart .hostinger-ai-menu-wrapper {
		width: 100%;
		max-width: none;
	}
}

/* ================= PHASE M5 - Cart + Checkout mobile footer =================
 * Reuses the exact v1.0.26 My Account mobile footer system - same hide/
 * reveal targets, same one-column reflow, same typography/spacing/
 * background values, same confirmed DOM order (newsletter -> brand block
 * [BVX LONDON, Captain Croak paragraph, WhatsApp Us, IG/TT/WA] -> SHOP ->
 * INFO -> bottom legal strip) - only the footer-root selector changes
 * from footer.site-footer to footer.wp-block-template-part, matching the
 * one confirmed structural difference already established above. No
 * second mobile design, no new typography value, and no new PHP - purely
 * the same CSS targets re-scoped to these two pages' confirmed footer
 * root.
 */
@media (max-width: 768px) {

	/* ---- Hide old Hostinger mobile footer content ---- */

	/* col 1 - trans-contacts/trans-socials. Column 0 (empty heading/nav)
	   is already hidden sitewide at this breakpoint since v1.0.7/v1.0.0 -
	   untouched, no new rule needed for it. */
	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:nth-child(2),
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column:nth-child(2) {
		display: none !important;
	}

	/* Original newsletter heading (trans-newsletter) - swapped for the
	   BVX eyebrow/heading/desc below, exactly like My Account. */
	body.woocommerce-checkout footer.wp-block-template-part .bvx-newsletter-original,
	body.woocommerce-cart footer.wp-block-template-part .bvx-newsletter-original {
		display: none !important;
	}

	/* No "original bottom block" rule here - confirmed in v1.0.21 above,
	   Checkout/Cart's footer has no such sibling element to hide. The
	   extra footer chameleon that DOES exist on these two pages is a
	   different, already-fixed issue (v1.0.24, unscoped by breakpoint -
	   already hidden at this width too). */

	/* ---- Reveal + reflow the BVX footer system, one column, #F7F7F7 ---- */

	body.woocommerce-checkout footer.wp-block-template-part > .wp-block-group.has-color-2-background-color,
	body.woocommerce-cart footer.wp-block-template-part > .wp-block-group.has-color-2-background-color {
		background: #F7F7F7 !important;
		padding: 0 !important;
	}

	body.woocommerce-checkout footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column.has-light-color,
	body.woocommerce-cart footer.wp-block-template-part .wp-block-columns.alignwide > .wp-block-column.has-light-color {
		background: #FAF7F2;
		padding: 40px 20px;
		text-align: center;
	}

	body.woocommerce-checkout .bvx-newsletter-eyebrow,
	body.woocommerce-cart .bvx-newsletter-eyebrow,
	body.woocommerce-checkout .bvx-newsletter-heading,
	body.woocommerce-cart .bvx-newsletter-heading,
	body.woocommerce-checkout .bvx-newsletter-desc,
	body.woocommerce-cart .bvx-newsletter-desc {
		display: block !important;
	}
	body.woocommerce-checkout .bvx-newsletter-eyebrow,
	body.woocommerce-cart .bvx-newsletter-eyebrow {
		font-family: "JetBrains Mono", monospace;
		font-size: 9.6px;
		font-weight: 300;
		letter-spacing: 2.88px;
		text-transform: uppercase;
		color: #0A0A0A;
		margin-bottom: 14px;
		line-height: normal;
	}
	body.woocommerce-checkout .bvx-newsletter-heading,
	body.woocommerce-cart .bvx-newsletter-heading {
		font-family: "Inter Tight", sans-serif;
		font-size: 32px;
		font-weight: 900;
		letter-spacing: -0.96px;
		color: #0A0A0A;
		margin: 0 0 10px;
		line-height: normal;
	}
	body.woocommerce-checkout .bvx-newsletter-desc,
	body.woocommerce-cart .bvx-newsletter-desc {
		font-family: "Inter", sans-serif;
		font-size: 14px;
		font-weight: 300;
		color: #0A0A0A;
		margin: 0 auto 28px;
		max-width: 320px;
		line-height: normal;
		opacity: 0.45;
	}

	/* Newsletter form - same confirmed Hostinger Reach selectors already
	   proven at both My Account mobile (v1.0.26) and Checkout/Cart
	   desktop, un-capped from the fixed 460px desktop measure. The form's
	   hidden fields, submit handler, validation, and
	   .reach-subscription-message markup are completely untouched. */
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-subscription-form-wrapper,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-subscription-form-wrapper {
		max-width: 100%;
		margin: 0;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-form-fields,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-form-fields {
		display: flex;
		flex-direction: row;
		align-items: stretch;
		box-sizing: border-box;
		width: 100%;
		height: 43px;
		margin: 0;
		border-bottom: 1px solid rgba(0, 0, 0, 0.2);
		background: transparent;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-form-field,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-form-field {
		flex: 1;
		min-width: 0;
		display: flex;
		align-items: center;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form .hostinger-reach-block-form-field,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form .hostinger-reach-block-form-field {
		height: 42px !important;
		margin-top: 0 !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form label,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form label {
		position: absolute;
		width: 1px;
		height: 1px;
		padding: 0;
		margin: -1px;
		overflow: hidden;
		clip: rect(0, 0, 0, 0);
		white-space: nowrap;
		border: 0;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email {
		width: 100%;
		min-width: 0;
		padding: 12px 0;
		margin: 0;
		border: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 13px !important;
		font-weight: 400 !important;
		letter-spacing: 0.5px !important;
	}
	body.woocommerce-checkout footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder,
	body.woocommerce-cart footer.wp-block-template-part #ai-theme-footer-form input#ai-theme-footer-form-email::placeholder {
		color: rgba(0, 0, 0, 0.35);
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-submit,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-submit {
		flex: 0 0 auto;
		width: auto !important;
		height: auto !important;
		padding: 12px 0 12px 14px !important;
		margin: 0 !important;
		border: 0 !important;
		border-radius: 0 !important;
		background: transparent !important;
		color: #0A0A0A !important;
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.5px !important;
		font-weight: 400 !important;
		letter-spacing: 1.8px !important;
		text-transform: uppercase;
	}
	body.woocommerce-checkout footer.wp-block-template-part .hostinger-reach-block-submit::after,
	body.woocommerce-cart footer.wp-block-template-part .hostinger-reach-block-submit::after {
		content: " \2192"; /* -> */
	}
	body.woocommerce-checkout footer.wp-block-template-part .reach-subscription-message,
	body.woocommerce-cart footer.wp-block-template-part .reach-subscription-message {
		max-width: 100%;
		margin: 10px 0 0;
	}

	/* BVX content row - single column stack, same thin top-border
	   separator motif as My Account mobile. */
	body.woocommerce-checkout .bvx-footer-content-row,
	body.woocommerce-cart .bvx-footer-content-row {
		display: block !important;
		padding: 32px 20px 0;
		margin: 0 !important;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
	}
	body.woocommerce-checkout .bvx-footer-brand,
	body.woocommerce-cart .bvx-footer-brand,
	body.woocommerce-checkout .bvx-footer-shop,
	body.woocommerce-cart .bvx-footer-shop,
	body.woocommerce-checkout .bvx-footer-info,
	body.woocommerce-cart .bvx-footer-info {
		margin-bottom: 32px;
	}

	/* BVX LONDON/Captain Croak are <p> elements, and SHOP/INFO headings
	   are <h3> elements - Checkout/Cart's confirmed-live competing theme
	   rules on these tags are stronger than My Account's (already
	   established in the v1.0.21 round-2 desktop fix: Montserrat
	   paragraph and Junge h3 defaults there needed EVERY property forced
	   with !important, not just the ones losing on My Account). This
	   mobile extension reuses that same full-!important treatment,
	   already proven live on these two pages at desktop, rather than the
	   lighter v1.0.26 My Account mobile version - diverging from v1.0.26
	   intentionally here, matching the one page-specific difference the
	   desktop block already establishes. */
	body.woocommerce-checkout .bvx-footer-brand-name,
	body.woocommerce-cart .bvx-footer-brand-name {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 20px !important;
		font-weight: 900 !important;
		letter-spacing: -0.4px !important;
		color: #0A0A0A !important;
		margin: 0 0 8px !important;
		line-height: normal !important;
	}
	body.woocommerce-checkout .bvx-footer-brand-copy,
	body.woocommerce-cart .bvx-footer-brand-copy {
		font-family: "Inter", sans-serif !important;
		font-size: 12px !important;
		font-weight: 300 !important;
		line-height: 1.6 !important;
		opacity: 0.35 !important;
		margin: 0 0 16px !important;
		max-width: 280px !important;
	}
	body.woocommerce-checkout .bvx-footer-whatsapp-us,
	body.woocommerce-cart .bvx-footer-whatsapp-us {
		display: inline-flex;
		align-items: center;
		gap: 8px;
		width: auto;
		background: rgba(37, 211, 102, 0.08);
		padding: 10px 14px;
		margin: 0 0 14px;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		letter-spacing: 0.928px;
		color: #25D366 !important;
		border: 1px solid rgba(37, 211, 102, 0.25);
		text-decoration: none !important;
	}
	body.woocommerce-checkout .bvx-footer-whatsapp-us svg,
	body.woocommerce-cart .bvx-footer-whatsapp-us svg {
		width: 14px;
		height: 14px;
		flex-shrink: 0;
	}
	body.woocommerce-checkout .bvx-footer-whatsapp-us svg,
	body.woocommerce-cart .bvx-footer-whatsapp-us svg,
	body.woocommerce-checkout .bvx-footer-whatsapp-us svg path,
	body.woocommerce-cart .bvx-footer-whatsapp-us svg path {
		fill: currentColor !important;
	}
	body.woocommerce-checkout .bvx-footer-socials,
	body.woocommerce-cart .bvx-footer-socials {
		display: flex;
		gap: 8px;
	}
	body.woocommerce-checkout .bvx-footer-socials a,
	body.woocommerce-cart .bvx-footer-socials a {
		box-sizing: border-box;
		width: 34px;
		height: 34px;
		display: flex;
		align-items: center;
		justify-content: center;
		font-family: "JetBrains Mono", monospace;
		font-size: 9.28px;
		font-weight: 300;
		color: #0A0A0A;
		opacity: 0.6;
		text-decoration: none !important;
		border: 1px solid rgba(0, 0, 0, 0.15);
	}
	body.woocommerce-checkout .bvx-footer-col-heading,
	body.woocommerce-cart .bvx-footer-col-heading {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 9.28px !important;
		font-weight: 700 !important;
		letter-spacing: 2.32px !important;
		line-height: normal !important;
		text-transform: uppercase;
		opacity: 0.35 !important;
		margin: 0 0 14px !important;
	}
	body.woocommerce-checkout .bvx-footer-shop a,
	body.woocommerce-cart .bvx-footer-shop a,
	body.woocommerce-checkout .bvx-footer-info a,
	body.woocommerce-cart .bvx-footer-info a,
	body.woocommerce-checkout .bvx-footer-link-text,
	body.woocommerce-cart .bvx-footer-link-text {
		font-family: "Inter", sans-serif;
		font-size: 12.8px;
		font-weight: 300;
		opacity: 0.6;
		color: #0A0A0A;
		text-decoration: none;
	}
	body.woocommerce-checkout .bvx-footer-shop ul,
	body.woocommerce-cart .bvx-footer-shop ul,
	body.woocommerce-checkout .bvx-footer-info ul,
	body.woocommerce-cart .bvx-footer-info ul {
		list-style: none;
		margin: 0;
		padding-left: 0;
	}
	body.woocommerce-checkout .bvx-footer-shop li,
	body.woocommerce-cart .bvx-footer-shop li,
	body.woocommerce-checkout .bvx-footer-info li,
	body.woocommerce-cart .bvx-footer-info li {
		margin-bottom: 10px;
	}

	body.woocommerce-checkout .bvx-footer-bottom,
	body.woocommerce-cart .bvx-footer-bottom {
		display: flex !important;
		flex-direction: column;
		align-items: flex-start;
		gap: 6px;
		border-top: 1px solid rgba(0, 0, 0, 0.1);
		margin: 0 !important;
		padding: 18px 20px 28px;
	}
	body.woocommerce-checkout .bvx-footer-copyright,
	body.woocommerce-cart .bvx-footer-copyright,
	body.woocommerce-checkout .bvx-footer-tagline,
	body.woocommerce-cart .bvx-footer-tagline {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 8.5px !important;
		font-weight: 300 !important;
		letter-spacing: 0.85px !important;
		text-transform: uppercase;
		opacity: 0.25 !important;
		margin: 0 !important;
		line-height: normal !important;
	}
}

/*
 * v1.0.28 - Mobile Cart Body Polish, CSS-only, no PHP change. Scoped
 * entirely to body.woocommerce-cart inside @media (max-width: 768px).
 * Does not touch: Checkout, My Account, any desktop (min-width:769px)
 * rule, or any v1.0.26/v1.0.27 mobile chrome (header/footer/newsletter/
 * chameleon-suppression) selector above. This is the first pass in this
 * plugin that styles Cart BODY content rather than chrome.
 *
 * STANDING CAVEAT (stronger than prior rounds): no live browser access
 * in this environment, and no user-supplied confirmed live computed
 * values for this specific round (unlike the v1.0.25 Checkout body
 * pass). Every selector below is a well-known, stable WooCommerce
 * Blocks Cart class name (wc-block-cart-item*, wc-block-components-*,
 * the generic block-theme wp-block-post-title), not a value confirmed
 * via live Console inspection on shop.wearbvx.com. Confidence is noted
 * per-section. A live visual spot-check at 390/393/430/768px is
 * strongly recommended before treating this as final.
 */
@media (max-width: 768px) {

	/* ---- 1) Page title ----
	   Hostinger AI theme is a block/FSE theme; the Cart page template
	   renders a generic Core "Post Title" block above the Woo Blocks
	   Cart block. Targeting the two standard markup shapes a block
	   theme uses for this (wp-block-post-title, and the classic
	   entry-title fallback some block templates still emit), scoped
	   to the FIRST such heading only via :first-of-type, so a heading
	   inside totals/coupon/payment/footer is never affected (those are
	   h2/h3 and/or not the page's first heading). Confidence: MEDIUM -
	   this is the standard WordPress block-theme pattern, not a
	   site-specific confirmed class. */
	body.woocommerce-cart main h1.wp-block-post-title:first-of-type,
	body.woocommerce-cart main .entry-title:first-of-type,
	body.woocommerce-cart main h1.entry-title:first-of-type {
		display: none !important;
	}
	/* Remove the gap the hidden title leaves behind so the first
	   product row sits directly under the mobile header, matching the
	   M4/M5 chrome above. Targets the title's own wrapping group when
	   the theme wraps it (common FSE pattern) and the main content
	   area's own top spacing - not the cart items/totals themselves. */
	body.woocommerce-cart main > .wp-block-group:has(> h1.wp-block-post-title),
	body.woocommerce-cart main > .wp-block-post-title {
		margin: 0 !important;
		padding: 0 !important;
	}
	body.woocommerce-cart main {
		padding-top: 0 !important;
	}

	/* ---- 2) Product row ----
	   Confidence: MEDIUM. wc-block-cart-item(s) and the Product Name/
	   Price/Metadata component classes are stable, documented
	   WooCommerce Blocks class names used across both the table-based
	   and flex-based Cart layouts. No product link, image src, or data
	   attribute is touched - typography/spacing/alignment only. */
	body.woocommerce-cart .wc-block-cart-items {
		font-size: 13px;
	}
	body.woocommerce-cart .wc-block-cart-item,
	body.woocommerce-cart .wc-block-cart-items__row {
		padding: 16px 0 !important;
		border-bottom: 1px solid rgba(0, 0, 0, 0.08) !important;
		align-items: flex-start !important;
	}
	body.woocommerce-cart .wc-block-cart-item__image,
	body.woocommerce-cart .wc-block-cart-items__row .wc-block-cart-item__image {
		width: 84px !important;
		min-width: 84px !important;
	}
	body.woocommerce-cart .wc-block-cart-item__image img {
		border-radius: 2px;
	}
	body.woocommerce-cart .wc-block-cart-item__product,
	body.woocommerce-cart .wc-block-cart-item__description {
		padding-left: 14px !important;
	}
	body.woocommerce-cart .wc-block-components-product-name {
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
		font-weight: 500 !important;
		line-height: 1.35 !important;
		color: #0A0A0A !important;
		text-decoration: none !important;
		margin: 0 0 4px !important;
		display: block;
	}
	body.woocommerce-cart .wc-block-components-product-metadata {
		font-family: "Inter", sans-serif !important;
		font-size: 11px !important;
		font-weight: 300 !important;
		opacity: 0.45 !important;
		line-height: 1.4 !important;
		margin: 0 0 8px !important;
	}
	body.woocommerce-cart .wc-block-components-product-price,
	body.woocommerce-cart .wc-block-components-formatted-money-amount {
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
		font-weight: 400 !important;
		color: #0A0A0A !important;
	}
	body.woocommerce-cart .wc-block-cart-item__prices {
		margin-top: 4px !important;
	}

	/* ---- 3) Quantity + remove controls ----
	   Confidence: MEDIUM. Spacing/sizing only - Woo's own +/- buttons,
	   number input, and remove-link markup/icons/handlers untouched. */
	body.woocommerce-cart .wc-block-components-quantity-selector {
		height: 34px !important;
		align-items: center !important;
		border-radius: 2px;
	}
	body.woocommerce-cart .wc-block-components-quantity-selector__button {
		width: 28px !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
	}
	body.woocommerce-cart .wc-block-components-quantity-selector__input {
		text-align: center !important;
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
	}
	body.woocommerce-cart .wc-block-cart-item__quantity {
		display: flex;
		align-items: center;
		gap: 14px;
		margin-top: 10px !important;
	}
	body.woocommerce-cart .wc-block-cart-item__remove-link {
		font-family: "Inter", sans-serif !important;
		font-size: 11px !important;
		opacity: 0.5 !important;
		text-decoration: none !important;
	}

	/* ---- 4) Coupon row ----
	   Confidence: MEDIUM. wc-block-components-totals-coupon and the
	   shared accordion panel classes are stable Woo Blocks names. The
	   accordion's own expand/collapse behavior is untouched - spacing/
	   typography/divider only. */
	body.woocommerce-cart .wc-block-components-totals-coupon {
		margin: 18px 0 !important;
		padding-top: 16px !important;
		border-top: 1px solid rgba(0, 0, 0, 0.08) !important;
	}
	body.woocommerce-cart .wc-block-components-totals-coupon .wc-block-components-panel__button {
		font-family: "Inter", sans-serif !important;
		font-size: 12px !important;
		opacity: 0.6 !important;
	}
	body.woocommerce-cart .wc-block-components-totals-coupon .wc-block-components-totals-coupon__input,
	body.woocommerce-cart .wc-block-components-totals-coupon .wc-block-components-totals-coupon__button {
		font-family: "Inter", sans-serif !important;
		font-size: 12px !important;
	}

	/* ---- 5) Totals hierarchy ----
	   Confidence: MEDIUM. wc-block-components-totals-item (Subtotal/
	   Shipping) and wc-block-components-totals-footer-item (the final
	   total row) are the two stable Woo Blocks class names used to
	   distinguish ordinary rows from the final total row. All price
	   values/calculations are rendered by Woo exactly as before -
	   typography only. */
	body.woocommerce-cart .wc-block-components-totals-item {
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
		padding: 8px 0 !important;
	}
	body.woocommerce-cart .wc-block-components-totals-item__label {
		font-weight: 400 !important;
		opacity: 0.7;
	}
	body.woocommerce-cart .wc-block-components-totals-item__value {
		font-weight: 400 !important;
	}
	body.woocommerce-cart .wc-block-components-totals-footer-item {
		border-top: 1px solid rgba(0, 0, 0, 0.1) !important;
		margin-top: 8px !important;
		padding-top: 14px !important;
	}
	body.woocommerce-cart .wc-block-components-totals-footer-item .wc-block-components-totals-item__label,
	body.woocommerce-cart .wc-block-components-totals-footer-item .wc-block-components-totals-item__value {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 15px !important;
		font-weight: 700 !important;
		opacity: 1 !important;
	}

	/* ---- 6) Klarna/Clearpay messaging ----
	   Intentionally NOT styled - zero confirmed selector for this
	   markup exists in this codebase, and no live inspection is
	   possible in this environment. No rule added for this item. */

	/* ---- 7) Express payment buttons ----
	   Confidence: LOW-MEDIUM on the wrapper class name; the individual
	   branded buttons (Amazon Pay/Google Pay/OneLink/Klarna/Clearpay)
	   are never selected - only the gap between them in the stack. */
	body.woocommerce-cart .wc-block-components-express-payment__event-buttons {
		display: flex !important;
		flex-direction: column !important;
		gap: 10px !important;
	}
	body.woocommerce-cart .wc-block-components-express-payment {
		margin: 18px 0 !important;
	}

	/* ---- 8) "OR" divider ----
	   Confidence: LOW-MEDIUM on the exact class name. Spacing only -
	   divider structure/function untouched. */
	body.woocommerce-cart .wc-block-components-express-payment-continue-rule {
		margin: 18px 0 !important;
	}
	body.woocommerce-cart .wc-block-components-express-payment-continue-rule__text {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 10px !important;
		letter-spacing: 1px;
		opacity: 0.4;
	}

	/* ---- 9) Proceed to Checkout ----
	   Confidence: MEDIUM. wc-block-cart__submit-button is the stable
	   Woo Blocks class for this button's wrapper/link. Typography only
	   - href, width logic, and click handler are Woo's own, untouched. */
	body.woocommerce-cart .wc-block-cart__submit-button,
	body.woocommerce-cart .wc-block-cart__submit-container .wc-block-components-button {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 12px !important;
		font-weight: 400 !important;
		letter-spacing: 1.5px !important;
		text-transform: uppercase !important;
		height: 48px !important;
	}
}

/*
 * v1.0.29 - Two Mobile Cart refinements on top of v1.0.28. Scoped entirely
 * to body.woocommerce-cart; desktop (769px+) and mobile header/footer are
 * completely untouched. See PHP changelog for full reasoning.
 */

/* ================= 1) Duplicate mobile divider fix ================= */
@media (max-width: 768px) {

	/* Remove v1.0.28's own per-row border from the LAST product row only
	   - every other row keeps its separator; only the one immediately
	   adjacent to the coupon section is removed, since that's the one
	   stacking with the lines below it. */
	body.woocommerce-cart .wc-block-cart-item:last-child,
	body.woocommerce-cart .wc-block-cart-items__row:last-child {
		border-bottom: none !important;
	}

	/* Force off whatever border the cart-items container and the
	   coupon panel's own top edge render by default (not confirmed
	   live - no browser access in this environment; this is a
	   defensive reset so the exact live combination can't leave a
	   second or third line here regardless of which rule was
	   responsible). */
	body.woocommerce-cart .wc-block-cart-items {
		border-bottom: none !important;
	}
	body.woocommerce-cart .wc-block-components-totals-coupon {
		border-top: none !important;
	}

	/* Exactly one clean divider, owned entirely by this rule, sitting
	   on the coupon row's own top edge - same neutral tone already used
	   throughout this plugin's mobile work. */
	body.woocommerce-cart .wc-block-components-totals-coupon {
		border-top: 1px solid rgba(0, 0, 0, 0.08) !important;
		padding-top: 16px !important;
	}
}

/* ================= 2) Mobile Cart scroll reveal ================= */
/*
 * Reuses the exact reveal mechanism already shipped on the wearbvx.com
 * frontend SPA (confirmed via its index.html): opacity 0 -> 1 +
 * translateY(36px) -> 0 over .9s ease, classes added by an
 * IntersectionObserver in bvx-shop-chrome-cart-reveal.js. Values here are
 * copied verbatim from the frontend's own .reveal / .reveal.visible rules
 * - nothing reinvented. Gated to mobile widths only, per this round's
 * scope; the JS adds .bvx-cart-reveal sitewide-on-Cart but it has no
 * visual effect outside this breakpoint since no other rule targets it.
 */
@media (max-width: 768px) {
	body.woocommerce-cart .bvx-cart-reveal {
		opacity: 0;
		transform: translateY(36px);
		transition: opacity 0.9s ease, transform 0.9s ease;
	}
	body.woocommerce-cart .bvx-cart-reveal.visible {
		opacity: 1;
		transform: translateY(0);
	}
}

/* Same prefers-reduced-motion handling as the frontend SPA - disables the
   animation/transition entirely rather than just speeding it up, so a
   reduced-motion visitor never sees the fade/slide at all. The JS also
   detects this directly and skips the observer, adding .visible
   immediately; this CSS rule is the belt-and-suspenders fallback. */
@media (prefers-reduced-motion: reduce) {
	body.woocommerce-cart .bvx-cart-reveal {
		transition-duration: 0.01ms !important;
		transform: none !important;
	}
}

/*
 * v1.0.30 - Mobile Checkout Body Polish, CSS+JS, no PHP logic change.
 * Scoped entirely to body.woocommerce-checkout inside
 * @media (max-width: 768px). Desktop (769px+), mobile header/footer
 * (v1.0.21/v1.0.27), and My Account/Cart mobile are completely
 * untouched - this pass does not add a single selector outside
 * body.woocommerce-checkout.
 *
 * CONFIDENCE NOTE: several selectors below reuse the v1.0.25 Checkout
 * body typography pass's CONFIRMED LIVE class names (h1,
 * .wc-block-components-checkout-step__title,
 * .wc-block-components-checkout-order-summary__title,
 * .wc-block-components-text-input/.wc-block-components-combobox-control
 * label/input, .wc-block-components-totals-item__*,
 * .wc-block-components-order-summary-item__*,
 * .wc-block-components-shipping-rates-control__package,
 * .wc-block-components-button) - these carry the SAME confidence as
 * v1.0.25 itself (confirmed live). Everything else (express-payment
 * wrapper/divider reused verbatim from the already-shipped Cart body
 * pass, secondary-control checkboxes, terms text, step container
 * spacing, shipping-rate radio/price alignment, order-summary toggle
 * panel) is NOT confirmed live on this specific site - same standing
 * caveat as v1.0.28/29: no live browser access in this environment. A
 * visual spot-check on Checkout mobile is recommended before this is
 * treated as final.
 *
 * "Top Order Summary" vs "Lower Order Summary" (per request items 2 and
 * 9): WooCommerce Blocks Checkout renders Order Summary as a single
 * component with a title/toggle area and an itemized breakdown
 * (product rows + coupon + totals) inside it - not two separate
 * component instances. This pass treats the title/toggle
 * (.wc-block-components-checkout-order-summary__title and its
 * containing panel) as "top" and the itemized breakdown (order-summary
 * items, coupon, totals rows, the final total) as "lower", which is
 * accurate to the DOM structure but is an assumption about which part
 * the live mobile layout visually pins to the top vs. lets flow below
 * Payment - flagged for the same reason as above.
 */
@media (max-width: 768px) {

	/* ================= 1) Page title ================= */
	/* body.woocommerce-checkout h1 is the CONFIRMED live selector for
	   the main "Checkout" title (v1.0.25 already styles it there -
	   Inter Tight/900 - at every breakpoint). Hiding it here cannot
	   catch a section heading, Order Summary heading, or Payment/
	   Shipping options heading - those are all h2 with their own
	   confirmed class (.wc-block-components-checkout-step__title /
	   .wc-block-components-checkout-order-summary__title), never h1. */
	body.woocommerce-checkout h1 {
		display: none !important;
	}
	body.woocommerce-checkout main {
		padding-top: 0 !important;
	}
	body.woocommerce-checkout .wc-block-checkout__main,
	body.woocommerce-checkout .wc-block-checkout__sidebar {
		margin-top: 0 !important;
	}

	/* ================= 2) Top Order Summary ================= */
	body.woocommerce-checkout .wc-block-components-checkout-order-summary__title {
		padding: 16px 0 !important;
		border-bottom: 1px solid rgba(0, 0, 0, 0.08) !important;
		margin: 0 0 16px !important;
	}
	body.woocommerce-checkout .wc-block-components-panel__button {
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
	}

	/* ================= 3) Express Checkout section ================= */
	/* Wrapper/divider classes reused verbatim from the already-shipped
	   Cart body pass (v1.0.28) - same shared Woo Blocks component,
	   same spacing-only treatment, branded button internals untouched. */
	body.woocommerce-checkout .wc-block-components-express-payment {
		margin: 20px 0 !important;
	}
	body.woocommerce-checkout .wc-block-components-express-payment__event-buttons {
		display: flex !important;
		flex-direction: column !important;
		gap: 10px !important;
	}
	body.woocommerce-checkout .wc-block-components-express-payment-continue-rule {
		margin: 20px 0 !important;
	}
	body.woocommerce-checkout .wc-block-components-express-payment-continue-rule__text {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 10px !important;
		letter-spacing: 1px;
		opacity: 0.4;
	}

	/* ================= 4) Contact information ================= */
	/* Typography mapping (Inter Tight heading / JetBrains Mono label /
	   Inter value) is already set, unscoped, by v1.0.25 above - this
	   pass only adds mobile spacing, it does not re-declare typography. */
	body.woocommerce-checkout .wc-block-components-checkout-step {
		padding: 20px 0 !important;
		border-bottom: 1px solid rgba(0, 0, 0, 0.08) !important;
	}
	body.woocommerce-checkout .wc-block-components-checkout-step__title {
		margin: 0 0 14px !important;
	}
	body.woocommerce-checkout .wc-block-components-text-input,
	body.woocommerce-checkout .wc-block-components-combobox-control {
		margin-bottom: 14px !important;
	}

	/* ================= 5) Shipping address ================= */
	/* Field/label vertical rhythm only - country selector behavior,
	   postcode logic, address calculation, and the billing checkbox's
	   own behavior are never touched by a spacing-only rule. */
	body.woocommerce-checkout .wc-block-components-address-form .wc-block-components-text-input,
	body.woocommerce-checkout .wc-block-components-address-form .wc-block-components-combobox-control {
		margin-bottom: 12px !important;
	}

	/* ================= 6) Shipping options ================= */
	body.woocommerce-checkout .wc-block-components-shipping-rates-control__package {
		padding: 12px 0 !important;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__option {
		display: flex !important;
		align-items: center !important;
		justify-content: space-between !important;
		gap: 10px !important;
		padding: 10px 0 !important;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__secondary-label {
		font-family: "Inter", sans-serif !important;
		font-size: 13px !important;
		font-weight: 400 !important;
	}

	/* ================= 7) Payment options ================= */
	/* Section spacing/surrounding typography only - card-input internals
	   beyond the already-approved v1.0.25 typography, and every branded
	   logo/method, are untouched. */
	body.woocommerce-checkout .wc-block-components-payment-methods {
		margin-top: 16px !important;
	}

	/* ================= 8) Secondary controls ================= */
	/* "Use same address for billing" (.wc-block-checkout__use-address-for-billing
	   is the confirmed real WooCommerce Blocks class for this specific
	   checkbox), "Add a note to your order", "Save payment information",
	   and the Terms/Privacy text - visually de-emphasized only, checkbox
	   behavior and every link stay exactly as Woo renders them. */
	body.woocommerce-checkout .wc-block-checkout__use-address-for-billing,
	body.woocommerce-checkout .wc-block-components-checkbox,
	body.woocommerce-checkout .wc-block-checkout__terms-text,
	body.woocommerce-checkout .wc-block-components-terms-and-conditions {
		font-family: "Inter", sans-serif !important;
		font-size: 12px !important;
		font-weight: 300 !important;
		opacity: 0.55 !important;
	}

	/* ================= 9) Lower Order Summary ================= */
	/* Itemized breakdown - product rows, coupon, totals, final total.
	   Values/classes reused verbatim from the already-shipped,
	   confirmed-live-typography Checkout selectors (v1.0.25) and the
	   already-validated Cart totals-hierarchy treatment (v1.0.28/29);
	   nothing about the calculation is touched. */
	body.woocommerce-checkout .wc-block-components-order-summary-item {
		padding: 14px 0 !important;
		border-bottom: 1px solid rgba(0, 0, 0, 0.06) !important;
	}
	body.woocommerce-checkout .wc-block-components-totals-coupon {
		margin: 18px 0 !important;
		padding-top: 16px !important;
		border-top: 1px solid rgba(0, 0, 0, 0.08) !important;
	}
	body.woocommerce-checkout .wc-block-components-totals-item {
		padding: 8px 0 !important;
	}
	body.woocommerce-checkout .wc-block-components-totals-footer-item {
		border-top: 1px solid rgba(0, 0, 0, 0.1) !important;
		margin-top: 8px !important;
		padding-top: 14px !important;
	}
	body.woocommerce-checkout .wc-block-components-totals-footer-item .wc-block-components-totals-item__label,
	body.woocommerce-checkout .wc-block-components-totals-footer-item .wc-block-components-totals-item__value {
		font-family: "Inter Tight", sans-serif !important;
		font-size: 15px !important;
		font-weight: 700 !important;
		opacity: 1 !important;
	}

	/* ================= 10) Place Order CTA ================= */
	/* .wc-block-components-button already carries the v1.0.25 JetBrains
	   Mono/uppercase treatment sitewide on Checkout (every button -
	   Place Order, Apply coupon, etc.) - this adds the mobile-only
	   full-width/height/letter-spacing emphasis that makes Place Order
	   specifically read as the primary BVX action, without touching its
	   click handler or processing-state logic. */
	body.woocommerce-checkout .wc-block-components-checkout-place-order-button {
		width: 100% !important;
		height: 48px !important;
		letter-spacing: 1.5px !important;
	}
}

/* ================= 11) Mobile Checkout scroll reveal ================= */
/*
 * Same values as the Mobile Cart reveal (v1.0.29), which itself reuses
 * the wearbvx.com frontend SPA's own .reveal/.reveal.visible rule
 * verbatim. Classes added by bvx-shop-chrome-checkout-reveal.js. Gated
 * to mobile widths only; the JS tags elements sitewide-on-Checkout but
 * it has no visual effect outside this breakpoint since no other rule
 * targets it.
 *
 * v1.0.32 (Fix 2) - EDITED, not appended: live-confirmed root cause of
 * the Woo Payments "+4" card-logo popover (#payment-methods-popover,
 * position:fixed) rendering ~294px lower than its own computed
 * top/right and overlapping the Security code field. Its offsetParent
 * was confirmed live to be FIELDSET#payment-method.bvx-checkout-
 * reveal.visible - i.e. the revealed Checkout fieldset this plugin
 * tags. Per spec, ANY transform value other than "none" establishes a
 * new containing block for fixed-position descendants, even
 * translateY(0), which is visually a no-op but not a CSS no-op. That
 * is the entire cause: Woo Payments correctly computes a viewport-
 * relative fixed position, but the browser resolves it against the
 * transformed fieldset instead of the viewport once reveal completes.
 * Fix: the only change is the .visible end-state transform below,
 * translateY(0) -> none. The transition still runs identically
 * (translateY(36px) -> none animates the same as -> translateY(0);
 * browsers treat "none" as the identity transform for interpolation
 * purposes), opacity/duration/easing/stagger are untouched, and the
 * popover itself is never selected by any rule - Woo Payments'
 * own fixed positioning is simply left free to resolve against the
 * viewport once this is the only transform in play. Scoped to
 * Checkout only per instruction; Cart's reveal end-state is
 * unchanged pending any evidence the same issue exists there.
 */
@media (max-width: 768px) {
	body.woocommerce-checkout .bvx-checkout-reveal {
		opacity: 0;
		transform: translateY(36px);
		transition: opacity 0.9s ease, transform 0.9s ease;
	}
	body.woocommerce-checkout .bvx-checkout-reveal.visible {
		opacity: 1;
		transform: none;
	}
}

@media (prefers-reduced-motion: reduce) {
	body.woocommerce-checkout .bvx-checkout-reveal {
		transition-duration: 0.01ms !important;
		transform: none !important;
	}
}

/*
 * v1.0.31 - Mobile Checkout radio-row overlap fix. Live-confirmed markup
 * (shared by Shipping options and Payment options rows):
 *   <label class="wc-block-components-radio-control__option ...">
 *     <input class="wc-block-components-radio-control__input" type="radio">
 *     <div class="wc-block-components-radio-control__option-layout">
 *       <div class="wc-block-components-radio-control__label-group">...</div>
 *     </div>
 *   </label>
 * Live-confirmed radio geometry: position:absolute; left:16px; top:16px;
 * width:20px; height:20px. v1.0.30's
 * .wc-block-components-radio-control__option { display:flex !important }
 * rule (item 6, Shipping options) overrode the option row's own layout
 * context without preserving the left inset that row normally reserves
 * for the absolutely-positioned radio, so the label/layout content's
 * left edge collapsed to 0 and sat directly under/over the radio -
 * text overlapping the input. Fixed by restoring exactly that reserved
 * inset on the shared option-layout element, on mobile Checkout only.
 * The radio's own left/top/width/height are untouched - this rule never
 * selects .wc-block-components-radio-control__input - and nothing about
 * shipping-rate calculation, payment-gateway markup, card fields, or
 * radio-selection behavior is touched. Applies identically to Standard
 * Shipping and every Payment options row (Card/Clearpay/Klarna/other
 * methods), since they share the same option-layout markup.
 */
@media (max-width: 768px) {
	body.woocommerce-checkout .wc-block-components-radio-control__option-layout {
		padding-left: 48px !important;
	}
}

/*
 * v1.0.32 - Mobile Checkout shipping-row alignment + BVX neon selected
 * state (Fix 1 of this round's correction pass). CSS-only, no PHP
 * change. Scoped entirely to body.woocommerce-checkout inside
 * @media (max-width: 768px); desktop (769px+), mobile header/footer,
 * Cart mobile, and the checkout reveal animation are untouched.
 *
 * EXACT CAUSE of the misalignment: the live-confirmed radio
 * (.wc-block-components-radio-control__input) is position:absolute
 * with a FIXED top:16px set by WooCommerce Blocks itself - it is taken
 * out of flow and does not respond to the row's own
 * align-items:center (added in v1.0.30), which only affects in-flow
 * flex children. Woo's top:16px implies the row is designed around a
 * 52px-tall option (16px inset above the 20px-tall radio, mirrored
 * 16px below = 16+20+16=52px). v1.0.30's
 * .wc-block-components-radio-control__option rule set padding:10px 0
 * with the row left at the browser default box-sizing:content-box, so
 * that 10px+10px padding was added ON TOP of the content height
 * instead of being carried inside it - rendering the row at 72px
 * (content height + 20px padding) rather than 52px. Because the
 * radio's top:16px offset is fixed and measured from the row's own
 * padding edge (practically its top edge, since there is no border),
 * the radio ended up sitting only 16px below the top of a 72px-tall
 * row instead of a 52px-tall one, leaving 16px of space above it but
 * 36px below - "not vertically centered". The label text and price
 * were separately never given their own flex alignment inside the
 * reserved 48px inset, so £3.99 was left-aligned immediately after the
 * label rather than flush right.
 *
 * FIX: add box-sizing:border-box to the existing
 * .wc-block-components-radio-control__option rule so min-height:52px
 * includes v1.0.30's own 10px top/bottom padding instead of adding to
 * it, restoring the true 52px row height the radio's fixed top:16px
 * was designed for (min-height/box-sizing only - the radio's own
 * left/top/width/height are never selected by any rule below), and
 * give the label/price pair their own flex row
 * (justify-content:space-between) inside the already-reserved 48px
 * inset so the price sits flush right without moving the radio or its
 * 48px inset horizontally.
 * Selected-radio accent: WooCommerce Blocks renders a plain native
 * <input type="radio">, which modern browsers already recolor via the
 * standard CSS `accent-color` property with no custom pseudo-element,
 * replacement markup, or JS needed - the safest possible way to
 * restyle a native form control's own checked-state fill/ring.
 *
 * SECOND discrepancy found during validation: native <input
 * type="radio"> elements carry a small default margin from the
 * browser's own UA stylesheet (Chromium: margin ~3px 3px 3px 4px).
 * Because the radio is position:absolute, that default margin still
 * offsets it further from the top:16px/left:16px values rather than
 * being collapsed away - pushing it a few pixels off the row's true
 * center regardless of the 52px row-height fix above. The live-
 * confirmed geometry (top:16px/left:16px exactly) implies this margin
 * is already neutralized on the real site, but to guarantee the
 * centering fix holds regardless, margin:0 is added defensively to
 * the same input rule already carrying accent-color - it does not
 * change left/top/width/height and has no effect other than
 * cancelling that default browser margin.
 */
@media (max-width: 768px) {
	body.woocommerce-checkout .wc-block-components-radio-control__option {
		min-height: 52px !important;
		box-sizing: border-box !important;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__option-layout {
		width: 100%;
		box-sizing: border-box;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__label-group {
		display: flex !important;
		align-items: center !important;
		justify-content: space-between !important;
		width: 100%;
		gap: 10px;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__input {
		accent-color: #BCFF00 !important;
		margin: 0 !important;
	}
}

/*
 * v1.0.33 - Mobile Checkout shipping-row correction pass, round 2: two
 * further live-confirmed geometry fixes on top of v1.0.32. Both are
 * pure additions; nothing above this block is edited.
 *
 * FIX A - Selected radio still rendering black. Live-confirmed:
 * the native <input> itself DOES already carry
 * accentColor:rgb(188,255,0) and appearance:none from v1.0.32's own
 * accent-color rule - but the visible dot is not native radio accent
 * rendering at all. WooCommerce Blocks draws the checked indicator
 * with its own ::before pseudo-element (background:rgb(0,0,0)), which
 * paints on top of/instead of the native accent-color fill. Because
 * accent-color only themes a browser's OWN native control rendering,
 * it has no effect on a separately-drawn ::before overlay. Fix:
 * target that pseudo-element's background directly on the :checked
 * state. The radio's ring, dimensions, absolute position and checked
 * behavior are untouched - only the ::before fill color changes, and
 * only when :checked, so an unchecked radio is unaffected. Applied to
 * :checked uniformly across Checkout (Shipping and Payment/Card share
 * the same radio-control markup), so selected Card/Klarna/Clearpay
 * also pick up the same BVX accent automatically - no gateway-specific
 * selector needed since none of them are targeted individually.
 *
 * FIX B - £3.99 flush against the row's right edge with no breathing
 * room. Live-confirmed geometry: row right:369, label-group
 * right:369, secondary-label right:369 - i.e. the price's own right
 * edge is the row's right edge exactly, 0px of inset. The existing
 * v1.0.31 padding-left:48px rule (preserved, not replaced) only
 * reserves space on the left for the radio; nothing previously
 * reserved space on the right. Fix: add padding-right:16px to the
 * same .option-layout rule's selector (as a separate declaration
 * block, so the v1.0.31 padding-left rule itself is never touched/
 * duplicated), plus flex:0 0 auto + text-align:right on the
 * secondary-label so the price doesn't stretch or get pushed off by
 * v1.0.32's label-group justify-content:space-between - it keeps its
 * own intrinsic width and right-aligns inside the newly reserved
 * 16px inset.
 */
@media (max-width: 768px) {
	body.woocommerce-checkout .wc-block-components-radio-control__input:checked::before {
		background-color: #BCFF00 !important;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__option-layout {
		padding-right: 16px !important;
	}
	body.woocommerce-checkout .wc-block-components-radio-control__secondary-label {
		flex: 0 0 auto;
		text-align: right;
	}
}

/*
 * ===================================================================
 * v1.0.34 - Mobile Header + My Account Drawer phase.
 * Scoped to body.woocommerce-account, body.woocommerce-cart,
 * body.woocommerce-checkout inside @media (max-width: 768px) only,
 * except where explicitly noted. Desktop (min-width: 769px), Cart
 * body, Checkout body, shipping/payment logic, mobile footer/
 * newsletter, Cart reveal, Checkout reveal, Cart Bridge, and Account
 * Styling are all untouched by this block.
 *
 * Reuses WordPress Core's own navigation-block drawer rather than
 * building a second one, per explicit instruction. Live-confirmed
 * markup this targets (Cart/Checkout):
 *   header nav.hostinger-ai-site-navigation.wp-block-navigation
 *     button.wp-block-navigation__responsive-container-open
 *       [aria-haspopup="dialog"] [aria-label="Open menu"]
 *     div.wp-block-navigation__responsive-container
 *       button.wp-block-navigation__responsive-container-close
 *       div.wp-block-navigation__responsive-container-content
 * Every selector below is scoped through "header nav.hostinger-ai-
 * site-navigation" specifically (never a bare class match), and PHP
 * additionally slices at <header>/<footer> boundaries before doing
 * its own insertion - both deliberately avoid the confirmed second
 * nav.wp-block-navigation instance in the footer ("modal-2" in this
 * round's live inspection). No modal id (e.g. "modal-1") is ever
 * matched, since those are confirmed dynamic/generated.
 *
 * My Account's own mobile hamburger trigger is NOT styled/exposed in
 * this block yet - per explicit instruction, pending confirmation of
 * whether .wp-block-navigation__responsive-container-open exists but
 * is hidden there, or is genuinely absent. The drawer CONTENT
 * insertion (PHP) and drawer CONTENT styling below already apply to
 * My Account too (harmless no-op until/unless its trigger is
 * resolved), since that part doesn't depend on the open-button
 * question either way.
 * ===================================================================
 */

/* ---- 1) Header height/padding + logo centering + icon grouping ----
 * Frontend-confirmed values: mobile header height 56px, 20px
 * horizontal padding. The chameleon is taken out of normal flow
 * (position:absolute, centered on both axes within the now-
 * position:relative wrapper) so it stays truly centered regardless of
 * the hamburger/account/cart group's own rendered width - the same
 * "centered logo, asymmetric side content" technique the frontend
 * doesn't need (it only has two top-level flex children) but this
 * backend markup does, since hamburger/account/cart are three
 * siblings inside one wrapper, not grouped into their own sub-wrapper.
 * margin-left:auto on the account control pushes it (and cart, which
 * simply follows it in normal flow) as a group to the right edge,
 * leaving the hamburger alone at the left edge - account<->cart
 * spacing is already provided by this same wrapper's existing sitewide
 * gap:10px rule (v1.0.1), unchanged and untouched here.
 *
 * Post-ship correction, this round: live DOM capture on all three
 * templates confirmed .hostinger-ai-menu-wrapper's direct children are
 * actually [logo wrapper div, (.bvx-account-header-nav on My Account
 * only - already display:none on mobile, untouched), .hostinger-ai-
 * site-navigation-wrapper] - and critically, the real logo element
 * (<p class="wp-block-site-title bvx-shop-chrome-logo">) is NOT itself
 * that direct-child wrapper; it is nested one level deeper inside a
 * <div class="wp-block-group is-nowrap ..."> which is the actual direct
 * child. The ">" (direct-child) combinator below never matched that
 * nesting, so the logo was never actually taken out of flow - it just
 * sat at its default static position (left), and with it still
 * occupying flow space, .hostinger-ai-site-navigation-wrapper's own
 * width:100% below could not resolve to the FULL header width either,
 * which is also what let hamburger/account/cart render bunched
 * together instead of hamburger-left/account+cart-right. Changing the
 * combinator to a plain descendant selector fixes both symptoms at
 * once: CSS position:absolute escalates to the nearest POSITIONED
 * ancestor regardless of nesting depth, so the logo still centers
 * correctly relative to .hostinger-ai-menu-wrapper (confirmed
 * position:relative, above) without needing to touch or even reference
 * the intermediate wrapper div at all. The confirmed hamburger/account/
 * mini-cart DOM order (nav first, then customer-account, then mini-
 * cart) was ALWAYS correct for the margin-left:auto technique below -
 * it only ever looked wrong because the logo bug was silently
 * preventing the navigation-wrapper from getting its full-width
 * flex-basis. Dual-use hazard unchanged/still avoided: .bvx-shop-
 * chrome-logo is shared between header and footer site-title
 * instances, but .hostinger-ai-menu-wrapper is header-only, so
 * widening "> .bvx-shop-chrome-logo" to a descendant selector still
 * cannot reach the footer's copy.
 */
@media (max-width: 768px) {
	body.woocommerce-account .hostinger-ai-menu,
	body.woocommerce-cart .hostinger-ai-menu,
	body.woocommerce-checkout .hostinger-ai-menu {
		height: 56px !important;
		/* v1.0.35 round 3 - this becomes the positioned ancestor for the
		   absolute layers below (the menu-wrapper used to be it, but the
		   menu-wrapper is already inset 24px inside this element's own
		   padding, which was silently doubling the intended 20px inset
		   to 44px live - see round 3 note below). */
		position: relative !important;
	}

	/* v1.0.35 round 2 - LIVE REGRESSION REWRITE. Production DOM capture
	 * confirmed .hostinger-ai-site-navigation-wrapper ALSO carries
	 * "wp-block-group is-nowrap" (the same classes as the logo's real
	 * direct-child wrapper), and that this element sits inside the
	 * desktop baseline's 3-column grid (.hostinger-ai-menu-wrapper's own
	 * `display:grid; grid-template-columns:265px 1fr auto`). The prior
	 * approach (flex row + zero-width the logo wrapper + margin-
	 * left:auto on the account control) depended on that zero-width
	 * trick to free up space for the flex row, and on margins/source
	 * order to group account+cart on the right - both of which broke as
	 * soon as the theme's shared class on the nav-wrapper caused the
	 * zero-width rule to hit the wrong element. Replaced entirely with
	 * explicit, structural positioning: the logo is absolutely centered
	 * (unchanged) and the nav-wrapper becomes its own independent
	 * absolutely-positioned grid layer spanning the full 20px-inset
	 * width, with each control explicitly placed into a named grid
	 * column. Neither the logo wrapper's width nor the nav-wrapper's
	 * flex/margin relationships matter anymore - no width-collapsing
	 * trick, no margin-left:auto, no reliance on source order.
	 * .hostinger-ai-menu-wrapper itself is forced to display:block
	 * (overriding the desktop grid) purely so that baseline grid no
	 * longer assigns its children (logo wrapper, nav-wrapper) to fixed-
	 * width tracks of its own - everything that's actually visible now
	 * comes from the two absolutely-positioned layers below, so the
	 * wrapper's own in-flow layout mode no longer matters visually. */
	/* v1.0.35 round 3 - LIVE REGRESSION FIX: live computed geometry showed
	 * the nav-wrapper landing at left:44/right:348 instead of the
	 * intended left:20/right:20 at a 392px viewport. Root cause: this
	 * wrapper is already inset 24px inside .hostinger-ai-menu's own
	 * padding (0 24px, theme-confirmed), and it was ALSO the
	 * position:relative ancestor the absolute layers below were
	 * resolving against - so their own 20px inset was being added on
	 * top of that existing 24px, compounding to 44px. Demoted to
	 * position:static so it is no longer anyone's containing block;
	 * .hostinger-ai-menu above is now that ancestor instead, and since a
	 * positioned ancestor's PADDING box (not its content box) is what
	 * absolutely-positioned descendants resolve against, the menu's own
	 * 24px padding has no effect on them - they now size against the
	 * true full 392px header width, giving a real 20px inset. The logo
	 * below needs no selector change for this - position:absolute
	 * always resolves against the nearest positioned ancestor in the
	 * DOM regardless of which selector targets it, so it automatically
	 * re-centers on .hostinger-ai-menu the moment this wrapper stops
	 * being positioned. */
	body.woocommerce-account .hostinger-ai-menu-wrapper,
	body.woocommerce-cart .hostinger-ai-menu-wrapper,
	body.woocommerce-checkout .hostinger-ai-menu-wrapper {
		position: static !important;
		display: block !important;
		width: 100% !important;
		height: 100% !important;
		box-sizing: border-box !important;
	}

	body.woocommerce-account .hostinger-ai-menu-wrapper .bvx-shop-chrome-logo,
	body.woocommerce-cart .hostinger-ai-menu-wrapper .bvx-shop-chrome-logo,
	body.woocommerce-checkout .hostinger-ai-menu-wrapper .bvx-shop-chrome-logo {
		position: absolute !important;
		left: 50% !important;
		top: 50% !important;
		transform: translate(-50%, -50%) !important;
		margin: 0 !important;
	}

	/* The nav-wrapper is now a self-contained absolute layer, 20px
	 * inset from each edge, completely independent of the logo
	 * wrapper's own (irrelevant) width. 4 explicit columns: hamburger
	 * (fixed 38px, matching the re-skinned button's own forced
	 * width/height below), a flexible spacer, account, cart - each
	 * control is placed by grid-column, not by document order. */
	body.woocommerce-account .hostinger-ai-site-navigation-wrapper,
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper {
		position: absolute !important;
		left: 20px !important;
		right: 20px !important;
		top: 0 !important;
		bottom: 0 !important;
		width: auto !important;
		display: grid !important;
		grid-template-columns: 38px 1fr auto auto;
		align-items: center !important;
		gap: 8px !important;
	}

	/* v1.0.38 round 5 - FIX 1 (mobile logo tap-through): confirmed via
	 * hit-testing that taps on the centered logo were being intercepted,
	 * not by the drawer panel (that's hidden via display:none when
	 * closed, so it can't be the cause), but by THIS wrapper itself. It
	 * is position:absolute and spans the full header width edge-to-edge,
	 * including its own empty "1fr" spacer grid track that sits directly
	 * over the centered logo - and because it's positioned, it paints
	 * above the logo's ordinary static-flow box regardless of DOM order,
	 * so that empty spacer area still swallows pointer events even
	 * though nothing is visually drawn there. Fixed purely with
	 * pointer-events, not geometry: the wrapper stops accepting pointer
	 * events itself (so a tap in its empty area now falls through to the
	 * logo underneath), while each real control below gets
	 * pointer-events:auto restored so the hamburger/account/cart stay
	 * fully tappable exactly as before. No position, size, z-index or
	 * visual change of any kind. */
	body.woocommerce-account .hostinger-ai-site-navigation-wrapper,
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper {
		pointer-events: none !important;
	}

	/* v1.0.35 round 3 - LIVE REGRESSION FIX: live computed styles showed
	 * the theme assigns these three controls flex "order" values
	 * sitewide (account:1, cart:2, hamburger-nav:3). `order` also
	 * governs CSS Grid auto-placement order, not just flex visual
	 * order - so with an explicit grid-column but automatic grid-row on
	 * each item, the auto-placement cursor processed account/cart
	 * FIRST (lower order), filled row 1 across to its last column, then
	 * had nowhere left in row 1 to place the hamburger (highest order,
	 * processed last) and dropped it into an implicit second row
	 * instead - exactly the confirmed live bug (hamburger top:46 vs
	 * account/cart's top:0). Fixed two ways at once, per instruction:
	 * order is neutralized back to the controls' own DOM order (so
	 * auto-placement would no longer reorder them even without the
	 * grid-row override), AND grid-row:1 is forced explicitly so the
	 * row assignment no longer depends on auto-placement timing at
	 * all. align-self:center keeps each control vertically centered
	 * within that shared row regardless of its own height. */
	body.woocommerce-account .hostinger-ai-site-navigation-wrapper > nav.hostinger-ai-site-navigation,
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper > nav.hostinger-ai-site-navigation,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper > nav.hostinger-ai-site-navigation {
		grid-column: 1;
		grid-row: 1 !important;
		justify-self: start;
		align-self: center !important;
		order: 0 !important;
		/* Neutralizes the sitewide v1.0.1 margin-right:30px (this
		   element also matches that rule's `nav.wp-block-navigation`
		   selector) - under the grid above a leftover margin would
		   shift the hamburger out of its 38px cell instead of just
		   compensating flex spacing like it did sitewide. Scoped to
		   these 3 templates only; the sitewide rule itself is
		   untouched everywhere else. */
		margin-right: 0 !important;
		/* v1.0.38 round 5 - FIX 1: restores tappability after the parent
		   wrapper above was set to pointer-events:none. */
		pointer-events: auto !important;
	}

	body.woocommerce-account .hostinger-ai-site-navigation-wrapper > .wp-block-woocommerce-customer-account,
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper > .wp-block-woocommerce-customer-account,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper > .wp-block-woocommerce-customer-account {
		grid-column: 3;
		grid-row: 1 !important;
		justify-self: end;
		align-self: center !important;
		order: 0 !important;
		margin-left: 0 !important;
		/* v1.0.38 round 5 - FIX 1: restores tappability after the parent
		   wrapper above was set to pointer-events:none. */
		pointer-events: auto !important;
	}

	/* My Account: the mini-cart is Woo's real, interactive, visible
	   control, so it takes its own grid column at the far right,
	   immediately after account. */
	body.woocommerce-account .hostinger-ai-site-navigation-wrapper > .wc-block-mini-cart {
		grid-column: 4;
		grid-row: 1 !important;
		justify-self: end;
		align-self: center !important;
		order: 0 !important;
		/* v1.0.38 round 5 - FIX 1: restores tappability after the parent
		   wrapper above was set to pointer-events:none. (Cart/Checkout's
		   mini-cart is already visibility:hidden/disabled/aria-hidden,
		   so it needs no equivalent rule - there's nothing tappable
		   there to restore.) */
		pointer-events: auto !important;
	}

	/* Cart/Checkout: Woo renders the same mini-cart markup but keeps it
	   visibility:hidden/aria-hidden/disabled (confirmed, untouched -
	   nothing here changes that accessibility state). As a normal grid
	   item it would still reserve column 4's auto-sized track even
	   while invisible, which is exactly what was pushing account away
	   from the right edge. Per spec, taking a grid item out with its
	   own position:absolute removes it from grid track-sizing entirely
	   (it no longer contributes to column 4's width) without touching
	   visibility/aria-hidden/disabled - so column 4 collapses to 0 and
	   account (column 3) becomes the true last column, flush right. */
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper > .wc-block-mini-cart,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper > .wc-block-mini-cart {
		position: absolute !important;
		right: 0 !important;
		top: 0 !important;
		bottom: 0 !important;
	}

	/* Confirmed-by-test, this round: taking the mini-cart out of grid
	 * flow (above) collapses column 4's own WIDTH to 0, but the grid's
	 * gap:8px still applies between every adjacent track the template
	 * declares, including the now-empty gap between column 3 (account)
	 * and the still-declared (if width-0) column 4 - leaving account
	 * 8px short of the true right edge on Cart/Checkout. Fixed by
	 * dropping that trailing column from the template entirely on these
	 * two templates only, so there is no gap left to reserve and
	 * account's own column 3 becomes the true last column, flush with
	 * the right edge. My Account keeps the 4-column template (untouched)
	 * since its cart is real and genuinely needs that column + gap. */
	body.woocommerce-cart .hostinger-ai-site-navigation-wrapper,
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper {
		grid-template-columns: 38px 1fr auto !important;
	}
}

/*
 * v1.0.44 - Checkout-only "back to cart" control (mobile). Per explicit
 * instruction, this does NOT reactivate Woo's own disabled mini-cart on
 * Checkout (that control stays exactly as-is - visibility:hidden/
 * aria-hidden/disabled, untouched, same v1.0.35-era rule above). Instead
 * this restyles a brand-new plugin-authored element,
 * .bvx-checkout-cart-link (markup: bvx_shop_chrome_render_checkout_cart_link()
 * in bvx-shop-chrome.php, Checkout-only), reusing the exact same bag-icon
 * background-image/sizing already established for the real mini-cart
 * button elsewhere in this file (v1.0.1) so it reads as the same icon
 * family, but as a plain navigation link with none of that control's
 * cart-state/interactivity attributes.
 *
 * Scoped to body.woocommerce-checkout only - Cart is completely
 * untouched (keeps the v1.0.35 3-column collapse/no-cart-icon layout
 * immediately above, byte-identical) and must come AFTER that shared
 * cart+checkout rule in source order so this checkout-only override of
 * the SAME property (grid-template-columns, same selector specificity,
 * both !important) actually wins the cascade for Checkout specifically.
 */
@media (max-width: 768px) {
	/* Restores the 4th grid column on Checkout - but ONLY when the new
	   .bvx-checkout-cart-link element the PHP transformation inserts
	   is actually present as a child (:has(), same technique already
	   proven in this file for the dashboard title-removal rule). This
	   is deliberate, not just a convenience: if that PHP insertion
	   were ever to no-op (its own single-match anchor gate failing to
	   find hostinger-ai-site-navigation-wrapper, logged, markup left
	   untouched - same defensive pattern as every other transformation
	   in bvx-shop-chrome.php), this CSS must not restore an empty 4th
	   column with nothing in it, which would silently reproduce the
	   exact "account sits 8px short of the right edge" bug the
	   v1.0.35 round-3 fix already solved once. Coupling the CSS to the
	   element's real presence means Checkout safely falls back to the
	   existing, already-correct 3-column collapse below whenever the
	   link isn't actually there - never a half-applied, broken middle
	   state. */
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper:has(> .bvx-checkout-cart-link) {
		grid-template-columns: 38px 1fr auto auto !important;
	}

	/* Same column/row placement convention as account/cart/hamburger
	   above - explicit grid-column, not DOM order, so it renders in
	   the normal cart position regardless of where the PHP insertion
	   placed it in the markup. pointer-events:auto restores
	   tappability after the parent wrapper's own pointer-events:none
	   (same v1.0.38 FIX 1 pattern already applied to every other
	   control in this wrapper). */
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper > .bvx-checkout-cart-link {
		grid-column: 4;
		grid-row: 1 !important;
		justify-self: end;
		align-self: center !important;
		order: 0 !important;
		pointer-events: auto !important;
		width: 38px;
		height: 38px;
		box-sizing: border-box;
		display: flex;
		align-items: center;
		justify-content: center;
		/* Byte-identical bag-icon SVG and sizing to the real mini-cart
		   button's own v1.0.1 background-image rule above - same
		   visual icon family, deliberately not a new/different glyph. */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M6 2L3 6v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6L18 2z'%3E%3C/path%3E%3Cline x1='3' y1='6' x2='21' y2='6'%3E%3C/line%3E%3Cpath d='M16 10a4 4 0 0 1-8 0'%3E%3C/path%3E%3C/svg%3E");
		background-repeat: no-repeat;
		background-position: center;
		background-size: 18px 18px;
		text-decoration: none;
	}
}

/*
 * v1.0.44 round 3 - Checkout-only "back to cart" control (DESKTOP).
 * Live-confirmed this round: Woo's real mini-cart is ALSO
 * visibility:hidden/aria-hidden/disabled on desktop Checkout, not just
 * mobile (confirmed rect 38x38) - same disabled-but-rendered pattern,
 * untouched here exactly as at mobile.
 *
 * Desktop's .hostinger-ai-site-navigation-wrapper is NOT the mobile
 * absolute/grid layer above - it is the theme's own ordinary flex row,
 * and (confirmed, this plugin's own v1.0.35-round-3 note) the theme
 * applies flex "order" values sitewide, unconditionally, to this row's
 * three controls: nav=3, account=1, cart=2. That means the real visual
 * order at desktop is account, then cart, then nav - the mini-cart's
 * flex slot sits BETWEEN account and nav, not at the wrapper's right
 * edge, so anchoring the new link with `right:0` (as if cart were
 * simply the rightmost item, the way it is once mobile's :has()
 * override already strips that order sitewide at that breakpoint)
 * would misplace it next to nav instead. Reusing the theme's own
 * ordering mechanism instead of fighting it: the real mini-cart is
 * taken out of flex flow with position:absolute (exactly the same
 * "remove its width contribution, change nothing else about it"
 * technique already proven for Cart/Checkout at mobile above - no top/
 * left/right is needed here because the element is already
 * visibility:hidden/aria-hidden/disabled, so where its now-invisible,
 * non-interactive box physically lands is irrelevant), and the new
 * link is given `order: 2 !important` - the exact order value the real
 * mini-cart carried - so it drops cleanly into that same vacated slot
 * between account and nav, with the wrapper's existing gap:10px
 * applying normally on both sides, no extra reserved space, no change
 * to account's or nav's own order/position.
 *
 * Gated the same defensive way as every other transformation in this
 * plugin: if the PHP insertion for any reason failed to add
 * .bvx-checkout-cart-link (logged, 0/multiple-match case), :has() means
 * the real mini-cart is left completely alone - still occupying its
 * normal (if invisible) flex slot exactly as before this round - never
 * a stripped-away slot with nothing to replace it.
 */
@media (min-width: 769px) {
	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper:has(> .bvx-checkout-cart-link) > .wc-block-mini-cart {
		position: absolute !important;
	}

	body.woocommerce-checkout .hostinger-ai-site-navigation-wrapper > .bvx-checkout-cart-link {
		order: 2 !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		width: 38px;
		height: 38px;
		box-sizing: border-box;
		/* Byte-identical bag-icon SVG/sizing to the real mini-cart
		   button's own v1.0.6 desktop reskin above - same icon family. */
		background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='18' height='18' viewBox='0 0 24 24' fill='none' stroke='%23000000' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M6 2L3 6v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6L18 2z'%3E%3C/path%3E%3Cline x1='3' y1='6' x2='21' y2='6'%3E%3C/line%3E%3Cpath d='M16 10a4 4 0 0 1-8 0'%3E%3C/path%3E%3C/svg%3E");
		background-repeat: no-repeat;
		background-position: center;
		background-size: 18px 18px;
		text-decoration: none;
	}
}

/* ---- 2) Scroll-triggered header background (frontend parity) ----
 * Replaces the earlier always-on rgba(255,255,255,.95) mobile
 * background (shipped in prior rounds) with the frontend's own
 * transparent-at-top -> blurred-white-on-scroll behavior, per explicit
 * instruction this round. Appended here rather than editing the prior
 * rule in place, per this plugin's standing practice of never rewriting
 * already-shipped history - as the LAST rule of equal selector and
 * specificity (both !important), this is the one that actually wins
 * the cascade and renders, while the earlier rule stays byte-identical
 * for anyone reading the file's history. .bvx-mobile-header-scrolled is
 * toggled by the new bvx-shop-chrome-mobile-header.js at the same
 * scrollY>20 threshold, same .4s transition, as the live frontend.
 */
@media (max-width: 768px) {
	body.woocommerce-account div.wp-block-group.hostinger-ai-menu.has-color-1-background-color,
	body.woocommerce-checkout div.wp-block-group.hostinger-ai-menu.has-color-1-background-color,
	body.woocommerce-cart div.wp-block-group.hostinger-ai-menu.has-color-1-background-color {
		background-color: transparent !important;
		-webkit-backdrop-filter: none !important;
		backdrop-filter: none !important;
		border-bottom: 1px solid transparent !important;
		transition: background-color 0.4s ease, border-color 0.4s ease !important;
	}

	body.woocommerce-account div.wp-block-group.hostinger-ai-menu.has-color-1-background-color.bvx-mobile-header-scrolled,
	body.woocommerce-checkout div.wp-block-group.hostinger-ai-menu.has-color-1-background-color.bvx-mobile-header-scrolled,
	body.woocommerce-cart div.wp-block-group.hostinger-ai-menu.has-color-1-background-color.bvx-mobile-header-scrolled {
		background-color: rgba(255, 255, 255, 0.95) !important;
		-webkit-backdrop-filter: blur(16px) !important;
		backdrop-filter: blur(16px) !important;
		border-bottom-color: rgba(0, 0, 0, 0.1) !important;
	}
}

/* ---- 3) Hamburger button re-skin (Cart/Checkout confirmed; harmless
 * no-op on My Account until/unless its trigger is confirmed/exposed) ----
 * Hides whatever Core renders inside the button (its own icon) and
 * draws two bars via pseudo-elements, matching the frontend's .menu-btn
 * span dimensions (22x1px, 6px gap, obsidian) and morph easing
 * (.35s cubic-bezier(.77,0,.18,1)) exactly. Core's own click handler
 * (data-wp-on--click="actions.openMenuOnClick", live-confirmed) lives
 * on the button element itself, never on its icon children, so hiding
 * those children has no effect on Core's open/close behavior.
 */
@media (max-width: 768px) {
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open {
		position: relative !important;
		width: 38px !important;
		height: 38px !important;
		padding: 0 !important;
		margin: 0 !important;
		background: none !important;
		border: none !important;
		box-shadow: none !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		flex-shrink: 0 !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open > *,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open > *,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open > * {
		display: none !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before,
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after {
		content: "";
		position: absolute;
		left: 50%;
		width: 22px;
		height: 1px;
		background: #0A0A0A;
		transform: translateX(-50%);
		transition: transform 0.35s cubic-bezier(0.77, 0, 0.18, 1), opacity 0.35s cubic-bezier(0.77, 0, 0.18, 1);
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::before {
		top: 16px;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open::after {
		top: 22px;
	}

	/* Morph into an X once Core marks the dialog open. aria-expanded is
	   the standard ARIA attribute an aria-haspopup="dialog" trigger
	   gets when its dialog opens - not independently re-confirmed this
	   round (the live inspection gave button/overlay/content/close
	   classes, not this attribute's toggled value), flagged as a
	   standard-pattern/medium-confidence assumption. Fails safely if
	   wrong: the bars simply would not morph, while Core's own actual
	   open/close click handling is completely unaffected either way. */
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::before {
		transform: translateX(-50%) translateY(6px) rotate(45deg);
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-open[aria-expanded="true"]::after {
		transform: translateX(-50%) translateY(-6px) rotate(-45deg);
	}
}

/* ---- 4) Drawer panel motion (best-effort; Core's own open/close
 * mechanics are never touched regardless of whether this matches) ----
 * Adds the frontend's own slide-in transform/easing on top of
 * whatever show/hide mechanism Core already uses. ".is-menu-open" is
 * WordPress Core block-library's documented class for an open
 * navigation-block overlay - not independently re-confirmed this
 * round. If Core instead toggles visibility via display:none/flex
 * rather than this class, this transition simply never animates and
 * the drawer still opens/closes correctly via Core's own default
 * behavior - a graceful no-op, not a breakage.
 */
@media (max-width: 768px) {
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container {
		transition: transform 0.45s cubic-bezier(0.77, 0, 0.18, 1) !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container:not(.is-menu-open),
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container:not(.is-menu-open),
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container:not(.is-menu-open) {
		transform: translateX(100%);
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open {
		transform: translateX(0);
	}
}

/* ---- 5) Drawer content styling (the account nav/login-register link
 * inserted by PHP into .wp-block-navigation__responsive-container-
 * content) - JetBrains Mono/uppercase per the Account Styling design
 * system already in use on the desktop sidebar nav, sulphur active
 * state as explicitly requested for the drawer specifically. ----
 */
@media (max-width: 768px) {
	body.woocommerce-account .bvx-account-drawer-nav,
	body.woocommerce-cart .bvx-account-drawer-nav,
	body.woocommerce-checkout .bvx-account-drawer-nav {
		display: flex !important;
		flex-direction: column !important;
		gap: 2px !important;
		padding: 28px !important;
	}

	body.woocommerce-account .bvx-account-drawer-link,
	body.woocommerce-cart .bvx-account-drawer-link,
	body.woocommerce-checkout .bvx-account-drawer-link {
		font-family: "JetBrains Mono", monospace !important;
		font-size: 0.78rem !important;
		letter-spacing: 0.15em !important;
		text-transform: uppercase !important;
		color: #0A0A0A !important;
		text-decoration: none !important;
		opacity: 0.55;
		padding: 15px 0 !important;
		border-bottom: 1px solid rgba(0, 0, 0, 0.1) !important;
		transition: opacity 0.2s !important;
		position: relative;
	}

	body.woocommerce-account .bvx-account-drawer-link:hover,
	body.woocommerce-cart .bvx-account-drawer-link:hover,
	body.woocommerce-checkout .bvx-account-drawer-link:hover {
		opacity: 1;
	}

	body.woocommerce-account .bvx-account-drawer-link.is-active,
	body.woocommerce-cart .bvx-account-drawer-link.is-active,
	body.woocommerce-checkout .bvx-account-drawer-link.is-active {
		opacity: 1;
	}

	body.woocommerce-account .bvx-account-drawer-link.is-active::after,
	body.woocommerce-cart .bvx-account-drawer-link.is-active::after,
	body.woocommerce-checkout .bvx-account-drawer-link.is-active::after {
		content: "";
		position: absolute;
		left: 0;
		bottom: -1px;
		width: 28px;
		height: 2px;
		background: #BCFF00;
	}
}

/* ---- 6) Hide the permanently-visible mobile My Account body nav now
 * that the drawer carries the same links. BVX Shop Chrome only, per
 * explicit instruction - Account Styling's own CSS is never edited. ----
 */
@media (max-width: 768px) {
	body.woocommerce-account .woocommerce-MyAccount-navigation {
		display: none !important;
	}
}

/* ---- 7) Expose My Account's own native Core nav (live-inspection
 * confirmed, this round) - reusing the existing toggle rather than
 * adding a duplicate one ----
 *
 * Live inspection this round confirmed My Account already has the exact
 * same Core markup as Cart/Checkout - the same
 * nav.hostinger-ai-site-navigation.wp-block-navigation, the same
 * button.wp-block-navigation__responsive-container-open (confirmed
 * computed display:flex/visibility:visible/opacity:1 on the button
 * itself), the same div#modal-1.wp-block-navigation__responsive-
 * container, the same .wp-block-navigation__responsive-container-content
 * drawer slot. Sections 1-5 above already style all of this correctly
 * for My Account too (they were never template-gated to only Cart/
 * Checkout), so no new JS, no new markup, and no new drawer
 * architecture are needed here - only one thing was actually hiding it.
 *
 * Root cause, confirmed via this round's live inspection: BVX Account
 * Styling v1.0.10 added
 *   body.woocommerce-account .hostinger-ai-menu nav.wp-block-navigation
 *     { display: none !important; }
 * at a time when this drawer was empty/non-functional on My Account
 * specifically (Cart/Checkout were never in scope for that rule, which
 * is exactly why their hamburger already worked and only My Account's
 * did not). Now that the drawer carries real account-nav content, that
 * rule is obsolete for My Account - but per explicit instruction, BVX
 * Account Styling's own CSS is never edited, so this overrides it
 * entirely from Shop Chrome.
 *
 * The override selector below is deliberately built to beat Account
 * Styling's rule regardless of stylesheet load order, not by relying on
 * source order between two separate files: both rules carry 3 class
 * selectors (equal class-tier specificity: woocommerce-account +
 * hostinger-ai-menu/hostinger-ai-site-navigation + wp-block-navigation),
 * but this one adds "header" as a third type selector (body/header/nav
 * vs. Account Styling's body/nav), which wins the type-tier tie-break
 * the moment class-tier specificity is equal - so it wins the cascade
 * whichever stylesheet happens to be enqueued second. Account Styling's
 * v1.0.10 rule itself is untouched, in its own file, exactly as shipped.
 *
 * Scoped to My Account only (body.woocommerce-account) - Cart/Checkout
 * never had this problem and are untouched by this rule. Desktop
 * (min-width:769px) is untouched: Account Styling's own rule (like this
 * override) is itself inside @media (max-width:768px), so neither one
 * ever applied to, or needs correcting for, desktop in the first place.
 */
@media (max-width: 768px) {
	body.woocommerce-account header nav.hostinger-ai-site-navigation.wp-block-navigation {
		display: flex !important;
		align-items: center !important;
	}
}

/* ---- 8) Desktop regression fix (post-ship): the injected account-
 * drawer links were rendering inline, unstyled, in the desktop header
 * on My Account/Cart/Checkout - confirmed live on all three pages after
 * v1.0.34 shipped. Root cause: sections 1-5 above only ever style
 * .wp-block-navigation__responsive-container-open/-container at mobile
 * widths (max-width:768px) - nothing in this phase, nor in Core's own
 * CSS as it turns out, actually hides the drawer CONTENT at desktop.
 * The drawer trigger/overlay mechanics stay Core's own responsibility
 * either way (never touched here) - what was missing is that the PHP-
 * inserted account links had no hiding mechanism of their own to fall
 * back on.
 *
 * .wp-block-navigation__responsive-container-content itself is never
 * hidden outright here, deliberately - it is Core-owned markup used
 * elsewhere in this nav block, so hiding it globally could affect
 * navigation behavior this plugin has no business touching. Instead,
 * the PHP that inserts the account links (bvx_shop_chrome_render_
 * account_drawer_nav()) now wraps ONLY its own injected markup in a new
 * BVX-owned element, .bvx-mobile-account-drawer-content, and this is
 * what actually gets hidden/shown - a wrapper under this plugin's own
 * control, independent of whatever Core's container does at any width.
 *
 * The unconditional (not media-gated) rule below is the one that
 * matters for desktop: display:none at every width by default, so our
 * own injected content contributes zero width/height anywhere unless
 * explicitly re-enabled. It is re-enabled only inside the same
 * max-width:768px scope already used throughout this phase, for the
 * same three templates - mobile layout/behavior is completely
 * unchanged by this fix (the inner .bvx-account-drawer-nav/-link
 * markup and styling from section 5 are untouched).
 */
.bvx-mobile-account-drawer-content {
	display: none !important;
}

@media (max-width: 768px) {
	body.woocommerce-account .bvx-mobile-account-drawer-content,
	body.woocommerce-cart .bvx-mobile-account-drawer-content,
	body.woocommerce-checkout .bvx-mobile-account-drawer-content {
		display: block !important;
	}
}

/* ---- v1.0.37 - Cart/Checkout mobile blank-gap fix ----
 * Live DOM capture (body-children dump) confirmed the large blank gap
 * above the Cart/Checkout mobile header is coming from body's own
 * padding-top:75px (and the resulting .wp-site-blocks top:75px) -
 * theme-applied sitewide, not from this plugin's header markup or any
 * rule above. My Account is untouched/out of scope here (confirmed
 * separately as not exhibiting this gap); scoped to Cart/Checkout only,
 * mobile only. Header geometry, hamburger placement, logo centering,
 * account/cart positioning, the drawer, body layouts, footer, and
 * desktop are all untouched by this rule. */
@media (max-width: 768px) {
	body.woocommerce-cart,
	body.woocommerce-checkout {
		padding-top: 0 !important;
	}
}

/* ==== v1.0.38 round 5 - Mobile drawer interaction fixes ====
 * Mobile-only (max-width:768px), scoped to the same three templates
 * and the same `header nav.hostinger-ai-site-navigation` selector
 * already used throughout sections 1-5 - footer's own nav instance,
 * desktop, and every approved piece of header geometry (hamburger/
 * account/cart x/y, logo centering/size, nav-wrapper position) are
 * completely untouched below. Per standing practice, sections 3 and 4
 * above are left byte-identical; the rules below win purely on source
 * order (same selectors/specificity, both !important).
 *
 * Ground truth for all three fixes below was taken directly from
 * WordPress Core's real shipped navigation-block source
 * (@wordpress/block-library's style.css, view.js and index.php),
 * fetched and read this round, not assumed:
 *   - the container is display:none by default and only becomes
 *     display:flex via the "is-menu-open" class Core's own JS toggles
 *     reactively (data-wp-class--is-menu-open="state.isMenuOpen" in
 *     index.php, backed by the state.isMenuOpen getter in view.js) -
 *     a plain display swap, never an animatable transform. That's
 *     exactly why section 4's existing transform-transition never
 *     visibly animates: a display:none element can't transition.
 *   - the real OPEN button never receives aria-expanded at all -
 *     Core's index.php only ever renders `aria-haspopup="dialog"` on
 *     it, nothing binds aria-expanded. That confirms section 3's
 *     existing `[aria-expanded="true"]` morph selector can never
 *     match, which is why those bars never turned into an X.
 *   - the real CLOSE button is a genuinely separate element, and
 *     Core's own style.css places it at `position:absolute;top:0;
 *     right:0;z-index:2` by default - confirming the reported "close
 *     button appears on the right" is Core's own default placement
 *     for this second, always-distinct button, not a bug in this
 *     plugin's existing CSS.
 *   - Confirmed via a corrected Playwright hit-test fixture (the
 *     earlier fixture wrongly modeled the container as unconditionally
 *     position:fixed;inset:0): the logo tap failure is NOT the drawer
 *     container at all (it's display:none while closed, so it can't
 *     intercept anything then) - it's `.hostinger-ai-site-navigation-
 *     wrapper`, the absolutely-positioned layer already added in round
 *     3 to place the hamburger/account/cart. That wrapper spans the
 *     full header width edge-to-edge, including its own empty "1fr"
 *     spacer grid track sitting directly over the centered logo, and
 *     being positioned it paints above the logo's ordinary static-flow
 *     box regardless of DOM order - so the empty spacer intercepts the
 *     tap even though nothing is drawn there. That fix (pointer-events,
 *     not geometry) is already applied in-place in section 1 above.
 */

/* ---- FIX 2: make the drawer's open/close actually animate ----
 * Keeps Core's own display toggle from ever snapping instantly by
 * forcing the container to stay display:flex at all times. Closed
 * state is hidden instead via visibility+pointer-events, which -
 * unlike display:none - CAN be transitioned/delayed, so the already-
 * correct .45s cubic-bezier(.77,0,.18,1) timing actually gets to play.
 * visibility's own change is delayed a full .45s on the CLOSING side
 * only, so the panel stays in the accessibility tree/still paints for
 * the entire slide-out and only truly disappears once fully off-
 * screen; opening is immediate (0 delay) so it's visible from the
 * first frame of the slide-in. Core's own focus-return-on-close
 * (closeMenu() in view.js, confirmed in the fetched source) runs
 * synchronously on click, independent of this CSS, so focus never
 * gets stranded inside a hidden region.
 *
 * The slide itself is deliberately moved from the outer container
 * (section 4's approach) onto the inner `-content` pane instead - see
 * FIX 3 below for why: it's what lets the repositioned close button
 * sit rock-still at the hamburger's exact coordinates while only the
 * links pane slides past/behind it, rather than sliding in together
 * with it from off-screen.
 */
@media (max-width: 768px) {
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container {
		display: flex !important;
		visibility: hidden;
		pointer-events: none;
		/* Cancels section 4's own container-level transform (that rule
		   is left byte-identical above) - the motion moves to the
		   content pane below instead. */
		transform: none !important;
		/* round 6: delay bumped from .45s to .65s to match the slower
		   slide duration below, so visibility only flips to hidden once
		   the (now-slower) slide-out has actually finished. */
		transition: visibility 0s linear 0.65s !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open {
		visibility: visible;
		pointer-events: auto;
		transition: visibility 0s linear 0s !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-content,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-content,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-content {
		/* round 6: slowed from .45s to .65s per live feedback - the
		   .45s timing, while technically animating, still read faster
		   than the frontend's own drawer. Same easing, just slower. */
		transition: transform 0.65s cubic-bezier(0.77, 0, 0.18, 1) !important;
		/* 100vw rather than 100% - the content pane's own box width is
		   whatever its flex children need, not necessarily the full
		   viewport, so a percentage-based translateX would only move it
		   by its own (smaller) width and leave it partly on-screen.
		   100vw guarantees it clears the viewport entirely regardless. */
		transform: translateX(100vw) !important;
		width: 100% !important;
		/* round 6 addition: Core's own default content padding-top
		   (calc(2rem + 24px) ~= 56px, confirmed in Core's real
		   style.css) assumes the trigger button sits near the true
		   viewport top. On My Account it doesn't - the close button is
		   now anchored to the hamburger's real (lower) position via
		   --bvx-close-top - so Core's fixed 56px safety margin wasn't
		   enough there and the drawer links started underneath/
		   overlapping the repositioned close button. max() guarantees
		   this NEVER shrinks below Core's own original 56px (so
		   Cart/Checkout, whose close button already sits above that
		   56px line, are completely unaffected - same padding as
		   before) while growing to clear the close button's real
		   bottom edge, plus an 8px gap, wherever that actually is. */
		padding-top: max(calc(2rem + 24px), calc(var(--bvx-close-top, 9px) + 38px + 8px)) !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
		transform: translateX(0) !important;
	}
}

/* ---- FIX 3: hamburger <-> X morphs in place ----
 * Core's close button is a second, genuinely separate element (see the
 * note above) - per the user's own explicit fallback for exactly this
 * case, its functionality is fully preserved (still Core's own button,
 * still Core's own data-wp-on--click="actions.closeMenuOnClick"
 * handler, still inside Core's own focus-trap boundary/still a
 * descendant of the container Core's focusout handler checks against)
 * and only its CSS position changes, to visually occupy the exact
 * hamburger slot instead of Core's default top:0;right:0.
 *
 * Because this button is a SIBLING of `-content` (not nested inside
 * it per FIX 2), it is never a descendant of anything transformed, so
 * it never slides across the screen with the links pane - it simply
 * sits at these fixed coordinates the whole time, only its own bars
 * animate. The original hamburger/open button underneath (section 3,
 * completely untouched) is unchanged and simply becomes covered by the
 * opaque drawer overlay once open, exactly as it already was before
 * this round - so at any moment there is exactly one visible control:
 * the hamburger's bars when closed, this repositioned button's X when
 * open. Never two.
 *
 * round 6 correction: top/left are NO LONGER a hardcoded per-template
 * guess (84px for Account, 9px for Cart/Checkout, assuming a fixed
 * 75px/0px header offset). Live testing showed that guess was wrong on
 * My Account specifically - the X dropped down into the drawer content
 * and overlapped the Dashboard row there, while Cart/Checkout (which
 * happened to use the same math, just with a 0px offset) stayed
 * correct. Root cause: the close button's own positioned ancestor is
 * Core's container (position:fixed;inset:0, confirmed in Core's real
 * style.css - set unconditionally, not gated on .is-menu-open), which
 * is pinned to the true VIEWPORT, not to the header - so any hardcoded
 * top value is only ever correct for whatever scroll position/header
 * behavior it was measured at. Account's header evidently does not
 * resolve to the same viewport offset at open-time that our static
 * fixture (unscrolled, non-sticky assumption) predicted; rather than
 * guess a second arbitrary number, the fix removes the guess entirely.
 *
 * bvx-shop-chrome-mobile-header.js now reads the OPEN/hamburger
 * button's own getBoundingClientRect() at the moment it's clicked
 * (plus on resize) and writes that as --bvx-close-top/--bvx-close-left
 * custom properties on :root. This button is used as-is here purely
 * for its real-time on-screen position - it is already live-filed
 * against My Account/Cart/Checkout only and never for Core's own
 * open/close logic, so Core's click handling is untouched. The close
 * button below simply reads those two properties, so it always lands
 * exactly on top of wherever the hamburger really is, on every
 * template, under whatever causes Account to differ (no longer
 * necessary to know why) - this is the "same header-relative
 * coordinate system" for all three: one mechanism, not three guesses.
 * The var() fallback (9px/20px) matches Cart/Checkout's own previous,
 * already-correct hardcoded numbers, so if the JS hasn't run yet for
 * any reason, nothing regresses there. Bar geometry (22x1px, top:
 * 16/22px, #0A0A0A, translateY(+-6px) rotate(+-45deg)) is copied
 * verbatim from section 3's own hamburger bars so the control reads as
 * one continuous element, not a visual swap to a different icon.
 */
@media (max-width: 768px) {
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close {
		/* Cancels Core's own default position:absolute;top:0;right:0 -
		   the exact cause of "close button on the right". */
		right: auto !important;
		bottom: auto !important;
		top: var(--bvx-close-top, 9px) !important;
		left: var(--bvx-close-left, 20px) !important;
		width: 38px !important;
		height: 38px !important;
		padding: 0 !important;
		margin: 0 !important;
		background: none !important;
		border: none !important;
		box-shadow: none !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
		z-index: 2;
	}

	/* Hides Core's own default close icon/label, exactly like section 3
	   already does for the open button's own default icon. */
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close > *,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close > *,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close > * {
		display: none !important;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after {
		content: "";
		position: absolute;
		left: 50%;
		width: 22px;
		height: 1px;
		background: #0A0A0A;
		transform: translateX(-50%);
		/* round 6: matched to the .65s slide above so the morph and the
		   slide read as one synchronized gesture, not two different
		   speeds. */
		transition: transform 0.65s cubic-bezier(0.77, 0, 0.18, 1);
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::before {
		top: 16px;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container-close::after {
		top: 22px;
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::before,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::before {
		transform: translateX(-50%) translateY(6px) rotate(45deg);
	}

	body.woocommerce-account header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-cart header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::after,
	body.woocommerce-checkout header nav.hostinger-ai-site-navigation .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close::after {
		transform: translateX(-50%) translateY(-6px) rotate(-45deg);
	}
}

/* ==== My Account dashboard-only branded welcome treatment ====
 * Styles the .bvx-dashboard-welcome block rendered by this plugin's
 * templates/myaccount/dashboard.php override (see that file and the
 * woocommerce_locate_template filter in bvx-shop-chrome.php for why
 * this is inherently scoped to the bare /my-account/ dashboard only -
 * the markup this targets physically does not exist on any other
 * page, so no body-class/endpoint gating is needed here either, but
 * the body.woocommerce-account prefix is kept for consistency with
 * this file's own scoping convention throughout).
 *
 * v1.0.41 - rescaled to sit in the same visual system as the footer
 * newsletter's "Join The Drop." block (.bvx-newsletter-heading/-desc,
 * further up this file), per explicit instruction to use that block
 * as the visual reference rather than a separate oversized hero.
 * Heading/sub font-sizes started as that block's own exact values;
 * the whole block is centered (text-align + margin:auto) to match
 * that block's centered column, same as the "Join The Drop"
 * reference. Font families/weights (Inter Tight 900 for the heading,
 * Inter 300 for the sub-copy) and color (#0A0A0A) are unchanged from
 * the original v1.0.40 pass and still match this file's sitewide
 * convention.
 *
 * v1.0.42 - CSS-only visual refinement, three explicit size/spacing
 * changes, nothing else: heading 32px/60.8px -> 30px/54px (mobile/
 * desktop - still a touch smaller than "Join The Drop."'s own 32px/
 * 60.8px, per explicit instruction that the heading read as slightly
 * less dominant than that reference block); letter-spacing rescaled
 * to the same ratio already used here (~-3% of font-size, unchanged
 * ratio from v1.0.41) rather than left at the old pixel value, so
 * the "same... tracking system" carries over proportionally: -0.9px/
 * -1.62px. Sub-copy desktop font-size 14.4px -> 14px, matching mobile
 * (mobile was already 14px, unchanged). Logout line top margin
 * 10px -> 18px mobile, 14px desktop (explicit new per-breakpoint
 * values, replacing the one shared 10px). No copy, color, opacity,
 * font-family/weight, centering, max-width, or the dashboard-only
 * scoping changed.
 */
body.woocommerce-account .bvx-dashboard-welcome {
	margin: 0 0 40px;
	text-align: center;
}

body.woocommerce-account .bvx-dashboard-welcome-heading {
	font-family: "Inter Tight", sans-serif;
	font-size: 30px;
	font-weight: 900;
	letter-spacing: -0.9px;
	line-height: normal;
	color: #0A0A0A;
	margin: 0 0 10px;
}

/* v1.0.43 - mobile-only forced line-break before "WE NOTICED." (see
 * the span wrapping it in templates/myaccount/dashboard.php), so the
 * mobile wrap lands at "YOU'RE BACK." / "WE NOTICED." instead of the
 * default wrap splitting "WE" from "NOTICED.". display:inline here
 * is the explicit default (not strictly needed, since a bare <span>
 * is inline already, but stated so this rule is self-contained and
 * the mobile-only override below reads as a deliberate, scoped
 * change rather than relying on the browser default). Font-size,
 * weight, letter-spacing, color, and centering are all inherited
 * unchanged from .bvx-dashboard-welcome-heading - nothing here
 * duplicates or overrides any of that. */
body.woocommerce-account .bvx-dashboard-welcome-heading .bvx-dashboard-welcome-break {
	display: inline;
}

@media (max-width: 768px) {
	body.woocommerce-account .bvx-dashboard-welcome-heading .bvx-dashboard-welcome-break {
		display: block;
	}
}

body.woocommerce-account .bvx-dashboard-welcome-sub {
	font-family: "Inter", sans-serif;
	font-size: 14px;
	font-weight: 300;
	line-height: normal;
	color: #0A0A0A;
	opacity: 0.45;
	margin: 0 auto;
	max-width: 320px;
}

body.woocommerce-account .bvx-dashboard-welcome-sub strong {
	font-weight: 600;
	opacity: 1;
}

/* Restored identity/logout line - smaller and more understated than
 * the sub-copy above it, same muted near-black, no new color. The
 * real wc_logout_url() link (see the template) is untouched by this
 * rule; only its typography/spacing is styled. */
body.woocommerce-account .bvx-dashboard-welcome-logout {
	font-family: "Inter", sans-serif;
	font-size: 12px;
	font-weight: 400;
	line-height: normal;
	color: #0A0A0A;
	opacity: 0.4;
	margin: 18px 0 0;
}

body.woocommerce-account .bvx-dashboard-welcome-logout a {
	color: inherit;
	text-decoration: underline;
}

@media (min-width: 769px) {
	body.woocommerce-account .bvx-dashboard-welcome-heading {
		font-size: 54px;
		letter-spacing: -1.62px;
	}

	body.woocommerce-account .bvx-dashboard-welcome-sub {
		font-size: 14px;
		max-width: 400px;
	}

	body.woocommerce-account .bvx-dashboard-welcome-logout {
		font-size: 12.8px;
		margin-top: 14px;
	}
}

/* ==== My Account "My account" page-title removal - dashboard only ====
 * Hides the theme's generic page-title heading ("My account") above
 * this welcome block, on the bare dashboard ONLY. Scoped via
 * body.bvx-dashboard-page - a dedicated marker class added only when
 * is_account_page() && !is_wc_endpoint_url() (see the body_class
 * filter in bvx-shop-chrome.php) - which is never present on Orders,
 * Addresses, Payment Methods, Account Details, or any other endpoint,
 * so those keep their heading exactly as before. Selectors reuse this
 * file's own existing pattern for removing a block-theme page title
 * (see the v1.0.28 Cart "Page title" rule, further up this file):
 * the two standard markup shapes a block theme emits for this
 * (wp-block-post-title, and the classic entry-title fallback),
 * scoped to :first-of-type so a heading inside the dashboard content
 * itself is never affected. Only the heading and its own wrapper's
 * margin/padding are touched - no other spacing on the page changes. */
body.bvx-dashboard-page main h1.wp-block-post-title:first-of-type,
body.bvx-dashboard-page main .entry-title:first-of-type,
body.bvx-dashboard-page main h1.entry-title:first-of-type {
	display: none !important;
}
body.bvx-dashboard-page main > .wp-block-group:has(> h1.wp-block-post-title),
body.bvx-dashboard-page main > .wp-block-post-title {
	margin: 0 !important;
	padding: 0 !important;
}

/* ==== Cart-only empty-state cleanup ("New in store" removal + START
 * SHOPPING button) ====
 * This backend must not expose WooCommerce's own product-browsing/
 * store UX when the cart is actually empty - the real storefront is
 * https://wearbvx.com/, not this backend's own Woo product pages.
 * Every rule below is scoped inside
 * .wp-block-woocommerce-empty-cart-block - WooCommerce Blocks' own
 * real, registered wrapper for the Cart page's empty-cart inner
 * block (Automattic\WooCommerce\Blocks\BlockTypes\EmptyCartBlock),
 * which Woo's own server-side rendering only ever outputs when the
 * cart genuinely has no items - never alongside the filled-cart
 * layout. That scoping is what makes this inherently cart-empty-only:
 * the existing Cart-with-items layout is never touched because this
 * wrapper simply does not exist in the markup then.
 *
 * v1.0.44 round 2 - LIVE-CONFIRMED CORRECTION: the user inspected the
 * real shop.wearbvx.com/cart/ empty state this round. The outer root
 * - .wp-block-woocommerce-empty-cart-block - is confirmed correct,
 * but the "New in store" recommendation area is NOT WooCommerce's
 * cross-sells/product-collection blocks this file originally guessed
 * (those selectors never matched on this site - harmless no-ops, but
 * wrong). The real, live-confirmed markup uses Woo's older grid-style
 * "Products (Block)" classes instead: .wc-block-grid,
 * .wp-block-product-new, .wp-block-woocommerce-product-new,
 * .wc-block-grid__products, .wc-block-grid__product - with the
 * product title and "Select options" link both confirmed live
 * pointing into https://shop.wearbvx.com/product/.../ . Narrowed to
 * the two confirmed root-level selectors below, covering both cases
 * (two separate elements, or both classes on the one element) in a
 * single rule either way - hiding the root hides every descendant
 * link/price/button inside it in one shot, with no need to also list
 * .wc-block-grid__product or .wc-block-grid__products separately.
 */

/* Hides the entire product-recommendation area at its confirmed live
 * root - no product cards, no prices, no "Select options", no links
 * into Woo's own product/store pages. */
.wp-block-woocommerce-empty-cart-block .wc-block-grid.wp-block-product-new,
.wp-block-woocommerce-empty-cart-block .wp-block-woocommerce-product-new {
	display: none !important;
}

/* Hides whichever original CTA button(s) already exist inside the
 * empty-cart block (Woo's own default, or a site-customized label -
 * text/destination not confirmed this round either way) so there is
 * never a duplicate/competing button next to the new one below. */
.wp-block-woocommerce-empty-cart-block .wp-block-button {
	display: none !important;
}

/* Centers the remaining content (icon + "Your cart is currently
 * empty!" heading, both untouched/unchanged - existing icon kept per
 * explicit instruction) and the new button below it, with clean,
 * generous spacing - "Nothing else" per the explicit desired state. */
.wp-block-woocommerce-empty-cart-block {
	text-align: center;
}

.bvx-cart-start-shopping-wrap {
	margin: 24px 0 0;
	text-align: center;
}

.bvx-cart-start-shopping-button {
	display: inline-block;
	font-family: "JetBrains Mono", monospace;
	font-size: 12px;
	font-weight: 400;
	letter-spacing: 2px;
	text-transform: uppercase;
	text-decoration: none;
	color: #0A0A0A;
	background-color: #BCFF00;
	padding: 14px 32px;
	border-radius: 999px;
}