/* His hamburger menu, on every page of the site.
 *
 * What the theme opens is a full-screen white sheet with the six links pushed into its top
 * right corner and the rest of it empty. This turns it into what a menu on a phone normally
 * is: a panel sliding in over a dimmed page, in the site's own teal.
 *
 * This one file is the only thing the plugin loads outside the home page, and that is a
 * decision rather than an accident. The menu is one template part shared by every page, so a
 * drawer on the home page and a white sheet everywhere else would read as a fault rather than
 * as a design. It was given rather than quoted: it is minutes of work on top of what the home
 * page already needed, and it is the same header on all of them.
 *
 * Everything here works with HIS markup and HIS script. The panel opens, closes and holds
 * focus exactly as before; `is-menu-open` is the class his own script sets, so none of these
 * rules has to know when the menu opens. Removing the plugin removes the drawer and gives the
 * sheet back, with nothing left behind in his theme.
 *
 * No media query on purpose: these apply whenever his panel is open, which is his theme's
 * decision and his breakpoint to move. Measured on his live page at 390 px: the drawer is
 * 263 px of a 375 px window, the longest item fits on one line, and every link is a 52 px tap
 * target. The colour is the site's `--brand-deep`, declared here rather than imported because
 * the home page's stylesheet is not loaded on the other pages.
 */

.wp-block-navigation__responsive-container.is-menu-open {
	/* The dim IS this element: it covers the viewport, and the drawer is positioned inside
	   it. Both declarations need !important — the white comes from a WordPress rule of the
	   same specificity that is printed after ours, and the padding from the block's own
	   inline layout. Measured: without them the sheet stays white and 25 px padded. */
	padding: 0 !important;
	background-color: rgba(3, 24, 24, .55) !important;
	animation: nsvh-menu-dim .2s ease-out;
	/* This pair is what makes the drawer open the same way twice, and it took a trace to
	   find. The drawer begins the animation translated one width to the right, i.e. outside
	   this box; his script then moves focus to the first link inside it; and the browser,
	   doing what it must for a focused element that is out of view, scrolls THIS element
	   sideways to reveal it. Measured on his live page: `scrollLeft` jumping to 160-186 px
	   and unwinding to 0 as the animation finished. Depending on where in the 240 ms the
	   focus landed, the drawer appeared to drift in from the left, or to be there already,
	   or to slide cleanly — three behaviours, one cause.

	   `overflow: hidden` does NOT fix it: it stops the user scrolling, not the browser.
	   `overflow: clip` removes the scroll container itself, and measured over repeated
	   opens it holds `scrollLeft` at 0. The `hidden` before it is what engines older than
	   Safari 16 fall back to, and for those menu-drawer.js keeps the offset at 0 as well. */
	overflow: hidden;
	overflow: clip;
}

.is-menu-open .wp-block-navigation__responsive-close {
	position: absolute;
	top: 0;
	right: 0;
	bottom: 0;
	width: min(70vw, 290px);
	padding: 22px 24px;
	background: #003f40;
	box-shadow: -18px 0 44px rgba(3, 24, 24, .38);
	/* A phone in landscape has room for four items, not six. */
	overflow-y: auto;
	animation: nsvh-menu-slide .24s ease-out;
}

.is-menu-open .wp-block-navigation__responsive-dialog,
.is-menu-open .wp-block-navigation__responsive-container-content {
	height: 100%;
}

/* The links start under the close button rather than beside it, so the first one cannot
   collide with a 44 px tap target in the same corner. */
.is-menu-open .wp-block-navigation__responsive-container-content {
	align-items: flex-start;
	justify-content: flex-start;
	padding-top: 62px;
}

.is-menu-open .wp-block-navigation__container {
	align-items: flex-start;
	gap: 0;
	width: 100%;
}

/* `align-items` is the one that decides this, not `text-align`: his list item is a flex
   COLUMN, so its cross axis is horizontal and his `flex-end` was holding every link against
   the right edge of the drawer. Read off the page — the link box sat at x=308 in a panel
   starting at 113 — after text-align alone had changed nothing. */
.is-menu-open .wp-block-navigation-item {
	width: 100%;
	align-items: flex-start;
	border-top: 1px solid rgba(255, 255, 255, .14);
	text-align: left;
}

.is-menu-open .wp-block-navigation-item:last-child {
	border-bottom: 1px solid rgba(255, 255, 255, .14);
}

/* Full width so the tap target is the row and not the word: 225 x 52 px, measured.
   The padding needs !important and only on his other pages, which is why it is here rather
   than a habit: without it the rows measured 26 px tall on `/about-us/`, half of what a
   thumb needs, while the identical rule was already winning on the home page. Something in
   his stack zeroes it with a priority the home page's own stylesheet happens to outrank. */
.is-menu-open .wp-block-navigation-item a {
	display: block;
	width: 100%;
	padding: 13px 0 !important;
	font-size: 17px;
	text-align: left;
}

/* The page the visitor is on keeps the theme's own highlight; everything else goes white on
   the teal, which is 11.6:1. His highlight is left alone rather than restyled. */
.is-menu-open .wp-block-navigation-item:not(.current-menu-item) a {
	color: #fff;
}

.is-menu-open .wp-block-navigation__responsive-container-close {
	top: 6px;
	right: 4px;
	width: 44px;
	height: 44px;
	color: #fff;
}

@keyframes nsvh-menu-dim {
	from {
		background-color: rgba(3, 24, 24, 0);
	}
}

@keyframes nsvh-menu-slide {
	from {
		transform: translateX(100%);
	}
}

@media (prefers-reduced-motion: reduce) {
	.wp-block-navigation__responsive-container.is-menu-open,
	.is-menu-open .wp-block-navigation__responsive-close {
		animation: none;
	}
}