/**
 * Header layout.
 *
 * Small screens: a plain flex row — logo left, hamburger right (the flex layout
 * the Group block already emits, so nothing to do here).
 *
 * Desktop: a 1fr / auto / 1fr grid. This is what makes the menu sit at TRUE page
 * centre. Flex centring would centre it in the space left OVER beside the logo,
 * pushing it off-centre by half the logo's width; the empty third grid track
 * mirrors the first, cancelling that out.
 */

@media ( min-width: 782px ) {
	.wp-block-group.pd-header-bar {
		display: grid;
		grid-template-columns: 1fr auto 1fr;
		align-items: center;
	}

	/* Logo takes the first track, hard left. */
	.wp-block-group.pd-header-bar > :first-child {
		grid-column: 1;
		justify-self: start;
		margin: 0;
	}

	/* Menu takes the centre track. */
	.wp-block-group.pd-header-bar > .pd-header-nav {
		grid-column: 2;
		justify-self: center;
	}
}

/**
 * Submenu parents ("Equipment") are rendered by core as an <a> with NO href,
 * because the parent is a toggle rather than a destination. An anchor without
 * href gets `cursor: auto`, which shows the text I-beam over the label. Restore
 * the pointer on the label and on the chevron button beside it.
 *
 * Not scoped to .pd-header-nav so the footer navigation gets the same fix.
 */
.wp-block-navigation-item__content:not( [href] ),
.wp-block-navigation-submenu__toggle,
.wp-block-navigation__submenu-icon {
	cursor: pointer;
}

/**
 * MOBILE OVERLAY MENU
 *
 * BREAKPOINT: 599px, not the theme's 782px.
 *
 * "overlayMenu": "mobile" is core's wording, and core's mobile ends at 600px —
 * that is where it stops rendering the hamburger and shows the full menu inline.
 * The theme's own desktop layout does not start until 782px, so between 600 and
 * 781 the header shows every link wrapped under the logo, 208px tall. Rules that
 * assume a hamburger have to stop at 599px or they describe a button that is not
 * on screen; the sticky rule especially, which would otherwise pin a 208px bar to
 * the top of a tablet.
 *
 * (That 600-781 header is worth its own pass — it predates this file.)
 *
 * Applies where the navigation block renders its overlay. Core gives you a working dialog and almost no
 * layout: the close button sits hard in the corner, and the menu inherits the
 * block's 3.25rem blockGap — a value chosen so eight items breathe across a
 * 1200px desktop bar, and wrong stacked in a phone-width column, where it reads
 * as eight unrelated words floating in white space.
 *
 * The three-bar hamburger is NOT here: the block now sets `"icon": "menu"` in
 * parts/header.html, which is core's three-bar icon (the default, "handle", is
 * two bars). A block attribute rather than CSS on purpose — restyling the SVG
 * would leave the editor preview showing the old one.
 *
 * SPECIFICITY — READ BEFORE EDITING.
 *
 * Core's overlay rules are unusually deep. Two examples, both of which quietly
 * beat anything shorter:
 *
 *   .wp-block-navigation__responsive-container.is-menu-open:where(…)
 *     .wp-block-navigation__responsive-container-content
 *     .wp-block-navigation__container                          → (0,4,0)
 *
 *   …same, plus .has-child .wp-block-navigation__submenu-container → (0,5,0)
 *
 * So every rule below goes through .wp-block-navigation__responsive-container-content
 * and, for the submenu, .pd-header-nav as well. That is not defensive padding —
 * a shorter selector here silently does nothing, which is how the first version
 * of this file left the 3.25rem gap in place while appearing to work.
 *
 * .pd-header-nav also scopes these rules to the header, leaving the footer
 * navigation alone.
 */
