/**
 * Header navigation - replaces UberMenu's styling entirely. Fresh class namespace
 * (.ezdock-nav) rather than reusing the old .nav-primary/.sub-menu/core-walker classes -
 * main.css still has legacy rules keyed to those exact names, and reusing them risks silent
 * bleed-through during the transition.
 *
 * Palette matches the site's existing brand colors (--primary/--accent used elsewhere) -
 * this is a first functional pass, not a final visual design.
 */

:root {
	--ezdock-nav-primary: #005c97;
	--ezdock-nav-primary-dark: #003560;
	--ezdock-nav-accent: #00b5df;
	--ezdock-header-height: 70px;
	--ezdock-nav-row-bottom: 70px;
}

.ezdock-nav__mobile-toggle {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: 8px;
	width: auto;
	height: 44px;
	padding: 0 4px;
	background: transparent;
	border: none;
	cursor: pointer;
}

.ezdock-nav__mobile-toggle-icon,
.ezdock-nav__mobile-toggle-icon::before,
.ezdock-nav__mobile-toggle-icon::after {
	display: block;
	width: 24px;
	height: 2px;
	background: var(--ezdock-nav-primary-dark);
	transition: transform 0.2s ease, opacity 0.2s ease;
}

.ezdock-nav__mobile-toggle-icon {
	position: relative;
	flex-shrink: 0;
}

.ezdock-nav__mobile-toggle-icon::before,
.ezdock-nav__mobile-toggle-icon::after {
	content: "";
	position: absolute;
	left: 0;
}

.ezdock-nav__mobile-toggle-icon::before { top: -7px; }
.ezdock-nav__mobile-toggle-icon::after { top: 7px; }

.ezdock-nav__mobile-toggle[aria-expanded="true"] .ezdock-nav__mobile-toggle-icon {
	background: transparent;
}
.ezdock-nav__mobile-toggle[aria-expanded="true"] .ezdock-nav__mobile-toggle-icon::before {
	top: 0;
	transform: rotate(45deg);
}
.ezdock-nav__mobile-toggle[aria-expanded="true"] .ezdock-nav__mobile-toggle-icon::after {
	top: 0;
	transform: rotate(-45deg);
}

.ezdock-nav__mobile-toggle-label {
	font-weight: 600;
	font-size: 14px;
	text-transform: uppercase;
	color: var(--ezdock-nav-primary-dark);
}

/*
 * The homepage header is transparent, floating directly over a photo hero
 * (.inverse-page-header in main.css, added via is_front_page()) - the default dark navy
 * icon/text is low-contrast there, same reason the desktop nav's own .home override exists
 * further down. Every other page has a solid (white) header background, where the default
 * dark color already reads fine.
 */
.inverse-page-header .ezdock-nav__mobile-toggle-icon,
.inverse-page-header .ezdock-nav__mobile-toggle-icon::before,
.inverse-page-header .ezdock-nav__mobile-toggle-icon::after {
	background: #fff;
}

.inverse-page-header .ezdock-nav__mobile-toggle-label {
	color: #fff;
}

.ezdock-nav__list {
	display: flex;
	align-items: center;
	list-style: none;
	margin: 0;
	padding: 0;
}

.ezdock-nav__item {
	position: relative;
}

.ezdock-nav__trigger {
	display: flex;
	align-items: center;
}

.ezdock-nav__link,
.ezdock-nav__link--no-href {
	display: inline-block;
	padding: 14px 2px 12px 14px;
	color: var(--ezdock-nav-primary-dark);
	font-weight: 600;
	font-size: 14px;
	text-decoration: none;
	text-transform: uppercase;
	white-space: nowrap;
}

.ezdock-nav__link:hover {
	color: var(--ezdock-nav-primary);
}

/*
 * Sized down from an earlier 32px (plus the link's own 14px right padding) - together those
 * put a good ~30px of empty space between the link text and the caret's own visual center,
 * which read as the arrow floating far to the right of its link. 24px is WCAG 2.5.5's minimum
 * touch-target size, so this is as tight as the button can get without failing that.
 * line-height:0 removes a <button>'s own default line-height from the vertical-centering math
 * - align-items:center on .ezdock-nav__trigger centers this against the link's own box, but a
 * button's line-height can otherwise nudge its content off that center by a couple of pixels.
 */
.ezdock-nav__toggle {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	width: 24px;
	height: 24px;
	padding: 0;
	line-height: 0;
	background: transparent;
	border: none;
	cursor: pointer;
}

