/**
 * core/navigation — the header's Main menu.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/navigation', … ), which is core's own theme-side
 * counterpart of block.json's `style` key: one stylesheet, attached to one block, and
 * enqueued on render rather than globally wherever the site opts into on-demand block
 * assets. It is NOT appended to the theme's root style.css, which this theme serves as a
 * minified stub on any request where SCRIPT_DEBUG is off — a rule added there would be
 * written, committed and silently never served.
 *
 * WHY CSS AT ALL, given the build ladder forbids skipping rungs. The source puts
 * `padding: 8px 24px` on a.main-navigation-link. Nothing above rung 5 can carry that:
 *
 *   - core/navigation-link and core/navigation-submenu declare NO `spacing` support, so
 *     there is no block attribute that expresses padding on a menu item at all;
 *   - theme.json styles.blocks would have to target `.wp-block-navigation-link`, a class
 *     core never renders — the padding-bearing element is
 *     `.wp-block-navigation-item__content` (a <button> on a submenu item, an <a> on a
 *     plain link), which no theme.json selector reaches;
 *   - the navigation block's own `spacing.blockGap` is the gap BETWEEN items, and this
 *     unit's contract derives that as 0. Using it would put the right number on the wrong
 *     property and overwrite a value that was measured.
 *
 * SCOPED BY className, NOT BY [aria-label="Main"]. The nav's ariaLabel is written through
 * esc_html_e() in patterns/header.php, so on a translated install the attribute value is
 * not "Main" and an attribute selector stops matching with no error. `main-navigation` is
 * a customClassName on the same block — core/navigation declares no
 * `supports.customClassName: false`, so it defaults to true and lands on the rendered
 * wrapper.
 *
 * TOP-LEVEL ITEMS ONLY. The `>` combinators below stop at children of
 * ul.wp-block-navigation__container; core renders a dropdown's own list as
 * ul.wp-block-navigation__submenu-container, which carries core's measured-elsewhere
 * 9px/18px and which this unit's contract records no value for.
 *
 * @package WordPress
 * @subpackage Xperience_Starter
 * @since Xperience Starter 1.0
 */

/*
 * NO `border-bottom` RULE HERE, AND THIS NOTE IS WHY IT MUST NOT COME BACK. Removed
 * 2026-09-09 (unit loop fix pass) and moved onto the `header-bar` band as a `core/group`
 * block attribute — patterns/header.php's docblock carries the full reasoning and the
 * measurements.
 *
 * THE RULE WAS NEVER WRONG; THE ELEMENT WAS, AND THE ELEMENT WAS PICKED BY MATCHING CLASS
 * NAMES. The source paints `border-bottom: 1px solid rgb(51,51,51)` on `.header-main-nav`,
 * which is a FULL-WIDTH BAND ROW. `.main-navigation` here is a `core/navigation` block,
 * which is a shrink-wrapped flex box. The names read alike and the boxes are not the same
 * box — measured 2026-09-09 at 1440x900 with `node tooling/extract/probe.js
 * --props=border-bottom-width,border-bottom-style,border-bottom-color,width`:
 *
 *   source  div.header-main-nav                    width 1440px   1px solid rgb(51,51,51)
 *   build   .wp-block-navigation.main-navigation   width  366px   1px solid rgb(51,51,51)
 *
 * So the built line was a 366px stub under three menu items, not a hairline across the
 * header, and the fidelity comparison reported BOTH halves of that at all four viewports:
 * a `corroborated` row saying the band's border was missing, and an `arbitrary` row saying
 * the nav had one the source does not.
 *
 * THREE PASSES MOVED IT BETWEEN WRONG ELEMENTS on that name match — `ab5376a` onto the nav,
 * `2665d92` off entirely, `5a40203` back onto the nav — and each pass could cite a real
 * measurement, because the measurement that the SOURCE has a hairline was true every time.
 * What none of them did was check that the element receiving the rule was the element the
 * comparison had paired. A fourth pass restoring it here would be the same error again:
 * confirm a target from geometry and the paired path, never from a class name.
 */

.wp-block-navigation.main-navigation
	.wp-block-navigation__container
	> .wp-block-navigation-item
	> .wp-block-navigation-item__content {
	/* 8px and 24px are spacing presets 30 and 50 exactly — no literal is needed. */
	padding: var(--wp--preset--spacing--30) var(--wp--preset--spacing--50);
	/*
	 * 22.5px IS ARITHMETIC OVER THREE MEASURED VALUES, NOT A NEW NUMBER.
	 * units/header.yml `controls` records this control's box as 122 x 38.5 in BOTH its
	 * closed and its open state; the same contract's `structure` records 8px block padding
	 * and an 18px font on the same element. 38.5 − 8 − 8 = 22.5, and this element is
	 * `display: block`, so its height is exactly its padding plus one line box. Built at
	 * 43 before this line, because theme.json's global styles.typography.lineHeight is 1.5
	 * and 18 × 1.5 = 27.
	 *
	 * A LENGTH RATHER THAN THE RATIO 1.25, on the precedent the chevron rule below sets out
	 * in full and for the same reason: 22.5px is what was measured, and a ratio would move
	 * silently the day anyone touches this menu's type scale.
	 *
	 * NOT IN theme.json. The measurement is on ONE element — the top-level menu item's
	 * content — and theme.json's global lineHeight reaches every block on the site, while
	 * styles.blocks['core/navigation'] would also reach every submenu item inside this menu,
	 * whose line height nothing has measured. There is no block attribute that reaches
	 * `.wp-block-navigation-item__content` either: that is the same argument this file's
	 * header already makes for the padding it sits beside, and the two together are the one
	 * box the contract states.
	 */
	line-height: 22.5px;
}

