/**
 * Keep the header on one line between the theme's mobile breakpoint and the width its
 * desktop layout was designed for.
 *
 * THE MEASURED DEFECT
 *
 * Nikki, reviewing staging on 2026-09-02: "Frist visit box looks in weird place on home
 * page". The theme's header row is a flex container that wraps, holding three children:
 * the logo, the navigation, and the "Your First Visit" call to action. When the three no
 * longer fit on one line the call to action wraps onto a second line and lands at the far
 * left, directly under the logo and overlapping the announcement bar - which is exactly
 * where she saw it.
 *
 * Measured with a viewport sweep on 2026-09-03, `wrapped` meaning the button sat below the
 * header row:
 *
 *          992  1024  1100  1152  1200  1280  1300  1366  1400
 *   prod    x     x     x     x     x     .     .     .     .
 *   ours    x     x     x     x     x     x     x     .     .
 *
 * So this is the theme's own defect, present on the live site today from 992px to about
 * 1160px, which this project then widened to about 1330px: rebuilding the top-level menu
 * (`src/anr/navigation.py`) took it from 686px to 751px, and the header had no 65px to
 * spare. 1280 and 1300 are ordinary laptop widths, which is why it reached the client.
 *
 * Below 992px none of this applies: the theme switches to the hamburger menu and hides
 * `.header-btn-nav`, putting the same call to action inside the drawer as `.btn-mobile`.
 * That is why the band has a floor as well as a ceiling.
 *
 * WHY TIGHTEN RATHER THAN HIDE OR COLLAPSE
 *
 * Hiding the button in the band was the smaller change and is wrong here: "Your First
 * Visit" is not in the navigation at all (`MENU` in `src/anr/navigation.py`), so the header
 * button is the only route to that page on desktop. Hiding it would delete the page from
 * the site's navigation between 992px and 1300px.
 *
 * Raising the theme's hamburger breakpoint to 1200px would also have worked and would have
 * changed how the menu behaves at tablet and small-laptop widths, which is the client's
 * call rather than a bug fix. Tightening spacing changes no behaviour and no words.
 *
 * The savings are taken from all three children in proportion to how much slack each has,
 * and were tuned against the sweep rather than guessed: at 992px the header fits with a
 * few pixels to spare, and every width from 992px to 1600px now renders on one line with
 * the button on the right and no text clipped.
 *
 * `flex-wrap: nowrap` alone does not fix this - it converts the wrap into the navigation
 * spilling onto two rows instead, because a flex line only shrinks after it has been
 * allowed to wrap. It is here so that any future pressure shrinks the navigation rather
 * than throwing the button onto its own line again, and it needs `min-width: 0` on the
 * navigation to be able to shrink at all.
 */

@media screen and (min-width: 992px) and (max-width: 1399px) {
	#header-wrap .header-main .row {
		flex-wrap: nowrap;
	}

	#header-wrap .header-navigation {
		min-width: 0;
	}

	/* The button keeps its size; the navigation is the flexible one. */
	#header-wrap .header-btn-nav {
		flex-shrink: 0;
	}

	#header-wrap .header-btn-nav .h-btn-nav {
		white-space: nowrap;
	}

	#header-wrap .main-navigation ul.primary-menu > li > a {
		padding-left: 9px;
		padding-right: 9px;
	}
}

/*
 * The tight half of the band. 1300px and 1366px need only the menu padding above; below
 * 1300px the logo and the button have to give something too, or the menu is squeezed to
 * the point where the words touch.
 */
@media screen and (min-width: 992px) and (max-width: 1299px) {
	#header-wrap .header-branding img {
		max-width: 150px;
	}

	#header-wrap .main-navigation ul.primary-menu > li > a {
		padding-left: 4px;
		padding-right: 4px;
		font-size: 13px;
	}

	#header-wrap .header-btn-nav .h-btn-nav {
		padding-left: 18px;
		padding-right: 18px;
		font-size: 12px;
	}
}