/*
 * box-sizing:border-box keeps the border-right/border-bottom (used to draw the chevron)
 * inside the declared 8x8 box instead of adding to it - content-box (the default) would make
 * this render as an asymmetric 10x10 box (8px content + 2px border, but only on the right/
 * bottom sides).
 *
 * transform-origin is the real fix for the arrow visibly jumping position between the closed
 * (rotate 45deg) and open (rotate -135deg) states: only 2 of the box's 4 sides are ever drawn,
 * so the visible ink (an L-shaped corner bracket) sits well off the box's own geometric center
 * (50% 50%, the default origin) - its actual centroid works out to roughly 66% 66% for an 8px
 * box with 2px borders. Rotating around the geometric center instead means the OFF-CENTER ink
 * sweeps around that center as the angle changes; 45deg and -135deg are exactly 180deg apart,
 * so the ink ends up on completely opposite sides of center between the two states - too low
 * when closed, too high when open, by design of the technique, not a sizing mistake. Rotating
 * around the ink's own centroid instead (transform-origin: 66% 66%) keeps that centroid fixed
 * in place regardless of angle, so both states land in the same spot.
 *
 * The margin below compensates for two remaining, constant (not rotation-dependent) offsets:
 * the ink centroid still sits ~1.3px right/down of the button's true center even once the
 * jump-between-states issue is fixed, and the link text beside it is uppercase, so its
 * line-height reserves descender space (for letters like "g"/"y") that all-caps text never
 * uses, making the text sit optically higher than its own line-height box's geometric center.
 */
.ezdock-nav__caret {
	box-sizing: border-box;
	width: 8px;
	height: 8px;
	transform-origin: 66% 66%;
	margin: -3px 0 0 -1px;
	border-right: 2px solid var(--ezdock-nav-primary-dark);
	border-bottom: 2px solid var(--ezdock-nav-primary-dark);
	transform: rotate(45deg);
	transition: transform 0.2s ease;
}

.ezdock-nav__toggle[aria-expanded="true"] .ezdock-nav__caret {
	transform: rotate(-135deg);
}

/*
 * The homepage's header is transparent, floating directly over a photo hero, ONLY while
 * header.php's `<header class="page-header ... inverse-page-header">` still has that class -
 * main.js's FX.Affix removes it once scrolled past 200px, at which point the header gets a
 * solid background (see main.css) and needs its normal dark text back. Scoped to
 * `.inverse-page-header` specifically, not just `.home` - `.home` never changes on scroll (it's
 * a static body class), so a `.home`-only selector kept forcing white text after scrolling,
 * putting white text on the now-solid (white) sticky header - invisible. The old nav had this
 * same bug potential (`.home .nav-primary a { color: #fff; }`, also unscoped to scroll state)
 * but apparently never surfaced it. Width-only breakpoint, not scoped to the hover-capable
 * media query below - this is about contrast against the photo, unrelated to hover capability,
 * so a touchscreen laptop on the homepage needs this too.
 */
@media (min-width: 1025px) {
	.home .inverse-page-header .ezdock-nav__link,
	.home .inverse-page-header .ezdock-nav__link--no-href {
		color: #fff;
	}

	/*
	 * Scoped to the top-level trigger's own caret (direct child of .ezdock-nav__item) only -
	 * a nested caret (e.g. "Docks by Water Type" inside "Resources") sits inside the dropdown
	 * panel's own white background, never over the photo hero, so forcing it white the same
	 * way made it invisible (white-on-white) instead of just unreadable-on-photo like the
	 * unscoped version assumed every caret on the homepage was.
	 */
	.home .inverse-page-header .ezdock-nav__item > .ezdock-nav__trigger .ezdock-nav__caret {
		border-color: #fff;
	}

	/* Old nav used a distinct hover color here too (#999966, not the navy used on other
	   pages) - the default hover color would have the same low-contrast problem against
	   the photo hero as the unhovered state did. */
	.home .inverse-page-header .ezdock-nav__link:hover {
		color: #999966;
	}
}

/* Every interactive element needs a visible focus state distinct from :hover. */
.ezdock-nav__link:focus-visible,
.ezdock-nav__toggle:focus-visible,
.ezdock-nav__mobile-toggle:focus-visible,
.ezdock-nav__dropdown a:focus-visible,
.ezdock-nav__mega a:focus-visible {
	outline: 2px solid var(--ezdock-nav-accent);
	outline-offset: 2px;
}

.ezdock-nav__dropdown {
	list-style: none;
	margin: 0;
	padding: 8px 0;
}

.ezdock-nav__dropdown a {
	display: block;
	padding: 10px 16px;
	color: var(--ezdock-nav-primary-dark);
	text-decoration: none;
	font-size: 14px;
}

.ezdock-nav__trigger--nested {
	display: flex;
	align-items: center;
	justify-content: space-between;
	/* The toggle button itself has no padding of its own (see .ezdock-nav__toggle) and this
	   row has none either, so space-between otherwise pushes it flush against the dropdown's
	   right inner edge (.ezdock-nav__dropdown has 0 horizontal padding - only its <a> children
	   carry the visual 16px inset). Matches the same 16px used everywhere else in the dropdown. */
	padding-right: 16px;
}

.ezdock-nav__trigger--nested a {
	padding: 10px 16px;
}

.ezdock-nav__dropdown--nested {
	/* padding-top:0 overrides the base .ezdock-nav__dropdown rule's `padding: 8px 0` (this
	   still carries that base class too) - without it, the nested list sat a visible 8px
	   below its parent trigger instead of reading as directly attached to it. */
	padding-top: 0;
	padding-left: 16px;
}