/*
 * THE TRIGGER'S INLINE PADDING IS 24px ONLY FROM 1400px UP — BOOTSTRAP'S `xxl`.
 *
 * The rule above states 24px unconditionally, which is the xxl value applied at every
 * width. The source declares the property THREE TIMES, each in its own query. Read
 * 2026-09-10 from the source's own served stylesheet at /frontend/dist/styles/main.css,
 * the same channel units/header.yml `derivations` names for the caret:
 *
 *     .main-navigation-link                      { padding: .5rem }        (base)
 *     @media (min-width:992px)  .main-…-link     { padding: .5rem 1rem }   (lg)
 *     @media (min-width:1400px) .main-…-link     { padding: .5rem 1.5rem } (xxl)
 *
 * MEASURED ON BOTH ORIGINS 2026-09-10, 15:11–15:12 UTC, by sweeping viewport width. The
 * four captured viewports cannot see this boundary — 1440 is above it and 1024 below, so
 * both sides agree at both and the step between them is invisible to every run on disk:
 *
 *     width   SOURCE a.main-navigation-link   BUILD …-item__content
 *     1400    122x39   pad 24/24              122x39   pad 24/24
 *     1399    106x39   pad 16/16              122x39   pad 24/24
 *     1200    106x39   pad 16/16              122x39   pad 24/24
 *     1024    106x39   pad 16/16              122x39   pad 24/24
 *      992    106x39   pad 16/16              122x39   pad 24/24
 *
 * 106 IS THE SAME DERIVATION WITH ONE TERM CHANGED, not a second measurement.
 * units/header.yml `derivations` composes 122 as 24 + 52 + 8 + 14 + 24, and
 * 16 + 52 + 8 + 14 + 16 = 106. The caret's two terms and the label's 52 are unmoved: the
 * source's box stays 39 tall at 18px across the step, and only `padding` is redeclared.
 *
 * WHAT IT COST DOWNSTREAM. Three items x 16px is 48, so the built nav bar measured 366 at
 * 1024 where the source's is 318 — and that 48 is the whole of units/mega-menu-panel's
 * Area 3 accordion sitting +48px in x at 1024 while being exact at 1440.
 *
 * A BOUNDED BAND, NOT A RE-TIERING OF THE RULE ABOVE. Restating the source's three tiers
 * here would also change what this element computes BELOW 992px, where the build renders
 * these items inside core/navigation's overlay drawer rather than in the source's separate
 * offcanvas markup — a different element in a different context, whose 116x39 both origins
 * were measured agreeing on (units/header.yml `states`, drawer-open, 2026-09-07) and which
 * nothing in this change has re-driven. Bounding the override at both ends means it can
 * only reach the band that was measured wrong.
 *
 * 1399.98px IS THE `max-width` COUNTERPART OF `min-width: 1400px`, Bootstrap's own
 * convention and the source's own boundary: a plain 1399 would leave fractional widths
 * between 1399 and 1400 matching neither query and falling through to the 24px above.
 *
 * PRESET 40 IS 1rem EXACTLY (theme.json settings.spacing.spacingSizes, slug 40, "Small"),
 * which is the source's own `1rem` — so no literal is needed here either, the same
 * argument the rule above makes for presets 30 and 50.
 *
 * THE TWO INLINE LONGHANDS RATHER THAN THE `padding` SHORTHAND, so the 8px of block
 * padding preset 30 sets above is not restated in a second place that could drift from it.
 * Same specificity as the rule it overrides and later in the same file, so it wins on
 * order — no `!important`, and nothing here outranks core.
 */
@media (min-width: 992px) and (max-width: 1399.98px) {
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-item__content {
		padding-left: var(--wp--preset--spacing--40);
		padding-right: var(--wp--preset--spacing--40);
	}
}

/*
 * CORE'S OWN CHEVRON SPAN, SIZED — THE ONES THE SOURCE HAS NO COUNTERPART FOR.
 *
 * Core sets `width: 0.6em; height: 0.6em` on .wp-block-navigation__submenu-icon
 * (wp-includes/blocks/navigation/style.css:140-151), so at this menu's 18px it computes
 * 10.8x10.8 — a chevron two thirds the size of anything else in the bar.
 *
 * WHICH ELEMENTS THIS STILL REACHES. Not the top-level trigger: below, at >=992px, that
 * span is hidden and the caret is drawn as the toggle's own ::after at the source's 14x8.
 * What is left is the NESTED submenu toggle inside a dropdown (Area 1's "Link 2"), and
 * every toggle in the overlay drawer under 992px. The source has neither — its dropdown
 * sub-lists are always visible rather than disclosed, and its drawer draws the same ::after
 * the desktop bar does — so 16px here is a house value for a control the source does not
 * have, not a measurement of one it does. units/header.yml `derivations` records the
 * source's own caret as 14 wide by 8 tall and is the place that number lives.
 *
 * A LENGTH RATHER THAN A RATIO: 0.888em is the same number today and moves silently the day
 * anyone touches this menu's type scale.
 *
 * NOT SCOPED WITH `>`, so it reaches both remaining cases; specificity (0,3,0) against
 * core's (0,2,0) — one class, no !important.
 */
.wp-block-navigation.main-navigation .wp-block-navigation__submenu-icon {
	width: 16px;
	height: 16px;
}

