/*
 * Header Bar — the floating white bar and the three clusters inside it.
 *
 * Registered by `includes/styles/blocks/core-group-header-bar.php` as an opt-in
 * `core/group` style, activated by `is-style-header-bar` on the group in
 * `parts/header.html`.
 *
 * Only what the editor cannot express is here — plus the shadow, which is a
 * literal rather than a token for the reason noted on it below. The bar's colour,
 * its padding and the gaps between its controls are all in the template part's
 * markup, so they stay editable — including the padding, which differs between
 * mobile and desktop through WordPress 7.1's per-block `@mobile` state.
 *
 * ## It floats
 *
 * In the design the hero's artwork runs to the very top of the viewport and the bar
 * sits over it, inset from three edges — so the bar is `position: fixed` and takes
 * no space in the flow. A sticky bar would reserve its own height at the top of
 * every page and push the hero down by 64px, which is a different design. The
 * consequence is that page content has to clear it itself, and
 * `--kg-header-height` is published on `:root` for exactly that.
 *
 * ## The links are centred on the bar, not on what is left over
 *
 * The design centres the links in the bar, with the logo on one side and three
 * controls on the other — and those two sides are nowhere near the same width, so a
 * flex row with `space-between` would put the links well right of centre. The bar is
 * a three-column grid whose outer columns are forced to equal width instead, which
 * centres the middle one geometrically however wide either end grows.
 *
 * The columns are assigned by `:nth-child` rather than left to auto-placement,
 * because the links are `display: none` below 72rem — an auto-placed row would then
 * pull the controls into the middle column and `justify-self: end` would align them
 * to the middle of the bar. `:nth-child` is structural and does not care.
 *
 * ## Which breakpoint, and why not 48rem
 *
 * The full row — logo, four links, two buttons and the switcher — needs about
 * 1100px before it starts fighting for space, so the links and the buttons are
 * hidden on `@mobile` **and** `@tablet`, and the burger takes over below
 * `settings.viewport.tablet` (72rem). That is a
 * `metadata.blockVisibility.viewport` decision in `parts/header.html` rather than a
 * media query, so it follows `theme.json`.
 */

:root {
	/*
	 * Published so page content can clear the fixed bar. Neither is a theme.json
	 * token: they are facts about one template part rather than design decisions
	 * anything else gets to make. `assets/css/global/header-clearance.css` derives
	 * `--kg-header-clearance` from both.
	 */
	--kg-header-height: 4rem;

	/*
	 * The breathing gap around the bar — **not** its position any more.
	 *
	 * The bar used to be inset by this value; it now sits on the page's `wide` rail
	 * instead (see below), so nothing here positions it. The value survives because
	 * it is still the right answer to a different question: how much room the design
	 * leaves around the floating bar, which is what page content needs in order to
	 * clear it rather than tuck under its shadow.
	 */
	--kg-header-inset: 1.25rem;
}

@media (width > 72rem) {
	:root {
		--kg-header-inset: 3.5rem;
	}
}

.wp-block-group.is-style-header-bar {
	position: fixed;
	inset-block-start: var(--wp-admin--admin-bar--height, 0);
	/*
	 * The bar is exactly as wide as a `wide` block, and sits on the same rail.
	 *
	 * `inset-inline: 0` plus `margin-inline: auto` centres a fixed element, and
	 * `--wp--style--global--wide-size` is the value core emits from
	 * `settings.layout.wideSize` — so the bar tracks the page's gutter at every
	 * width with no number of its own to keep in step. Two hardcoded insets (the
	 * design's 20px and 56px) were the first attempt and drifted badly in between:
	 * at 1000px the bar sat 21px outside the content rail.
	 */
	inset-inline: 0;
	margin-inline: auto;
	max-inline-size: var(--wp--style--global--wide-size, 100%);
	/*
	 * Above the menu overlay's layer (z-index 100): the design keeps the bar — and
	 * so the close button — visible over the open menu. This works only because the
	 * overlay is printed at the end of the document rather than inside this bar; a
	 * descendant of a stacking context cannot paint below that context's own
	 * content, whatever z-index it carries. See `defer_overlay()` in
	 * `includes/blocks/menu-button.php`.
	 */
	z-index: 200;

	display: grid;
	/*
	 * `minmax(min-content, 1fr)` rather than `1fr`, and the floor is the point: at
	 * the narrow end of the desktop range the controls need slightly more than
	 * their equal share, and a bare `1fr` track cannot grow — the cluster
	 * overflows and collides with the links. A `min-content` floor lets the track
	 * take what it needs and pushes the links a couple of pixels off centre
	 * instead, which is invisible and self-healing.
	 */
	grid-template-columns: minmax(min-content, 1fr) auto minmax(
			min-content,
			1fr
		);
	align-items: center;

	/*
	 * The bar's own height rather than padding on its contents: the design's 64px
	 * bar holds 44px controls with 10px above and below, and pinning the height is
	 * what keeps that true when a control's padding is edited.
	 */
	block-size: var(--kg-header-height);
	/*
	 * `useRootPaddingAwareAlignments` is on, so the group would otherwise inherit
	 * the root padding vertically. The bar's block padding is its height.
	 */
	padding-block: 0;

	/*
	 * Figma's header shadow. A literal rather than a `theme.json` shadow preset:
	 * only this one element uses it, and a preset is a control the editor offers
	 * everywhere and a custom property core emits on every page. The bar's colour
	 * stays a token in the markup — that one an editor might reasonably change.
	 */
	box-shadow: 0 4px 64px 0 rgb(0 0 0 / 8%);
}