/*
 * Same connector line + bullet treatment as .ezdock-nav__mega-column-links--nested, just in
 * --ezdock-nav-primary-dark instead of white - this list sits on a light dropdown panel, not
 * the mega menu's dark one. See that rule's own comment for why centering uses translateX(-50%)
 * off a shared reference point rather than a shared left edge, and why the line is drawn as one
 * segment per <li> rather than a single tall line on the <ul>.
 */
.ezdock-nav__dropdown--nested li {
	position: relative;
}

/*
 * left is +8px here, not a small negative number like the mega version's -12px - this list's
 * <a> inherits .ezdock-nav__dropdown a's own `padding: 10px 16px`, stacking on top of this
 * <ul>'s own 16px padding-left, so the actual visible text sits at 32px from the <li>'s edge,
 * not 16px (confirmed directly via Range.getClientRects(), not assumed) - the mega version's
 * nested <a> has no horizontal padding of its own, so it didn't need this adjustment. +6px
 * lands the connector a sensible distance to the left of the real text position instead of
 * ~28px away from it, which read as disconnected/"too far left" against the visible content.
 */
.ezdock-nav__dropdown--nested li::before {
	content: "";
	position: absolute;
	left: 6px;
	top: 50%;
	width: 4px;
	height: 4px;
	border-radius: 50%;
	background: rgba(0, 53, 96, 0.3);
	transform: translate(-50%, -50%);
}

.ezdock-nav__dropdown--nested li::after {
	content: "";
	position: absolute;
	left: 6px;
	top: 0;
	bottom: 0;
	width: 2px;
	background: rgba(0, 53, 96, 0.15);
	transform: translateX(-50%);
}

.ezdock-nav__dropdown--nested li:first-child::after {
	background: linear-gradient(to bottom, transparent, rgba(0, 53, 96, 0.15) 24px, rgba(0, 53, 96, 0.15));
}

.ezdock-nav__dropdown--nested li:last-child::after {
	bottom: 50%;
}

/*
 * Mega menu colors/sizing pulled directly from the live production styling
 * (content/plugins/ubermenu/custom/custom.css - the plugin is still installed, its own
 * site-specific CSS untouched, so this was the real source of truth rather than a guess):
 * dark navy panel (#2a3546), light-gray/white text, #00b5df/#008ca8 accent + hover.
 */
.ezdock-nav__mega {
	background: #2a3546;
}

.ezdock-nav__mega-columns {
	display: flex;
	flex: 1 1 auto;
	flex-wrap: wrap;
	gap: 40px;
}

.ezdock-nav__mega-column {
	flex: 1 1 160px;
	min-width: 160px;
}

.ezdock-nav__mega-column-title {
	display: block;
	margin-bottom: 8px;
	font-weight: 900;
	font-size: 16px;
	text-transform: uppercase;
	color: #cbcbcb;
	text-decoration: none;
}

.ezdock-nav__mega-column-links {
	list-style: none;
	margin: 0;
	padding: 0;
}

.ezdock-nav__mega-column-links a,
.ezdock-nav__mega-column-links-no-href {
	display: block;
	padding: 8px 0;
	color: #fff;
	text-decoration: none;
	font-size: 14px;
}

.ezdock-nav__mega-column-links a:hover {
	color: #008ca8;
}

/*
 * A column link can have its own nested group (e.g. "PWC EZ Ports" -> EZ Port
 * 260/280/2i/Inline), matching production's actual menu structure - static and always
 * visible (not a toggle/accordion) since it's already inside an open mega menu, just
 * indented to show it belongs under the link above it.
 */
.ezdock-nav__mega-column-links--nested {
	padding-left: 16px;
}

/*
 * A vertical connector line + a small bullet per link, reading as "these belong to the item
 * above". Both share one center x-position (4px inside the 16px padding-left above, left of
 * the link text - a bullet/line's own `left: -12px` is the same 4px measured from the <li>'s
 * edge instead of the <ul>'s, since the <li> already starts 16px in from the <ul>'s edge) via
 * `translateX(-50%)` on each, rather than lining up their raw left edges - two shapes of
 * different widths (a 4px bullet, a 2px line) sharing a left edge does NOT share a center,
 * which read as visibly off before this.
 *
 * The line is drawn per-<li> (its own top to its own bottom) rather than as one tall line on
 * the <ul>, specifically so it can stop exactly at the last bullet instead of continuing past
 * it to the bottom of the list - each segment's bottom edge is the next one's top edge, so
 * they still read as one continuous line. Only the first segment fades in from transparent
 * (so the line reads as growing out of the parent item above, not starting with a hard edge);
 * every other segment, including the visible top portion of the last one, is solid.
 */
.ezdock-nav__mega-column-links--nested li {
	position: relative;
}