/*
 * A DROPDOWN LINK IS 10px/20px, WHICH IS NOT CORE'S 0.5em/1em AND NOT A SPACING PRESET.
 *
 * The source states it once, for every link in every dropdown of this menu:
 *
 *     .main-navigation-dropdown .navigation-menu-item-link { padding: .625rem 1.25rem }
 *     .main-navigation-dropdown-link                       { padding: .625rem 1.25rem }
 *
 * Core's submenu rule is `padding: 0.5em 1em` (navigation/style.css:219-222 and :392-397),
 * so at the 16px these links now carry it renders 8px/16px. Neither 10px nor 20px is a step
 * on this theme's spacing ladder — 4, 8, 16, 24 — and neither is a value the block model can
 * express: core/navigation-link and core/navigation-submenu declare no `spacing` support at
 * all, so there is no attribute for a menu item's padding. Written in the source's own rem
 * form rather than as px, which is how the source authors it.
 *
 * NOT INSIDE A MEDIA QUERY, because the source's rule is not: `.main-navigation-dropdown`
 * carries these links in the offcanvas drawer too. The mega-menu panel's own list links are
 * not `.wp-block-navigation-item__content` and are unaffected — their padding is
 * blocks/mega-menu-panel/style.css.
 */
.wp-block-navigation.main-navigation
	.wp-block-navigation__submenu-container
	> .wp-block-navigation-item
	> .wp-block-navigation-item__content {
	padding: 0.625rem 1.25rem;
}


/*
 * THE SUBMENU OUTLINE CORE ADDS AND THE SOURCE DOES NOT HAVE.
 *
 * Core paints `background-color:#fff; border:1px solid rgba(0,0,0,.15)` on every dropdown
 * container, from `.wp-block-navigation:not(.has-background)
 * .wp-block-navigation__submenu-container` (wp-includes/blocks/navigation/style.min.css).
 * Measured on this build's Area 1 dropdown and its nested one at 1440 and 390: 1px solid
 * rgba(0, 0, 0, 0.15) on all four sides. The source's dropdowns have no such outline. This
 * is the opposite of a missing style — the build is ADDING something — so the fix belongs on
 * core/navigation, the block that owns the rule, and not on whatever happens to sit inside
 * a dropdown.
 *
 * ONLY `border`. The white ground from the same core declaration is left alone: it is what
 * the source's own collapse paints, and the mega panel's stylesheet restates it for its own
 * reasons. The `left:-1px` core sets to overlap this border is ALSO left alone and is
 * reported instead of guessed — it is a separate positional value, and no capture of this
 * build records where the source puts a plain dropdown's left edge.
 *
 * SPECIFICITY IS THE WHOLE DESIGN OF THIS SELECTOR, chosen so it cannot fight the mega
 * menu panel. Three parties address the same element:
 *
 *   core                    (0,3,0)   border: 1px solid rgba(0,0,0,.15)
 *   this rule               (0,3,1)   border: 0
 *   blocks/mega-menu-panel  (0,4,0)   border: 0; border-top: 3px solid …bright-blue
 *
 * The `ul` type selector adds to the ELEMENT column, which is weaker than the class column,
 * so this rule outranks core's and is outranked by the panel's — deterministically, on
 * weight, with no !important and no dependence on which stylesheet the enqueue order happens
 * to print first. That 3px rgb(28,58,169) top rule is measured as matching the source
 * exactly, so a rule that could clobber it would be a regression, and a rule that named the
 * panel's class here would make the navigation stylesheet depend on a block it knows nothing
 * about.
 *
 * Every dropdown container is a child of a `.wp-block-navigation-item` — core's own
 * `.wp-block-navigation .wp-block-navigation-item .wp-block-navigation__submenu-container`
 * rules rely on the same nesting — so the middle class costs a selector segment and excludes
 * nothing.
 */
.wp-block-navigation
	.wp-block-navigation-item
	ul.wp-block-navigation__submenu-container {
	border: 0;
}