/*
 * Core's flow layout gives every child a `margin-block-start`, which in a grid
 * shows up as the row's contents sitting low. Its rules are wrapped in `:where()`,
 * so this outranks them without `!important`.
 */
.wp-block-group.is-style-header-bar > * {
	margin-block: 0;
}

.wp-block-group.is-style-header-bar > :nth-child(1) {
	grid-column: 1;
	justify-self: start;
}

.wp-block-group.is-style-header-bar > :nth-child(2) {
	grid-column: 2;
}

.wp-block-group.is-style-header-bar > :nth-child(3) {
	grid-column: 3;
	justify-self: end;
}

/* One row of links, never two — the bar has no room to grow. */
.wp-block-group.is-style-header-bar .wp-block-navigation__container {
	flex-wrap: nowrap;
}

/*
 * `core/button` is **not** styled here. Its flex box and its 44px height are the
 * `core/button` default block style's (`includes/styles/blocks/core-button.php`),
 * which applies site-wide and already uses the same control height; and its square
 * corners come from the `border.radius` on each button in `parts/header.html`,
 * which beats core's `:where(.wp-block-button__link){border-radius:9999px}`
 * outright. Restating either here would be two files claiming one decision.
 *
 * What is left is the one thing specific to a bar with no room to grow.
 */
.wp-block-group.is-style-header-bar .wp-block-button__link {
	white-space: nowrap;
}

/*
 * The three custom controls are not `core/button`, so they get the design's
 * control height here.
 */
.wp-block-group.is-style-header-bar
	.wp-block-kg-product-menu-button:not([hidden]),
.wp-block-group.is-style-header-bar
	.wp-block-kg-product-menu-close-button:not([hidden]),
.wp-block-group.is-style-header-bar
	.wp-block-kg-product-language-switcher__toggle {
	display: flex;
	align-items: center;
	/* 44px — the design's control height inside the 64px bar. */
	min-block-size: 2.75rem;
}

/*
 * The menu toggles occupy the same slot, so the flag beside them does not shift
 * when the burger is replaced by the close icon. Both are `hidden` in turn rather
 * than removed — which is why every rule above that sets their `display` carries
 * `:not([hidden])`: `[hidden] { display: none }` is a UA rule, and an unguarded
 * author `display` beats it and shows both at once.
 */
.wp-block-group.is-style-header-bar
	.wp-block-kg-product-menu-button:not([hidden]),
.wp-block-group.is-style-header-bar
	.wp-block-kg-product-menu-close-button:not([hidden]) {
	justify-content: center;
	/* The design's 16px glyph in a 44px-tall, 36px-wide hit area. */
	min-inline-size: 2.25rem;
}

/*
 * Where a submenu panel lands, and how the pointer gets to it.
 *
 * What the panel *looks* like is `assets/css/blocks/navigation.css`, the default
 * `core/navigation` style. These two rules are the half that only makes sense
 * inside this bar, so they live with the bar.
 *
 * Core hangs a panel at `top: 100%` — the bottom edge of the link that opens it.
 * That is the right answer for a menu whose items fill their container and the
 * wrong one here: a 15px link centred in a 64px bar has its bottom edge around
 * 41px down, so the panel would start halfway up the bar and cover the links
 * beside it. The design puts it 4px below the bar. Measured from the link's own
 * top edge that is `50%` (the link's centre, which is the bar's centre, because
 * the bar's grid centres it) plus half the bar plus the gap — so the offset is
 * derived from `--kg-header-height` and follows it if the bar's height changes.
 */
.wp-block-group.is-style-header-bar
	.wp-block-navigation
	.has-child
	> .wp-block-navigation__submenu-container {
	top: calc(50% + var(--kg-header-height) / 2 + 0.25rem);
}

/*
 * That offset opens a ~26px band between the link and the panel with nothing in
 * it, and a submenu is held open by `:hover` on the `<li>` the panel is a child
 * of — so a pointer moving down from the link crosses dead ground and the panel
 * closes before it arrives. The band has to belong to the `<li>` too.
 *
 * A generated bridge, which is core's own answer to the same problem one level
 * down (`.wp-block-navigation__submenu-container::before`, a `.5em` strip beside
 * a nested panel). `content` is declared only in the hovered and focused state,
 * so the strip does not exist the rest of the time — a permanent invisible band
 * hanging under the menu would swallow pointer events over the bar for no
 * reason. It appears the instant the link is hovered, which is soon enough to
 * catch the pointer on its way down.
 *
 * Its height is the same arithmetic as the offset above, less the half of the
 * link's own box that `top: 50%` already skipped: a percentage `block-size`
 * resolves against the containing block, which for a pseudo-element on the
 * `<li>` is the `<li>`.
 */
.wp-block-group.is-style-header-bar
	.wp-block-navigation
	.has-child:hover::after,
.wp-block-group.is-style-header-bar
	.wp-block-navigation
	.has-child:focus-within::after {
	content: "";
	position: absolute;
	inset-inline: 0;
	inset-block-start: 100%;
	block-size: calc(var(--kg-header-height) / 2 + 0.25rem - 50%);
}