.ezdock-nav__mega-column-links--nested li::before {
	content: "";
	position: absolute;
	left: -12px;
	top: 50%;
	width: 4px;
	height: 4px;
	border-radius: 50%;
	background: rgba(255, 255, 255, 0.3);
	transform: translate(-50%, -50%);
}

.ezdock-nav__mega-column-links--nested li::after {
	content: "";
	position: absolute;
	left: -12px;
	top: 0;
	bottom: 0;
	width: 2px;
	background: rgba(255, 255, 255, 0.15);
	transform: translateX(-50%);
}

.ezdock-nav__mega-column-links--nested li:first-child::after {
	background: linear-gradient(to bottom, transparent, rgba(255, 255, 255, 0.15) 24px, rgba(255, 255, 255, 0.15));
}

.ezdock-nav__mega-column-links--nested li:last-child::after {
	/* Stops the assembled line at this <li>'s own vertical center - the same 50% mark its own
	   bullet sits at - instead of continuing to the bottom of the last row. */
	bottom: 50%;
}

.ezdock-nav__mega-column-links--nested a {
	padding: 4px 0;
	font-size: 13px;
}

.ezdock-nav__dropdown a:hover {
	color: var(--ezdock-nav-primary);
}

/*
 * 237x239px background-photo box, matching the original's exact fixed size
 * (content/plugins/ubermenu/custom/mega-nav-img*.jpg) - flex-shrink:0 keeps it from being
 * squeezed by the columns next to it.
 */
.ezdock-nav__mega-promo {
	flex: 0 0 237px;
	width: 237px;
	height: 239px;
	border-radius: 8px;
	background-size: cover;
	background-position: center;
	background-color: #1c2531;
	display: flex;
	flex-direction: column;
	align-items: center;
	justify-content: center;
	text-align: center;
	padding: 0 17px;
}

.ezdock-nav__mega-promo h3 {
	color: #fff;
	font-size: 20px;
	margin: 0 0 12px;
}

/*
 * The promo content comes from an ACF wysiwyg field - re-saving it through the visual editor
 * wraps the button in a <p> (wpautop), which carries the browser's default paragraph margin,
 * and the button's own .btn-primary class (main.css, used site-wide) adds its own
 * `margin: 10px 2px` on top of that - two separate, stacked sources of unwanted space here,
 * not one.
 */
.ezdock-nav__mega-promo p {
	margin: 0;
}

.ezdock-nav__mega-promo a {
	display: inline-block;
	background-color: var(--ezdock-nav-accent);
	color: #fff;
	padding: 6px 14px;
	margin: 0;
	text-decoration: none;
}

.ezdock-nav__mega-promo a:hover {
	background-color: #008ca8;
}