/*
 * THE DROPDOWN CHROME, AND IT BELONGS TO THE CONTAINER RATHER THAN TO WHATEVER SITS IN IT.
 *
 * WHY IT MOVED HERE FROM blocks/mega-menu-panel/style.css. That file scoped every one of
 * these declarations with `:has( > .wp-block-wakefly-mega-menu-panel )` on the stated
 * reasoning that Area 1's plain link submenu "is not this unit". The premise is disproved by
 * measurement: the source's three dropdowns are chrome-identical — same container element,
 * ground, rule, shadow, padding, radius, position, z-index and offset — and it is
 * div.main-navigation-item-collapse, the CONTAINER, that paints them, whatever the widget
 * inside happens to be. units/mega-menu-panel.yml's own `behaviour` says so in as many
 * words: "the white ground, the blue rule and the shadow belong to the container, never to
 * the panel". Area 1 measured 200x93, z-index 2, `0px none`, no shadow, against a source
 * 300x143 with all four; Area 2 measured identical to the source on every one of them.
 * So the rule is the same rule and it is written once, on core/navigation, which owns the
 * element — not twice, once per block that might be found inside it.
 *
 * SPECIFICITY, DELIBERATELY, AND IT HAS TO CLEAR FOUR CORE RULES:
 *
 *   .wp-block-navigation .has-child .wp-block-navigation__submenu-container       (0,3,0)
 *       position:absolute; z-index:2; background-color:inherit — and left:-1px; top:100%
 *   .wp-block-navigation:not(.has-background) .wp-block-navigation__submenu-container
 *                                                                                 (0,3,0)
 *       background-color:#fff; border:1px solid rgba(0,0,0,.15)
 *   .wp-block-navigation .has-child
 *     .wp-block-navigation-submenu__toggle[aria-expanded=true] ~ …container        (0,5,0)
 *       min-width:200px (plus the width/height/visibility that open the thing)
 *   the `border: 0` rule above                                                     (0,3,1)
 *
 * The selector below is (0,5,1) — five classes and the `ul` type — which beats every one of
 * them on weight, with no !important and no dependence on stylesheet order. It stops at
 * children of ul.wp-block-navigation__container, so it reaches the three TOP-LEVEL dropdowns
 * and never Area 1's third level, which the source renders inside this box rather than as a
 * second one (see the `position: static` rule below).
 *
 * WHAT EACH DECLARATION IS FOR:
 *   left / z-index    core sets -1px to overlap its own 1px border, which is gone, and
 *                     z-index 2; the source measures 0 and 1000 ($zindex-dropdown).
 *   border-top        3px rgb(28,58,169) is the theme's own `bright-blue` slug exactly,
 *                     read through its preset custom property rather than restated as hex.
 *   box-shadow        core has none.
 *   background-color  core computes #fff here only because the header group is white and
 *                     its has-background branch inherits; stated so the dropdown does not
 *                     change colour if the bar ever does.
 *   min/max-width     the source's collapse is shrink-to-fit between 300px and 600px
 *                     (units/mega-menu-panel.yml `behaviour`), which is the whole mechanism
 *                     behind three dropdowns of three different widths: Area 1 has less
 *                     content than 300 and lands on the floor, Area 2 carries a 500px image
 *                     and sizes to it, Area 3 starts at the floor and GROWS to 542 when an
 *                     accordion opens. Pinning any of them to a number would break the third
 *                     one. This is what replaces core's own min-width:200px.
 *   padding/margin    measured 0 on the container; the 24px lives on each child wrapper.
 *
 * ≥992px ONLY, AND THAT IS THE SOURCE'S OWN BOUNDARY, not a defensive guard. The source
 * paints this chrome inside @include media-breakpoint-up(lg)
 * (_main-navigation.scss:50-60); below it there is no desktop dropdown at all, only the
 * offcanvas drawer, in which core renders every submenu static, borderless and transparent.
 * A chrome rule that outranked core's overlay rules would put an absolutely-positioned,
 * shadowed, z-index-1000 box inside the drawer — which is precisely what the shadow and the
 * z-index were doing there before this query existed.
 */
