/*
 * Navigation — the submenu panel that drops out of a top-level link.
 *
 * Registered by `includes/styles/blocks/core-navigation.php` as the **default**
 * `core/navigation` style, so it adds no class and every menu in the theme is
 * dressed by it.
 *
 * The panel, and the current page's own menu item. A top-level link's colour,
 * size and weight are the block's own controls in `parts/header.html`; its hover
 * and focus states are `assets/css/global/ui-states.css`; and *where* the panel
 * lands relative to the floating header bar is
 * `assets/css/blocks/header-bar.css`, because that offset is a fact about one
 * template part rather than about menus.
 *
 * The current item is here rather than beside those other link states because
 * **its place in this file's source order is what makes it correct** — see the
 * rule itself.
 *
 * ## Why every selector here is longer than it looks like it needs to be
 *
 * `blocks/navigation/style.css` is the most defensively written sheet core ships.
 * The panel's white ground and hairline border are 0-3-0
 * (`.wp-block-navigation:not(.has-background) .wp-block-navigation__submenu-container`);
 * a submenu link's `padding: .5em 1em` is 0-5-0; and a link's colour is pinned by
 * the doubled-class trick `ui-states.css` documents at length. So each rule below
 * is core's own selector plus a type selector — one step above it, which is the
 * smallest thing that wins. `!important` would also work, and would take the
 * decision away from whoever needs to override it next; an extra `ul` does not.
 *
 * ## `:not(.open-always)`, on every panel rule
 *
 * `open-always` is the class core puts on a submenu that is unfolded in place —
 * an indented list inside its own responsive overlay — where a ground, a shadow
 * and a fixed width are all wrong. No menu in this theme is in that state today
 * (`overlayMenu` is `never` everywhere; the burger opens
 * `parts/menu-overlay.html` instead), which is why the guard is cheap to write
 * now and expensive to work out later.
 */

/*
 * The panel.
 *
 * `border: 0` before anything else: core draws a 1px `rgba(0,0,0,.15)` hairline
 * around an unbackgrounded submenu, and the design has no line at all — the
 * shadow is what separates the panel from the page. That shadow is the header
 * bar's own, and a literal here for the same reason it is a literal there: one
 * value, two elements, and a `theme.json` preset would be a control offered
 * everywhere plus a custom property emitted on every page.
 *
 * `padding-inline: 0` is load-bearing rather than tidy-minded. The design's
 * hover state fills the row edge to edge, so the 24px of air beside a label has
 * to belong to the link and not to the panel around it; put it here and the fill
 * stops 24px short on both sides.
 */
.wp-block-navigation
	.has-child:not(.open-always)
	> ul.wp-block-navigation__submenu-container {
	border: 0;
	background-color: var(--wp--preset--color--white);
	box-shadow: 0 4px 64px 0 rgb(0 0 0 / 8%);
	/* The design's panel is translucent over whatever it covers. */
	backdrop-filter: blur(22px);

	padding-block: 0.75rem;
	padding-inline: 0;

	/*
	 * Centred under the link that opens it, rather than core's `left: -1px`.
	 * Measured off the design: the panel's centre line sits within 8px of the
	 * trigger's, and its left edge 117px away from it — so it is centred by
	 * intent and left-aligned by nothing.
	 */
	left: 50%;
	transform: translateX(-50%);
}

/*
 * The panel's width, stated on the rows rather than on the panel.
 *
 * The design's panel is 343px, which is ~50px wider than its longest label needs
 * — a real number, not a shrink-wrap. The obvious place for it is the panel's
 * own `min-width`, and that is the one place it cannot go: core sets
 * `min-width: 200px` in each of the three *open* states, at 0-5-0 and 0-6-0, so
 * overriding it means restating three selectors including `:not(.open-on-click)`
 * and `:not(.open-on-hover-click)` verbatim. A flex column with `width: auto`
 * takes the width of its widest child instead, so one rule on the row does the
 * same job with nothing to keep in step. A longer label still grows the panel.
 */
.wp-block-navigation
	.has-child:not(.open-always)
	> .wp-block-navigation__submenu-container
	> .wp-block-navigation-item {
	min-inline-size: 21.4375rem;
}

/*
 * A row.
 *
 * 12px and 24px rather than core's `.5em 1em`, which at this size would be 9px
 * and 18px — and which is an `em` of a font size the row is about to change.
 * `display: flex` and `flex-grow: 1` are core's and stay: they are what makes the
 * link fill the row, which is what the hover fill needs.
 *
 * The type is the header bar's own — 15px, the `ui` preset — so a panel row
 * reads at the same size as the link that opened it. It is restated here rather
 * than left to inherit because core sizes a submenu link itself; a declaration
 * on the child beats an inherited value whatever either one's specificity, so
 * this needs no help from the selector, and the length of the selector is only
 * about the padding. The weight stays Medium: the row is a destination under a
 * heading, not a peer of the Semi Bold label above it.
 */
.wp-block-navigation
	.has-child:not(.open-always)
	> .wp-block-navigation__submenu-container
	> li.wp-block-navigation-item
	> .wp-block-navigation-item__content {
	padding: 0.75rem 1.5rem;
	font-size: var(--wp--preset--font-size--ui);
	font-weight: 500;
	line-height: var(--wp--custom--line-height-heading);
}