@media ( max-width: 599px ) {

	/**
	 * Mirrors parts/header.html. Declared on :root so the sticky rule and the
	 * close-button rule below both read the same numbers — they have to agree,
	 * since one positions the bar and the other positions a button inside it.
	 */
	:root {
		--pd-nav-button: 44px;
		--pd-header-pad-y: 6px;
		--pd-header-logo-h: calc( 70px * 419 / 384 );

		/* Padding top and bottom, the logo, and the 1px bottom border. */
		--pd-header-h: calc( ( var( --pd-header-pad-y ) * 2 ) + var( --pd-header-logo-h ) + 1px );
	}

	/**
	 * STICKY HEADER.
	 *
	 * Mobile only. On a phone the menu is behind a button, so a visitor deep in
	 * the California equipment page — six screens of rig cards — had to scroll all
	 * the way back up to reach any other page. On a desktop the full menu is
	 * always on screen anyway, and a sticky bar there would just spend 90px of a
	 * laptop viewport on navigation nobody is looking for.
	 *
	 * z-index 100 is deliberately far below the 100000 core gives the open
	 * overlay, so the menu still covers its own header when it opens.
	 *
	 * A useful side effect: the close button is aligned to where the hamburger
	 * sits at the top of the page (see the note below). With the bar stuck there,
	 * that is now where the hamburger ALWAYS is, so the swap holds at any scroll
	 * position rather than only at the top.
	 *
	 * THE RULE IS ON THE TEMPLATE PART, NOT ON .pd-header. A sticky element can
	 * only travel within its containing block, and .pd-header's parent — the
	 * <header> the template part renders — is exactly as tall as .pd-header
	 * itself. Stuck to a box with no room in it, the bar scrolled away like any
	 * static element (measured: top = -1500 after scrolling 1500). Its parent,
	 * <header class="wp-block-template-part">, is a direct child of
	 * .wp-site-blocks and therefore has the whole page to travel through.
	 *
	 * Tag-qualified because the footer is the same class with a <footer> tag.
	 */
	header.wp-block-template-part {
		position: sticky;
		top: 0;
		z-index: 100;
	}

	/**
	 * Anchors and skip links land under a sticky bar unless the scroll position
	 * is padded by its height. Costs nothing when nothing on the page uses one.
	 */
	html {
		scroll-padding-top: var( --pd-header-h );
	}

	/**
	 * 44px is the minimum comfortable touch target; the icons stay 24px inside
	 * it. The close button is positioned absolutely by core, so its clearance
	 * comes from inset rather than margin — margin on an absolutely positioned
	 * element offsets it from where top/right already put it, leaving two values
	 * to keep in sync.
	 */
	.wp-block-navigation__responsive-container-open,
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close {
		display: grid;
		place-items: center;
		width: var( --pd-nav-button );
		height: var( --pd-nav-button );
		padding: 0;
	}

	/**
	 * THE X HAS TO LAND WHERE THE HAMBURGER WAS.
	 *
	 * The open button sits in the header bar's flex row; the close button is
	 * positioned absolutely inside a fixed, full-viewport overlay. Nothing ties
	 * the two together, and measured against each other they were 16px apart
	 * horizontally and 2.8px vertically — enough that the icon visibly jumps as
	 * the overlay opens, which reads as a broken transition rather than a swap.
	 *
	 * Both values below reconstruct where the flex row puts the open button:
	 *
	 *   right — the same root padding the full-width header group uses, so the
	 *           two buttons share one edge whatever the viewport does to it.
	 *   top   — the header group's own 6px padding, plus half the difference
	 *           between the bar's height and the button, i.e. the centring the
	 *           flex row does. The bar's height IS the logo's rendered height:
	 *           70px wide in parts/header.html, at logo.png's 384x419 aspect.
	 *
	 * If the logo width in that pattern changes, --pd-header-logo-h has to change
	 * with it. That coupling is the price of aligning an absolutely positioned
	 * element to a flexed one; the alternative — a fixed header height — would
	 * pin the logo instead, which is worse.
	 */
	/**
	 * ANCHOR THE BUTTON TO THE VIEWPORT, NOT THE DIALOG.
	 *
	 * Core makes .wp-block-navigation__responsive-dialog `position: relative`, so
	 * it — not the fixed overlay — is what an absolutely positioned close button
	 * resolves against. The dialog sits inside the overlay's padding, so every
	 * inset written here came out shifted by that padding (measured: 36px from
	 * the right instead of the 16px asked for). Making the dialog static at
	 * mobile hands the anchoring back to the overlay, which IS the viewport.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-dialog {
		position: static;
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close {
		top: calc( var( --pd-header-pad-y ) + ( var( --pd-header-logo-h ) - var( --pd-nav-button ) ) / 2 );
		right: var( --wp--style--root--padding-right );
	}

	/**
	 * Side inset for the whole overlay.
	 *
	 * Core sets this from the root padding custom properties, which this theme
	 * leaves at 0 — so the menu rows sat flush against the screen edge with the
	 * text touching it. The doubled class is what carries the rule past core's
	 * own (0,3,0) declaration; core's block styles are enqueued after the
	 * theme's, so a tie would go to core.
	 */
	.wp-block-navigation__responsive-container.is-menu-open.is-menu-open:not( .disable-default-overlay ) {
		padding-inline: 1.25rem;
	}

	/* Clears the close button. (0,5,0) — core sets this at (0,4,0). */
	.wp-block-navigation__responsive-container.is-menu-open:not( .disable-default-overlay ) .wp-block-navigation__responsive-container-content.wp-block-navigation__responsive-container-content {
		padding-top: 4rem;
	}

	/**
	 * Full-bleed rows.
	 *
	 * The block's layout sets justifyContent: center, which core turns into
	 * `align-items: center` on the overlay's flex column — that is what stops the
	 * links from filling the width, so a tap only registers on the words
	 * themselves rather than anywhere on the row. Stretch, then left-align.
	 *
	 * gap: 0 here is the one that matters: it is the 3.25rem desktop blockGap,
	 * inherited all the way down, that made the menu look like a word list.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav {
		align-items: stretch;
		gap: 0;
		width: 100%;
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav > .wp-block-navigation-item {
		align-items: stretch;
		width: 100%;
		border-bottom: 1px solid rgba( 0, 0, 0, 0.08 );
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav > .wp-block-navigation-item:last-child {
		border-bottom: 0;
	}

	/**
	 * Size and padding go on the anchor, not the item: the block writes a fluid
	 * font-size clamp inline onto every <li>, and an inline style cannot be
	 * overridden from a stylesheet. The anchor is the first element in the chain
	 * CSS can still reach — and core zeroes its padding at (0,4,0), hence the
	 * depth here.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav .wp-block-navigation-item__content {
		display: block;
		width: 100%;
		padding: 0.95rem 0.25rem;

		font-size: 1.125rem;
		font-weight: 600;
		line-height: 1.3;
	}

	/**
	 * "Equipment" and its two children.
	 *
	 * In the overlay core expands the submenu inline rather than as a flyout, and
	 * hides the chevron. Left as core has it, the children get 2rem of side
	 * padding and a full blockGap of padding-top — 52px of white space between a
	 * parent and the two items belonging to it. Indented modestly and stepped
	 * down in weight instead, so the pair reads as subordinate rather than as two
	 * more top-level destinations.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav .has-child .wp-block-navigation__submenu-container {
		gap: 0;
		padding: 0 0 0.35rem 1rem;
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav .has-child .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
		padding-block: 0.55rem;
		font-size: 1rem;
		font-weight: 400;
		opacity: 0.75;
	}
}

/**
 * MOTION
 *
 * Core opens the overlay with a 0.1s fade from 0.5em down. At that duration the
 * panel is essentially already there — the eye registers a flicker rather than a
 * movement, which is most of why the menu felt clunky.
 *
 * The movement is split in two on purpose. The OVERLAY only fades; the CONTENT
 * rises. That is what lets the close button land exactly on top of the hamburger
 * it replaced — if the whole panel slid, so would the icon, and the swap that the
 * alignment above exists to create would be undone by the animation. So the panel
 * appears, the icon stays put, and the list drops into place under it.
 *
 * All of it sits behind `prefers-reduced-motion: no-preference`, matching how the
 * rest of the theme gates motion (see reveal.css and services.css).
 */
@media ( prefers-reduced-motion: no-preference ) {
	.wp-block-navigation__responsive-container.is-menu-open {
		animation: pd-menu-fade 0.18s ease-out;
		animation-fill-mode: forwards;
	}

	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
		animation: pd-menu-rise 0.28s cubic-bezier( 0.2, 0.7, 0.3, 1 );
		animation-fill-mode: both;
	}

	@keyframes pd-menu-fade {
		from { opacity: 0; }
		to { opacity: 1; }
	}

	@keyframes pd-menu-rise {
		from {
			opacity: 0;
			transform: translateY( 0.75rem );
		}

		to {
			opacity: 1;
			transform: none;
		}
	}

	.wp-block-navigation__responsive-container-open svg,
	.wp-block-navigation__responsive-container-close svg,
	.wp-block-navigation-item__content {
		transition:
			background-color 0.18s ease,
			color 0.18s ease,
			opacity 0.18s ease;
	}
}