@media (min-width: 992px) {
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> ul.wp-block-navigation__submenu-container {
		left: 0;
		z-index: 1000;
		min-width: 300px;
		max-width: 600px;
		margin: 0;
		padding: 0;
		border: 0;
		border-top: 3px solid var(--wp--preset--color--bright-blue);
		border-radius: 0;
		background-color: var(--wp--preset--color--white);
		box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1);
	}

	/*
	 * "left 0 — right 0 instead on the LAST navigation item, so the last panel does not
	 * overflow the page." Measured on the source. Written against the last item of this menu
	 * rather than against a named area, because which area is last is the menu's business.
	 * (0,6,1), so it overrides the `left` above rather than racing it.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item:last-child
		> ul.wp-block-navigation__submenu-container {
		right: 0;
		left: auto;
	}

	/*
	 * AREA 1'S THIRD LEVEL RENDERS INSIDE THE SAME BOX, NOT AS A FLYOUT BESIDE IT.
	 *
	 * Core puts a nested submenu at `left:100%; top:-1px` from 782px up, so "Tertiary Link"
	 * measured x=487 — outside a dropdown whose own box starts at x=287 and ends at 487. The
	 * source renders it in the same 300px box, which is the whole of why Area 1 measures 143
	 * there and 93 here: three stacked rows against two.
	 *
	 * `position: static` ALONE IS NOT ENOUGH, and the reason is worth writing down because it
	 * is invisible until measured. Core makes every navigation item a flex ROW
	 * (`.wp-block-navigation .wp-block-navigation-item { display: flex; align-items: center }`,
	 * navigation/style.css:109-114), so a de-absoluted submenu becomes a second flex item
	 * BESIDE its own toggle button rather than a block beneath it — measured at x=588 on a
	 * container running 288-588, which is the same wrong place the flyout was in, reached a
	 * different way.
	 *
	 * SO THIS IS CORE'S OWN `open-always` SHAPE, NOT AN INVENTION. Where core itself renders
	 * a submenu in flow (navigation/style.css:275-281 and :330-341) it does exactly three
	 * things: `flex-wrap: wrap` on the parent item, then `position: static` and
	 * `flex-basis: 100%` on the container. Wrapping is what puts the container on its own
	 * line; the basis is what makes that line full width. Both are copied here rather than
	 * approximated, and neither touches the open/closed mechanics: shut, the container is
	 * still `visibility:hidden; height:0; overflow:hidden` and paints nothing.
	 *
	 * (0,4,0) on each — one more class than core's `position:absolute` at (0,3,0) and than
	 * its `display:flex` on the item at (0,2,0).
	 *
	 * AND IT IS NOT A DISCLOSURE IN THE SOURCE AT ALL, WHICH IS THE OTHER HALF OF THE SAME
	 * BOX. `ul.main-navigation-dropdown-subitems` is permanently visible and indented
	 * `padding: 0 0 0 32px`; the source's own "Link 2" is a plain
	 * `a.main-navigation-dropdown-link` with that list as its SIBLING inside one
	 * `li.main-navigation-dropdown-item`, and nothing in the box is a toggle. Measured on
	 * the live source at 1440x900 with the Area 1 collapse driven open: rows at y 114, 158
	 * and 202 stepping 44, the sub-list 300x44 at x=288 and "Tertiary Link" 268x44 at x=320.
	 * The 32px is not a rule of the project's — grep the served main.css and the class has
	 * zero declarations; it is Bootstrap reboot's own `ul { padding-left: 2rem }`.
	 *
	 * CORE HAS NO PER-ITEM CONTROL THAT WOULD EXPRESS THAT. `submenuVisibility` takes
	 * `hover | click | always` but it is an attribute of core/navigation and reaches every
	 * level through context (navigation/block.json `providesContext`), so `always` would
	 * also un-click the three top-level Areas, whose click behaviour is measured and
	 * required. `showSubmenuIcon` cannot help either: in the click branch
	 * navigation-submenu.php renders the icon span `if ( $has_submenu )` and never consults
	 * it, so every level is a `<button>` whatever it is set to.
	 *
	 * SO THE RULE BELOW IS CORE'S OWN OVERLAY TREATMENT, MOVED TO THIS BREAKPOINT. Inside an
	 * open overlay core does exactly this to every nested submenu — `display: none` on
	 * `.wp-block-navigation__submenu-icon`, then `visibility: visible; opacity: 1; overflow:
	 * initial; height: auto; width: auto; position: static` on the container with
	 * `padding-left: 2rem` (navigation/style.css, the `is-menu-open` block). 2rem is 32px,
	 * the source's own indent, arrived at from the other direction.
	 *
	 * WHAT IT COSTS, STATED RATHER THAN HIDDEN: the `<button>` core renders for "Link 2"
	 * keeps `aria-expanded="false"` while its list is showing, and clicking it changes
	 * nothing a viewer can see. That is the same markup core itself ships inside its own
	 * overlay drawer, and no attribute produces the source's plain anchor.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__submenu-container
		> .wp-block-navigation-item.has-child {
		flex-wrap: wrap;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__submenu-container
		.wp-block-navigation__submenu-container {
		position: static;
		flex-basis: 100%;
		visibility: visible;
		overflow: visible;
		opacity: 1;
		width: auto;
		height: auto;
		padding-left: 32px;
	}

	/*
	 * AND THE AFFORDANCE GOES WITH IT. A chevron on a control whose list is already showing
	 * is a direction cue for a movement that never happens, and the source draws none: its
	 * "Link 2" is an anchor with no glyph of any kind. `display: none` is what core does to
	 * the same span in its own overlay, at (0,3,0) against core's `display: inline-block` on
	 * the bare class — no !important and no dependence on stylesheet order.
	 *
	 * WHAT THIS RETIRES. Two rules stood here that unset core's -90deg flyout rotation and
	 * restored its 180deg open flip on this same span. Both addressed a glyph that is no
	 * longer painted at this breakpoint; keeping them would be styling nothing.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__submenu-container
		.wp-block-navigation__submenu-icon {
		display: none;
	}

	/*
	 * THE OPEN TRIGGER: ONE ELEMENT CARRIES THE CARET, THE FILL AND THE FOCUS RING.
	 *
	 * THE SOURCE'S SHAPE. a.main-navigation-link IS the whole control — 122x39 at 1440x900,
	 * `display:flex; align-items:center`, padding .5rem 1.5rem, with the caret as its own
	 * ::after (14x8, margin-left .5rem) and the open/focus fill on the same box:
	 *
	 *     .main-navigation-link:focus,
	 *     .main-navigation-link[data-bs-toggle=collapse]:not(.collapsed) {
	 *         background-color: #1c3aa9; color: #fff }
	 *     .main-navigation-link[data-bs-toggle=collapse]:after { … width:14px; height:8px }
	 *     .main-navigation-link[data-bs-toggle=collapse]:not(.collapsed):after {
	 *         transform: rotate(180deg) }
	 *
	 * (frontend/dist/styles/main.css as served, read 2026-09-08.) The `li` around it adds
	 * nothing: it is 122 too, because the link fills it.
	 *
	 * WHAT CORE RENDERS INSTEAD. `span.wp-block-navigation__submenu-icon` is a SIBLING of
	 * the toggle button, pulled back over the button's right padding by `margin-left:
	 * -0.6em`. So the button is 100 and the `li` 105.2, the painted box and the outlined box
	 * are different elements, and no fill on either one can enclose the caret cleanly.
	 *
	 * THE FIX IS THE SOURCE'S OWN MECHANISM, not a patch on core's. The sibling span is
	 * hidden at this breakpoint and the caret is drawn as the toggle's ::after, inside the
	 * button — so the button becomes 24 + label + 8 + 14 + 24 = 122, the `li` shrink-wraps to
	 * it, and fill, caret and focus ring are one box. `display:flex; align-items:center` is
	 * the source's own declaration on that element and is what centres the caret against the
	 * label; without it the 8px-tall glyph sits on the text baseline.
	 *
	 * THE SVG IS THE SOURCE'S, byte for byte, including the second copy stroked #fff that it
	 * swaps in when the tab is painted. Reproducing it as a background-image on a ::after is
	 * how the source draws it; there is no core attribute for a menu item's caret.
	 *
	 * NOT BELOW 992px. The desktop bar does not exist there — core's overlay drawer does, and
	 * it keeps core's own affordance. Same boundary as the dropdown chrome above.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle
		+ .wp-block-navigation__submenu-icon {
		display: none;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle {
		display: flex;
		align-items: center;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle::after {
		content: "";
		flex-shrink: 0;
		width: 14px;
		height: 8px;
		margin-left: 8px;
		background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg viewBox='0 0 14 8' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='m1 1 6 6 6-6' stroke='%23333' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
		background-repeat: no-repeat;
		background-position: 50%;
		background-size: contain;
		transition: transform 0.2s ease;
	}

	/*
	 * AN OPEN TRIGGER IS A SOLID BLUE FILLED TAB WITH ITS LABEL AND CARET REVERSED OUT.
	 *
	 * THE COLOUR IS THE `bright-blue` SLUG. units/header.yml `controls` measures the source's
	 * open trigger at backgroundColor rgb(28, 58, 169), color rgb(255, 255, 255), identical
	 * on all three areas — which is why this is written against every top-level toggle and
	 * not only the two carrying a mega panel. rgb(28, 58, 169) is #1c3aa9, theme.json's
	 * `bright-blue`, and the same slug the dropdown's 3px top rule above resolves to, so the
	 * tab is continuous with the rule beneath it. (The contract's prose names the `primary`
	 * slug; in this theme that is #0d6efd, the utility bar's CTA. The measurement wins.)
	 *
	 * ON THE BUTTON AND NOTHING ELSE. The caret is now this element's ::after, so one
	 * declaration paints the whole tab. `color` is not put on the `li`: it inherits, and the
	 * open item's <ul class="wp-block-navigation__submenu-container"> is a DESCENDANT of that
	 * li, so a colour there reverses out the whole dropdown instead of the tab.
	 *
	 * `[aria-expanded="true"]` rather than a class: nothing in core's markup marks an open
	 * item except the toggle's own attribute, which is core's marker and the one the contract
	 * names.
	 *
	 * AND IT IS ALSO WHAT `:focus` PAINTS, WHICH IS A SECOND STATE AND NOT A RESTATEMENT OF
	 * THE FIRST. The source declares the two together and only the two:
	 *
	 *     .main-navigation-link:focus,
	 *     .main-navigation-link[data-bs-toggle=collapse]:not(.collapsed) {
	 *         background-color: #1c3aa9; color: #fff }
	 *     .main-navigation-link[data-bs-toggle=collapse]:focus:after,
	 *     .main-navigation-link[data-bs-toggle=collapse]:not(.collapsed):after {
	 *         background-image: <the #fff copy> }
	 *
	 * (frontend/dist/styles/main.css as served.) Measured on the live source at 1440x900 by
	 * focusing a SHUT trigger — `a.main-navigation-link.collapsed` still carrying its closed
	 * class — backgroundColor rgb(28, 58, 169), color rgb(255, 255, 255) on the same 122x39
	 * box. So a tabbed-to trigger is the blue tab before anything is opened.
	 *
	 * THE ROTATION IS NOT PART OF IT, AND THAT IS WHY THE CARET TAKES TWO RULES INSTEAD OF
	 * ONE. `transform: rotate(180deg)` is declared only on `:not(.collapsed)` — the open
	 * state — while the white glyph is declared on both. A focused shut trigger therefore
	 * points DOWN in white, which is what a control that has not opened anything should do.
	 *
	 * `:focus` AND NOT `:focus-visible`, because that is the selector the source uses: a
	 * mouse press paints it there and must paint it here. It is written on
	 * `.wp-block-navigation-item__content`, the class core puts on both the `<a>` of a plain
	 * item and the `<button>` of a submenu toggle, so a top-level link that is not a
	 * disclosure would take the same fill the source gives it.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle[aria-expanded="true"],
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-item__content:focus {
		background-color: var(--wp--preset--color--bright-blue);
		color: var(--wp--preset--color--white);
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle[aria-expanded="true"]::after,
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle:focus::after {
		background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg viewBox='0 0 14 8' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='m1 1 6 6 6-6' stroke='%23fff' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-submenu__toggle[aria-expanded="true"]::after {
		transform: rotate(180deg);
	}

	/*
	 * AND THE FOCUS RING IS THE BROWSER'S, WHICH IS WHAT THE SOURCE'S IS.
	 *
	 * The source declares no outline on .main-navigation-link at all, so its focused trigger
	 * takes the UA ring: measured rgb(16, 16, 16) auto 1px at offset 1px, drawn around the
	 * same 122x39 box that carries the fill. The forked theme overrides that globally —
	 * `:where(.wp-site-blocks *:focus){outline-width:2px;outline-style:solid}` and
	 * `outline-offset: 4px` on every navigation item content (style.css) — which is a 2px
	 * solid rectangle 4px outside a box that is not the painted one.
	 *
	 * `revert` rather than a hand-typed `auto 1px`: it discards the author-origin
	 * declarations and lets the UA's own ring apply, so this reproduces the source by the
	 * same mechanism the source uses rather than by copying today's computed value.
	 * Top-level items only — the submenu items keep the theme's `outline-offset: 0`, which
	 * is what stops a ring being clipped by the dropdown's edge.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__container
		> .wp-block-navigation-item
		> .wp-block-navigation-item__content:focus {
		outline: revert;
		outline-offset: revert;
	}
}

/*
 * THE DRAWER TAKES OVER AT 992px, AND CORE'S OWN BREAKPOINT IS 600.
 *
 * units/header.yml `behaviour` (b): "the whole desktop navigation … is in the capture at
 * 1440 and 1024 and absent at 768 and 390", and div.header-offcanvas is the mirror. The
 * boundary is Bootstrap lg, which theme.json already carries as
 * settings.viewport.tablet = 991.98px. core/navigation's `overlayMenu` attribute takes only
 * never/mobile/always — there is no breakpoint attribute — and the 600px lives in two
 * `@media (min-width: 600px)` blocks in wp-includes/blocks/navigation/style.css. So
 * 600–991.98px showed a horizontal desktop bar the source does not have there, and its
 * dropdowns opened as a 200x3 sliver.
 *
 * THIS UNDOES EXACTLY THOSE TWO BLOCKS AND NOTHING ELSE. Both of core's rules carry
 * `:not(.is-menu-open)` / `:not(.always-shown)`, and so do these, so once the drawer is open
 * every rule here stops matching and core's own `.is-menu-open` styling applies unaltered —
 * the open state is core's, untouched.
 *
 * ONE DECLARATION EACH IS ENOUGH. The rest of core's @600 block (width, position, z-index,
 * background-color) only ever applies to a container that is `display: none` under this
 * rule, and it drops out with the same `:not(.is-menu-open)` guard the moment the drawer
 * opens, leaving the base `position: fixed` in place.
 */