/* ---- Desktop (hover-capable pointer devices) ---- */
@media (min-width: 1025px) and (hover: hover) and (pointer: fine) {
	/*
	 * Explicit display:none baseline - deliberately NOT relying on the native [hidden]
	 * attribute's own (very low-specificity) display:none to keep this closed by default.
	 * Found a real bug from doing that: a later, unconditional `.ezdock-nav__item--mega
	 * .ezdock-nav__mega { display:flex }` rule (two classes) beat [hidden]'s specificity
	 * outright, with no :hover/:focus-within gate at all - both mega menus rendered open on
	 * every page load, no interaction needed. Making THIS stylesheet the sole authority for
	 * open/closed state (rather than racing against the browser's own [hidden] handling)
	 * means every rule that shows something is required to earn it via :not([hidden])
	 * (JS-driven open, via the click-toggle removing the attribute) or :hover/:focus-within
	 * (pure-CSS convenience) - nothing can show unconditionally by accident again.
	 */
	.ezdock-nav__dropdown,
	.ezdock-nav__mega {
		display: none;
		z-index: 100;
		box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12);
	}

	/* Plain flyouts (Resources, etc.) stay anchored directly under their own trigger <li>,
	   with the light dropdown treatment - only the mega menu itself uses the dark navy panel
	   and the full-header-width positioning set separately below. */
	.ezdock-nav__dropdown {
		position: absolute;
		/* Pulled up 7px to slightly overlap/tuck under the header row rather than starting
		   with a hard seam right at its edge - a deliberate visual choice, not a gap fix. */
		top: calc(100% - 7px);
		left: 0;
		min-width: 220px;
		background: #fff;
		border: 1px solid #d5e4ee;
		border-radius: 6px;
	}

	/* Tighter vertical rhythm than the base (mobile-shared) 10px - desktop's mouse-driven
	   list doesn't need the extra room a touch target does. */
	.ezdock-nav__dropdown a {
		padding-top: 6px;
		padding-bottom: 6px;
	}

	/* Tighter still - a nested sub-list (e.g. Ocean/River/Lake Docks) reads better with less
	   room between its own rows than the top-level list it hangs off of, same reasoning as
	   .ezdock-nav__mega-column-links--nested a's own tighter 4px 0. */
	.ezdock-nav__dropdown--nested a {
		padding-top: 2px;
		padding-bottom: 2px;
	}

	/*
	 * The mega menu is meant to span the full width of the header row, regardless of which
	 * top-level item (Products, Markets, ...) triggered it - anchoring it to its own trigger
	 * <li> via position:absolute (like a plain dropdown) can only ever size/position it
	 * relative to that one item, never the full header. position:fixed escapes the trigger's
	 * positioning context entirely and lets it be placed using the header row's own real
	 * bounds instead - measured in JS (header-nav.js's setHeaderBoundsVars(), same pattern as
	 * the existing --ezdock-header-height var) since "as wide as that other element" isn't
	 * expressible in pure CSS.
	 */
	.ezdock-nav__item--mega .ezdock-nav__mega {
		position: fixed;
		/*
		 * --ezdock-nav-row-bottom (header-nav.js), not --ezdock-header-height - the latter is
		 * the bottom of the WHOLE header (logo row + search/buttons row + nav row combined),
		 * noticeably lower than where a plain dropdown's own top:100% lands (the nav row's own
		 * bottom edge specifically). Using the full header height put this panel visibly lower
		 * than a plain dropdown opened from the same row - confirmed via direct measurement,
		 * not just eyeballing, that the two now share the same starting edge.
		 *
		 * Pulled up 7px on top of that to slightly overlap/tuck under the header row, same
		 * deliberate visual choice as .ezdock-nav__dropdown above, not a gap fix - the header's
		 * own z-index (main.css) already sits above this panel's, so the overlap tucks behind
		 * it cleanly.
		 */
		top: calc(var(--ezdock-nav-row-bottom) - 7px);
		left: var(--ezdock-header-bounds-left, 0);
		width: var(--ezdock-header-bounds-width, auto);
		align-items: flex-start;
		/*
		 * Uniform padding on all 4 sides, plus a gap for the space between the promo box and
		 * the columns - previously this box had padding:20px 0 (vertical only) and the promo
		 * box below had its own 20px margin on top/left/bottom, so top/bottom edges got
		 * DOUBLE padding (this box's 20px + the promo's own 20px = 40px) while the left edge
		 * only ever got the promo's single 20px margin - the mismatch was two different
		 * spacing mechanisms stacking on some edges and not others, not deliberate asymmetry.
		 * Desktop-only (not the unconditional base rule) so it can't leak into the mobile
		 * flyout, which keeps its own separate, edge-to-edge-appropriate spacing. Bumped from
		 * 20px to 32px - the whole panel read as cramped at 20px, especially with 4-5 columns
		 * of content packed against a full-header-width panel.
		 */
		padding: 32px;
		gap: 32px;
		border-radius: 8px;
	}

	/*
	 * Columns are sized to their own content (flex: 0 0 auto) rather than stretched to fill
	 * equal shares of the row (flex: 1 ...) - with 5 columns of very different content
	 * lengths (e.g. "Kayak/Canoe Launches" has 2 short links, "Add-ons" has many), equal-width
	 * columns left wildly different amounts of empty space after each one's actual content,
	 * which read as uneven gaps even though the column boxes themselves were evenly sized.
	 * justify-content:space-between distributes real leftover width as equal gaps between
	 * columns instead, which is the actual thing that needed to be even.
	 */
	.ezdock-nav__item--mega .ezdock-nav__mega-columns {
		flex: 1 1 auto;
		flex-wrap: nowrap;
		justify-content: space-between;
	}

	.ezdock-nav__item--mega .ezdock-nav__mega-column {
		flex: 0 0 auto;
		min-width: 140px;
	}

	/*
	 * The per-column accordion toggle (see header-nav.css's mobile query / header-nav.js) is
	 * mobile-only - a hover-opened desktop mega panel has room to just show every column's
	 * full link list at once, same as it always has. The template always renders the toggle
	 * button and `hidden` on the links list regardless of width, so desktop needs to actively
	 * override both: hide the toggle, and force the links to display despite `hidden` - same
	 * "explicit display baseline, don't rely on [hidden]'s own low specificity" reasoning as
	 * .ezdock-nav__dropdown/.ezdock-nav__mega above.
	 */
	.ezdock-nav__mega-column-toggle {
		display: none;
	}

	.ezdock-nav__mega-column-links {
		display: block;
	}

	.ezdock-nav__dropdown:not([hidden]),
	.ezdock-nav__item:hover > .ezdock-nav__dropdown,
	.ezdock-nav__item:focus-within > .ezdock-nav__dropdown {
		display: block;
	}

	/*
	 * Plain dropdowns open via pure CSS :hover/:focus-within above, with no JS involved at all
	 * (unlike mega menus, which need JS hover-intent - see header-nav.js - since their panel is
	 * position:fixed and physically separate from the trigger). That means aria-expanded never
	 * actually flips to "true" during a hover-only open, so the caret's rotation rule below
	 * (keyed to [aria-expanded="true"], global, still needed for click/mobile) never matched -
	 * the arrow only ever rotated for mega items, whose JS explicitly sets aria-expanded on
	 * hover too. Mirrors the exact same :hover/:focus-within trigger the dropdown panel itself
	 * uses just above, so the two are never out of sync.
	 *
	 * Both this and the dropdown rule above are scoped with `>` (direct child of .ezdock-nav__item),
	 * not a bare descendant selector - a nested item's own dropdown/caret (e.g. "Docks by Water
	 * Type" inside "Resources") lives inside Resources' own <ul>, which is ALSO a descendant of
	 * the same top-level .ezdock-nav__item. A bare `.ezdock-nav__item:hover .ezdock-nav__dropdown`
	 * matched both, so merely hovering "Resources" force-opened the nested submenu too (CSS
	 * display:block, higher specificity than [hidden]) regardless of its own aria-expanded/hidden
	 * state - clicking its toggle correctly flipped that state under the hood (confirmed via
	 * automated click test), but had no visible effect while the mouse stayed anywhere over
	 * "Resources", since the hover rule kept forcing it open independent of the click state. The
	 * nested dropdown's own hover-to-open behavior instead comes from it being a descendant of the
	 * OUTER dropdown, which is itself shown via the (correctly scoped) rule above once opened.
	 */
	.ezdock-nav__item:hover > .ezdock-nav__trigger .ezdock-nav__caret,
	.ezdock-nav__item:focus-within > .ezdock-nav__trigger .ezdock-nav__caret {
		transform: rotate(-135deg);
	}

	/*
	 * No :hover/:focus-within rule here, deliberately, unlike .ezdock-nav__dropdown above -
	 * the mega panel is position:fixed and can render with real physical distance from its
	 * trigger <li>, which breaks CSS :hover continuity (see header-nav.js's hover-intent
	 * handler, which manages `hidden` directly with a close delay instead). `hidden` is the
	 * sole authority for mega-menu visibility - both that hover-intent JS and the click
	 * toggle already used everywhere else drive it, so they can never fight each other.
	 */
	.ezdock-nav__mega:not([hidden]) {
		display: flex;
	}

	/*
	 * A nested dropdown (e.g. "Docks by Water Type" inside "Resources") is NOT anchored
	 * relative to its own parent <li> the way a top-level dropdown is anchored relative to
	 * its .ezdock-nav__item - .ezdock-nav__dropdown--nested still carries the base
	 * .ezdock-nav__dropdown class, so without this override it inherits the exact same
	 * position:absolute/top:100%/left:0 rule above, calculated against the wrong ancestor
	 * (the outer Resources dropdown isn't a positioned container itself), and ends up
	 * floating wherever that math happens to land instead of inside the Resources box.
	 * Rendering it inline/static instead - same indented-nested-list treatment mobile
	 * already uses - sidesteps needing a second real anchor point entirely.
	 */
	.ezdock-nav__dropdown--nested {
		position: static;
		top: auto;
		left: auto;
		min-width: 0;
		border: none;
		box-shadow: none;
		padding-left: 16px;
	}

}