/*
 * The current page's own item: an underline, and nothing else.
 *
 * Core does all the work of finding it — `current-menu-item` on the `<li>`, plus
 * `aria-current="page"` on the link — so this is only the visual half. Two
 * things about *when* it is set are worth knowing before debugging a menu that
 * looks unmarked:
 *
 * - **Core alone marks only an item inserted as a page.**
 *   `render_block_core_navigation_link()` asks
 *   `get_queried_object_id() === (int) $attributes['id']`, and a link added as a
 *   custom URL has no `id` to compare. `includes/blocks/navigation-current.php`
 *   covers that case by matching on the URL instead, which is what makes a menu
 *   built out of typed addresses mark at all. An item pointing at `#` still
 *   never matches, because it names no page.
 * - **Only the page itself is marked.** Core also offers
 *   `current-menu-ancestor` on the top-level item a current submenu row sits
 *   under, and this deliberately leaves it alone: "Branscher" is not the page
 *   you are on.
 *
 * The underline carries the whole state, and no colour goes with it. The accent
 * is what `ui-states.css` gives a *hovered* menu item, so spending it here would
 * make current and hovered indistinguishable — and it would put two competing
 * blues in a header whose only other blue is the "Kontakta oss" button. An
 * underline is also not a colour, so the state survives being unable to tell the
 * two apart, and a current item still turns blue on hover like any other.
 *
 * 0-4-1 by the doubled class this theme uses everywhere for `core/navigation`.
 * That is above the hover and focus rules in `ui-states.css` (0-3-1), which set
 * `text-decoration: none` on every menu item — so **a current item keeps its
 * underline while it is hovered** instead of having it taken back.
 *
 * ## Why this rule sits where it does in this file
 *
 * The panel's own hover and focus rules below are 0-4-1 as well and also set
 * `text-decoration: none`, and they must beat this one: inside the dropdown a
 * hovered row fills with brand blue and turns its label white, and the design
 * draws no underline in it. Equal specificity is settled by source order, so
 * this goes *above* them — which is also why it is in this file at all rather
 * than next to the other menu link states in `ui-states.css`, where the order of
 * two separately enqueued sheets is not something to rely on.
 */
.wp-block-navigation
	.current-menu-item
	> a.wp-block-navigation-item__content.wp-block-navigation-item__content {
	text-decoration: underline;
}

/*
 * The hovered row, which is the whole state: the design fills it with the brand
 * blue and turns the label white. This is the one place in the theme where a
 * menu item's hover is a fill rather than a colour shift, so it has to say both
 * halves and take back the colour `ui-states.css` sets for every other menu item.
 *
 * 0-4-1 — one class above that rule and above core's `.content.content` — and
 * guarded by `@media (hover: hover)` for the reason the whole of `ui-states.css`
 * is: an unguarded `:hover` leaves the last tapped row filled blue on a phone.
 */
@media (hover: hover) {
	.wp-block-navigation
		.wp-block-navigation__submenu-container
		a.wp-block-navigation-item__content:hover {
		background-color: var(--wp--preset--color--brand-blue);
		color: var(--wp--preset--color--white);
		text-decoration: none;
	}
}

/*
 * The same row reached by keyboard, plus two corrections to the theme's own
 * link ring — both of which exist because that ring is written for a link in
 * prose and this is a full-width fill.
 *
 * `outline-offset` goes *negative*, so the ring is drawn inside the row instead
 * of 2px outside it, where it would break the panel's edge; and the `-3px`
 * inline margin `ui-states.css` gives a focused link is zeroed, because the 3px
 * of padding it pairs with is overridden by the row's own 24px above and the
 * margin alone would hang the fill 3px past the panel on both sides.
 */
.wp-block-navigation
	.wp-block-navigation__submenu-container
	a.wp-block-navigation-item__content:focus-visible {
	background-color: var(--wp--preset--color--brand-blue);
	color: var(--wp--preset--color--white);
	text-decoration: none;
	outline-offset: -2px;
	margin-inline: 0;
}

/*
 * The chevron beside a link that has a submenu.
 *
 * Core sizes it in `em` of the link — `.6em`, `.25em` of air — which lands on
 * 9px and 3.75px against the header's 15px label. The design draws the same
 * chevron at 10px with 8px of air, and those are absolute: the gap matches the
 * 8px the design uses between a label and its affordance, not a ratio of the
 * type.
 *
 * The selector goes through the `<li>` rather than naming an element, because
 * the element changes: with `openSubmenusOnClick` off — this theme's case, and
 * core's default — the icon is a `<button>` that toggles the panel, and with it
 * on it is a `<span>` inside the link. Core's rule is 0-2-0; the `<li>`'s own
 * `wp-block-navigation-submenu` class is the third, and it is there in both
 * shapes.
 */
.wp-block-navigation
	.wp-block-navigation-submenu
	> .wp-block-navigation__submenu-icon {
	inline-size: 0.625rem;
	block-size: 0.625rem;
	margin-inline-start: 0.5rem;
}

/*
 * The chevron does not turn over when the panel opens.
 *
 * Core flips it 180° on `aria-expanded="true"`, which is the conventional
 * affordance and is not what the design draws: both Figma frames show the panel
 * open with the chevron still pointing down at the thing it opened. Nothing is
 * lost by following them — the state a sighted reader needs is the panel itself,
 * two pixels below, and the state assistive technology needs is `aria-expanded`,
 * which core still sets and this does not touch.
 *
 * Core's rule is 0-2-1 (the attribute counts as a class), so this is 0-3-1.
 */
.wp-block-navigation
	.wp-block-navigation-submenu__toggle[aria-expanded="true"]
	> svg {
	transform: none;
}