@media (max-width: 991.98px) {
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container:not(.hidden-by-default):not(.is-menu-open) {
		display: none;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container-open:not(.always-shown) {
		display: flex;
	}

	/*
	 * THE HAMBURGER'S GLYPH IS 32px AND CORE'S IS 24 — and the CONTROL AROUND IT IS 56x48,
	 * WHICH IS THE HALF THIS RULE DID NOT CARRY UNTIL 2026-09-10.
	 *
	 * THE GLYPH. MEASURED at 390x844 on both origins 2026-09-07: reference 32x32, built 24x24.
	 * Core sets `width: 24px; height: 24px` on the open and close buttons' svg together
	 * (wp-includes/blocks/navigation/style.css:630-637); this names the OPEN button only,
	 * because the source's own drawer-close control is not in any capture and giving it a
	 * number measured on a different control would be a guess. The two therefore differ by 8px
	 * inside our drawer, which is recorded rather than tidied away — it is the honest state
	 * until somebody drives the source's offcanvas and measures its close.
	 *
	 * THE CONTROL. The source's hamburger measures 56x48; core's open button carries no
	 * padding of its own, so ours measured 32x32 — the glyph and the button were the same box,
	 * and the affordance was a third of the source's area. MEASURED on page 5 with
	 * tooling/extract/probe.js, before: `.wp-block-navigation__responsive-container-open`
	 * 32x32 at 390/480/540/600/768/900. After: 56x48 at all six.
	 *
	 * THE PADDING IS SOLVED FROM TWO MEASUREMENTS, NOT GUESSED, and it closes in both axes at
	 * once, which is the reason to trust it. 32 + 2x12 = 56 and 32 + 2x8 = 48 — so an 8px/12px
	 * inset around the already-measured 32px glyph reproduces the already-measured 56x48
	 * control exactly, with nothing left over on either axis. It is also Bootstrap's own
	 * `.navbar-toggler` shape ($navbar-toggler-padding-x: .75rem = 12px), which is what the
	 * source's control is. NO BORDER IS ADDED: Bootstrap's toggler has a 1px one by default,
	 * and adding it would make the box 58x50 — the measured 56x48 says this project turned it
	 * off, so reproducing the number is what is done here rather than reproducing the default.
	 *
	 * THE BAND'S HEIGHT DOES NOT MOVE, AND assets/css/blocks/core-group.css IS WHERE THAT IS
	 * PAID FOR. `.header-bar` is 65px tall below 992 on both origins. It was decomposing as
	 * 16 + 32 + 16 + 1 with our undersized toggle; it now decomposes as 8 + 48 + 8 + 1, which
	 * is the SOURCE's own decomposition of the same 65 — that file's own docblock already
	 * recorded the 56x48 and said the padding was what it owed once the toggle was right.
	 * THE TWO CHANGES ARE ONE CHANGE AND MUST NOT BE SPLIT: this rule alone takes the band to
	 * 81px and breaks a ladder that is currently correct at all seven measured widths.
	 *
	 * Specificity (0,3,0) plus the element against core's (0,1,0) plus the element.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container-open {
		padding: 8px 12px;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container-open
		svg {
		width: 32px;
		height: 32px;
	}

	/*
	 * THE DRAWER'S OWN SHAPE. The source's is a Bootstrap `offcanvas-end`
	 * (units/header.yml `behaviour`: data-bs-target="#headerOffcanvas", offcanvas-end,
	 * data-bs-backdrop="false") — right-anchored, 400px wide, white, a 1px left border and
	 * no shadow. Core's overlay is a full-bleed `inset: 0` sheet, so `left: auto` plus a
	 * width is the whole difference; the white ground is already core's for a navigation
	 * with no background of its own.
	 *
	 * `box-sizing: border-box` IS NOT TIDINESS, it is the difference between 400 and 433.
	 * Core sets border-box on the dialog, the close wrapper and the content, but not on this
	 * element, and it pads the drawer `clamp(1rem, root-padding, 20rem)` on all four sides —
	 * so a content-box `width: 400px` measured 433 at 768 and 423 at 390, both wider than the
	 * source's whole drawer. With border-box the box is 400 and its content 367, which is the
	 * width all three areas measure in the source.
	 *
	 * `max-width: 100%` is ours and not the source's: Bootstrap lets a 400px offcanvas hang
	 * 10px off the left edge of a 390px phone, and clamping is the safer half of a
	 * difference nothing measures at that width.
	 *
	 * THE BORDER COLOUR IS INFERRED, NOT MEASURED, and is flagged so. #dee2e6 is Bootstrap
	 * 5.3's own --bs-border-color, which its offcanvas border defaults to and which this
	 * project does not override — the same standing-Bootstrap-default reading
	 * units/mega-menu-panel.yml already makes for $light/$gray-100. It is exactly the
	 * theme's `light-gray` slug, so it is referenced as a preset rather than as a literal.
	 *
	 * z-index IS DELIBERATELY LEFT AT CORE'S 100000 against the source's 1045
	 * ($zindex-offcanvas). Both mean "above everything on the page"; lowering it would put
	 * the drawer under the admin bar and under anything else core stacks between the two,
	 * to reproduce a number nothing else in this build can see.
	 */
	/*
	 * EVERY ROW IN THE DRAWER IS THE DRAWER'S WIDTH. The source's three areas all measure
	 * 367 there — the drawer's 400 less its 32px of padding and its 1px border — while core
	 * shrink-to-fits each one, because it sets
	 * `align-items: var(--navigation-layout-justification-setting, initial)` on the list and
	 * on each item, and this menu's justification is flex-start. Measured before this rule:
	 * A1 264, A3 246, and A2 367 only because its own content happens to be that wide.
	 * `stretch` is the flex default and is what the source's block-level rows amount to; it
	 * is set on the same two elements core names, at one class more than core's (0,4,0).
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation__container,
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation-item {
		align-items: stretch;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open {
		box-sizing: border-box;
		left: auto;
		width: 400px;
		max-width: 100%;
		border-left: 1px solid var(--wp--preset--color--light-gray);
		box-shadow: none;
	}

	/*
	 * THE DRAWER IS A DISCLOSURE, AND CORE'S OVERLAY IS NOT.
	 *
	 * MEASURED, both origins, 768x1024 and 390x844, drawer opened and nothing clicked: the
	 * source shows 0 of its panels, both mobile-nav panels 0x0 with aria-expanded="false", and
	 * tapping an area opens exactly one. This build showed every panel expanded before any
	 * click, at 303x569 and 303x136, with all three triggers inert.
	 *
	 * IT WAS CORE'S DESIGN AND NOT A BUILD SLIP, which is why the fix is two halves and both
	 * are documented where they live. Core's overlay forces every `.has-child` submenu
	 * `opacity:1; visibility:visible; height:auto; width:auto; position:static; min-width:200px`
	 * (navigation/style.css:533-543) and hides the submenu icon (530-532), and its store getter
	 * `isSubmenuOpen` returns `isOverlayOpen || …` so every toggle reads aria-expanded="true"
	 * while the drawer is open. The store half is corrected in functions.php through context,
	 * because that store is locked and cannot be overridden; this is the CSS half.
	 *
	 * IT NARROWS CORE'S RULE RATHER THAN REPLACING IT. The selector below is core's own open
	 * chain plus `:not([aria-expanded="true"])` on the toggle, so it matches only while the
	 * item is SHUT and core keeps owning every value of the OPEN state — its padding, its
	 * min-width, its `position: static`. Restating those here would be a second copy of core's
	 * open state, free to drift from it on the next release.
	 *
	 * The closed values are core's own closed values for a submenu outside the overlay
	 * (navigation/style.css:198-218), plus a padding reset the base rule does not need and this
	 * one does: the overlay adds 2rem of inline padding and a block-gap of top padding, and a
	 * 0x0 box still carries them.
	 *
	 * Specificity (0,8,0) against core's (0,5,0).
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation__responsive-container-content
		.has-child
		.wp-block-navigation-submenu__toggle:not( [aria-expanded="true"] )
		~ .wp-block-navigation__submenu-container {
		visibility: hidden;
		opacity: 0;
		width: 0;
		height: 0;
		min-width: 0;
		overflow: hidden;
		padding: 0;
	}

	/*
	 * THE CHEVRON COMES BACK IN THE DRAWER, because a disclosure with no affordance is not one.
	 *
	 * Core hides the submenu icon inside its overlay (530-532), and it is right to: with every
	 * submenu forced open there is nothing for it to indicate. Once the disclosure is real the
	 * `showSubmenuIcon: true` this menu already carries applies again, and without it "Area 2"
	 * renders as a line of text that happens to be a button.
	 *
	 * NOT MEASURED ON THE SOURCE, and said so. Nothing in any capture drives the source's
	 * offcanvas far enough to record whether it draws a caret there or what it looks like. What
	 * is chosen here is the DESKTOP behaviour of this same menu — label, then chevron, on one
	 * row — because that is the one reading available that invents nothing new.
	 *
	 * THE ROW IS WHY THERE ARE THREE RULES. Core lays every overlay item out as
	 * `display:flex; flex-direction:column`, and the icon is a SIBLING of the toggle button
	 * rather than a child of it, so simply un-hiding it drops the chevron onto its own line
	 * under the label. `row` plus `wrap`, with the submenu list forced onto its own line by a
	 * 100% flex-basis, is the standard idiom for exactly this shape and leaves the drawer's
	 * full-width rows (`align-items: stretch`, above) intact.
	 *
	 * `margin-left: 0` undoes core's `-0.6em` (navigation/style.css:365), which exists to pull
	 * the icon back over the 0.85em of right padding an open-on-click toggle carries. The
	 * overlay sets that toggle's padding to 0 (552-554), so the compensation has nothing left
	 * to compensate for.
	 */
	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation__responsive-container-content
		.wp-block-navigation-item.has-child {
		flex-direction: row;
		flex-wrap: wrap;
		align-items: center;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation__responsive-container-content
		.has-child
		> .wp-block-navigation__submenu-container {
		flex-basis: 100%;
	}

	.wp-block-navigation.main-navigation
		.wp-block-navigation__responsive-container.is-menu-open
		.wp-block-navigation__responsive-container-content
		.has-child
		> .wp-block-navigation__submenu-icon {
		display: inline-block;
		margin-left: 0;
	}
}