@media ( max-width: 599px ) {
	/**
	 * Press feedback on a menu row — the theme's cream at the full width of the
	 * row, so the thing that lights up is the thing you tapped. This is what the
	 * suppressed tap highlight is replaced with, not simply removed.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav .wp-block-navigation-item__content:active {
		background-color: var( --wp--preset--color--cream );
	}

	.wp-block-navigation__responsive-container-open:active,
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-close:active {
		border-radius: 6px;
		background-color: var( --wp--preset--color--cream );
	}
}

/**
 * Desktop submenu labels stay on one line.
 *
 * Core sizes the flyout to a 200px minimum and lets it grow to its content, but
 * the content is allowed to wrap — so "Salt Lake City Based" broke across two
 * lines in a panel that had room to be wider. Stopping the wrap lets the panel
 * do what core already intended and size itself to the longest label.
 *
 * Set on the link rather than the panel: core styles the panel's width in three
 * separate state rules (hover, focus-within, aria-expanded), and this needs to
 * hold in all of them.
 */
.pd-header-nav .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
	white-space: nowrap;
}

/**
 * THE PAGE YOU ARE ON.
 *
 * inc/nav-current.php adds .pd-nav-current to the link matching the request —
 * core cannot, because these are custom-URL links rather than post references.
 * See that file for what counts as current.
 *
 * Two signals, not one: colour AND a rule under the label. Colour alone fails
 * for anyone who cannot separate this blue from this near-black, and the gold
 * rule is the same mark this theme puts under every section title, so "you are
 * here" is stated in a language the rest of the site already speaks.
 *
 * text-decoration rather than a border or a pseudo-element: it needs no layout
 * space, so nothing shifts when the current page changes.
 */
.pd-header-nav .wp-block-navigation-item__content.pd-nav-current {
	color: var( --wp--preset--color--primary );

	text-decoration: underline;
	text-decoration-color: var( --wp--preset--color--gold );
	text-decoration-thickness: 2px;
	text-underline-offset: 6px;
}

@media ( max-width: 599px ) {
	/**
	 * In the overlay the rows are full width, so the rule would run the width of
	 * the screen. A gold bar down the left edge of the row is the same idea in
	 * the shape this layout wants; the row's padding makes space for it without
	 * the text moving.
	 */
	.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .pd-header-nav .wp-block-navigation-item__content.pd-nav-current {
		color: var( --wp--preset--color--primary );
		text-decoration: none;
		box-shadow: inset 3px 0 0 var( --wp--preset--color--gold );
		padding-left: 0.85rem;
	}
}