/*
 * Fullscreen flyout layout - matches the exact same 1024px breakpoint as the .hidden-md-up
 * utility class hiding/showing the mobile toggle button (main.css). The hover/pointer-fine
 * media query above only governs whether hovering ALSO opens a dropdown as a convenience on
 * top of click - it must never change which layout applies, or a wide touchscreen device
 * (hover:none at a desktop width) would get this flyout's hidden nav list with no visible
 * button to open it, since the toggle button's own visibility is purely width-based.
 */
@media (max-width: 1024px) {
	/*
	 * .mainmenu (main.css, pre-existing legacy layout, unrelated to this rebuild) is itself
	 * position:absolute at this breakpoint, offset well below the header's actual visible
	 * band (top:100% relative to .head-col, a short 54px-tall absolutely-positioned strip) -
	 * main.css only ever accounted for this via a rule specifically targeting the OLD
	 * UberMenu toggle's own class (.mainmenu .ubermenu-responsive-toggle), which this button
	 * doesn't have and can't inherit. This button is position:fixed specifically to escape
	 * that messy .mainmenu box.
	 *
	 * BUT .head-col (an ANCESTOR of .mainmenu, same legacy CSS) also has its own
	 * `transform: translateY(-50%)` at this breakpoint - and any transform on an ancestor,
	 * regardless of that ancestor's own position value, silently makes it the containing
	 * block for position:fixed descendants too, per spec. So this button was never actually
	 * positioned relative to the viewport at all - real measurement confirmed its rendered
	 * position matches being relative to .head-col instead, ~10px off from where
	 * var(--ezdock-header-height) (a real viewport-relative measurement) assumed it'd land.
	 * `top: 50%` sidesteps needing to know which box is really the containing block at all -
	 * .head-col's own legacy CSS already centers ITSELF within the visible header band, so
	 * centering within .head-col (its real containing block) lands in the same place as
	 * centering within the header would have.
	 */
	.ezdock-nav__mobile-toggle {
		position: fixed;
		top: 50%;
		right: 16px;
		transform: translateY(-50%);
		z-index: 1000;
	}

	.ezdock-nav__list {
		display: none;
		position: fixed;
		/*
		 * Same containing-block issue as .ezdock-nav__mobile-toggle above: .head-col's own
		 * `transform` makes IT the real containing block for this position:fixed element too,
		 * not the viewport - so `top: var(--ezdock-header-height)` (a true viewport-relative
		 * value) landed ~10px too low here, leaving a gap under the header and overflowing
		 * the same ~10px past the bottom of the screen.
		 *
		 * Unlike the toggle button (a simple center, where .head-col centering itself within
		 * the header meant the two centers already coincided), this needs to land at the
		 * header's true BOTTOM edge specifically - .head-col's own bottom edge does NOT
		 * coincide with that (.head-col is a fixed 54px tall, `main.css`, centered within the
		 * header via top:50%/translateY(-50%), so it has an equal gap above and below itself).
		 * Converting "the header's true bottom, relative to the viewport" into "relative to
		 * .head-col's own top" (what `top` actually measures against here): .head-col's own
		 * top sits (header height - 54px)/2 below the header's top, so subtracting that back
		 * out of the header height gives (header height + 54px)/2 - the same 54px from
		 * .head-col's own CSS, not a new number.
		 */
		top: calc((var(--ezdock-header-height) + 54px) / 2);
		left: 0;
		right: 0;
		width: 100%;
		max-height: none;
		height: calc(100svh - var(--ezdock-header-height));
		overflow-y: auto;
		flex-direction: column;
		align-items: stretch;
		background: #fff;
		z-index: 999;
	}

	html.is-nav-open .ezdock-nav__list {
		display: flex;
	}

	/*
	 * The search box used to live in the collapsed header row itself, alongside the logo and
	 * mobile toggle - but at real phone widths there's simply not enough room for all three at
	 * once, which is exactly why an older rule in main.css (@media max-width:500px) set the
	 * original markup's .headsrch class to display:none outright rather than trying to fit it
	 * in. Rendered here instead, as the first item inside the mobile flyout itself, which has
	 * an entire spacious, dedicated screen to work with.
	 *
	 * Deliberately its own fresh classes (.ezdock-nav__search, not .headsrch) rather than
	 * reusing the original markup's class - that class carries its own breakpoint-specific
	 * CSS (position/width/display rules keyed to the old collapsed-header layout, including
	 * the exact display:none above that broke the first attempt at this) which has nothing to
	 * do with how this box behaves here. Styled fresh below instead, matching the same visual
	 * look (rounded input/button, #3eb5df accent) without inheriting any of that baggage.
	 */
	.ezdock-nav__search-item {
		padding: 16px 20px;
		border-bottom: 1px solid #e0e6ec;
	}

	.ezdock-nav__search {
		display: flex;
		align-items: center;
	}

	.ezdock-nav__search input {
		flex: 1 1 auto;
		min-width: 0;
		height: 40px;
		margin: 0;
		padding: 0 12px;
		border: 1px solid #d5e4ee;
		border-right: none;
		border-radius: 5px 0 0 5px;
		font-size: 14px;
	}

	/*
	 * The real cause of the button sitting visibly lower than the input, found by actually
	 * measuring the two margin boxes rather than guessing again: main.css has global resets
	 * for EVERY text input (`[type="text"] { margin-bottom: 5px; ... }`) and EVERY submit
	 * button (`[type="submit"] { margin: 10px 2px; ... }`) that neither of my previous rules
	 * overrode - margin, not padding or line-height. With align-items:center centering each
	 * child by its own MARGIN box, the button's much larger 10px-top/10px-bottom margin
	 * (which the input doesn't share) made the row's shared cross-axis height 60px instead of
	 * 40px, and centered the input's smaller 45px margin box within that - working out to the
	 * input's visible box sitting 2.5px higher than the button's on both edges. margin:0 on
	 * both elements below removes the asymmetry entirely, rather than trying to compensate
	 * for it. The flex-centering/line-height:0 from the previous attempt stays - real
	 * improvements for the icon's own position inside the button, just not what was causing
	 * this particular symptom.
	 */
	.ezdock-nav__search-submit {
		display: flex;
		align-items: center;
		justify-content: center;
		flex-shrink: 0;
		width: 45px;
		height: 40px;
		margin: 0;
		padding: 0;
		line-height: 0;
		background-color: #3eb5df;
		border: 1px solid #3eb5df;
		border-radius: 0 5px 5px 0;
		color: #fff;
		cursor: pointer;
	}

	/*
	 * A position:fixed body always renders from its own top edge regardless of scroll
	 * position, and since the real scroll position is never touched (only visually
	 * overridden), removing this on close snaps back to exactly where the page was - no
	 * scrollY bookkeeping needed in JS at all. `top:0`/`left:0` unconditionally, not a
	 * computed offset.
	 */
	html.is-nav-open {
		overflow: hidden;
	}

	html.is-nav-open body {
		position: fixed;
		top: 0;
		left: 0;
		width: 100%;
		overflow: hidden;
	}

	/*
	 * The sticky quote button, Tidio live chat, and Klaviyo's teaser popup are all
	 * independent third-party floating widgets (position:fixed, defensively high z-index -
	 * Tidio's in particular renders inside a shadow DOM host set inline, so out-competing it
	 * with a bigger z-index isn't reliable). A fullscreen menu takeover should hide
	 * distracting floating UI anyway - simplest fix is to hide all three outright while open.
	 */
	html.is-nav-open .ab-sticky-btn,
	html.is-nav-open #tidio-chat,
	html.is-nav-open [class*="kl-teaser-"] {
		display: none !important;
	}

	.ezdock-nav__item {
		border-bottom: 1px solid #e0e6ec;
	}

	.ezdock-nav__trigger {
		justify-content: space-between;
	}

	/*
	 * The link/label side of an accordion row (matches both the top-level .ezdock-nav__link
	 * and a nested row's bare <a>, via :not(.ezdock-nav__toggle) rather than needing to name
	 * every variant) grows to fill the entire row instead of just hugging its own text width,
	 * so the whole left portion of the row is part of its clickable/tappable area, not just
	 * the visible label. The toggle button is sized up to a proper square touch target (was
	 * 24px, tuned tight specifically for desktop's mouse-driven caret - too small to
	 * comfortably tap here) and gets its own border to visually separate it from the link
	 * beside it, now that the two are sharing one full-width row.
	 */
	.ezdock-nav__trigger > *:not(.ezdock-nav__toggle) {
		flex: 1 1 auto;
	}

	.ezdock-nav__toggle {
		width: 48px;
		height: 48px;
		flex-shrink: 0;
		border-left: 1px solid #e0e6ec;
	}

	.ezdock-nav__dropdown,
	.ezdock-nav__mega {
		position: static;
		width: 100%;
	}

	/*
	 * Explicit here (rather than inherited from an unconditional base rule) so the desktop-
	 * only padding/gap/rounding fix for the full-width mega panel (see the desktop query
	 * below) can't leak into this edge-to-edge mobile flyout layout, where rounded corners
	 * and doubled-up horizontal padding would look wrong.
	 */
	.ezdock-nav__mega {
		padding: 20px 0;
	}

	.ezdock-nav__mega-columns {
		flex-direction: column;
		gap: 0;
		padding: 0 20px;
	}

	/*
	 * The base rule's `flex: 1 1 160px` sets each column's flex-basis assuming the desktop
	 * row-direction layout above, where that reasonably means "start at 160px wide". Flipping
	 * to flex-direction:column here (just above) flips the main axis too, so that same 160px
	 * becomes a MINIMUM HEIGHT instead - harmless before this column became collapsible (real
	 * content was always taller than 160px anyway), but now forces every collapsed column to
	 * stay ~160px tall regardless of its actual (much shorter, title-only) content. Reset to
	 * auto so each column's height is driven by its real content instead.
	 */
	.ezdock-nav__mega-column {
		flex: 0 1 auto;
		min-width: 0;
	}

	.ezdock-nav__mega-promo {
		/*
		 * width:auto (overriding the base rule's fixed 237px desktop width) - a normal block
		 * box with side margins and auto width automatically sizes to fill what's left,
		 * matching .ezdock-nav__mega-columns' own 20px side padding instead of either the
		 * desktop-fixed 237px or running edge-to-edge like the previous `width:100%` did.
		 */
		width: auto;
		margin: 0 20px;
		height: 160px;
	}

	/*
	 * Client feedback: mega menu columns (Products has 5, each with several links) taking up
	 * too much vertical space on mobile all expanded at once. Each column becomes its own
	 * mobile accordion section - same row treatment as the top-level trigger rows above (title
	 * fills the row, toggle is a square touch target), just on a dark background instead of
	 * white/bordered, and columns separate with a subtle light-on-dark rule instead of
	 * .ezdock-nav__item's #e0e6ec (designed for the light dropdown panels, invisible here).
	 */
	.ezdock-nav__mega-column {
		padding: 6px 0;
		border-bottom: 1px solid rgba(255, 255, 255, 0.15);
	}

	.ezdock-nav__mega-column:last-child {
		border-bottom: none;
	}

	.ezdock-nav__mega-column-trigger {
		display: flex;
		align-items: center;
		justify-content: space-between;
	}

	.ezdock-nav__mega-column-trigger > .ezdock-nav__mega-column-title {
		flex: 1 1 auto;
		margin-bottom: 0;
	}

	.ezdock-nav__mega-column-toggle {
		width: 48px;
		height: 48px;
		flex-shrink: 0;
		/* Overrides the base .ezdock-nav__toggle rule's #e0e6ec border-left, designed for the
		   light dropdown panels - visible as a stray pale line against this dark background. */
		border-left: none;
	}

	.ezdock-nav__mega-column-toggle .ezdock-nav__caret {
		border-color: #fff;
	}
}