/**
 * core/group — the four full-bleed bands of the header and the footer.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/group', … ), the same mechanism and for the same reasons as
 * core-navigation.css beside it: one stylesheet attached to one block, enqueued on render
 * where the site opts into on-demand block assets, and 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, so a rule added there would be written, committed and silently never served.
 *
 * WHY CSS AT ALL, given the build ladder forbids skipping rungs. Every number below was
 * written inline in patterns/header.php and patterns/footer.php as a literal — 12px, 10px,
 * 50px, 20px — and inline literals in a pattern are exactly what `presets-not-hardcoded`
 * refuses: a pattern's markup is copied into content, so a literal there can never be
 * corrected in one place afterwards. The rungs above this one were each tried and each is
 * closed:
 *
 *   - THE PRESET RUNG IS CLOSED BY A RECORDED DECISION. `var:preset|spacing|N` is what core
 *     writes for a band's padding and it is what this theme writes everywhere a value is on
 *     its scale. None of these four is. ai/site.yml's settings.spacing.spacingSizes is
 *     `decided`: five slugs, 20–60, re-valued from the source's own Bootstrap $spacers map,
 *     with "a `size` sitting in this file between measured Bootstrap steps reads as this
 *     project's decision to every later reader" as the reason no sixth is claimed. Adding a
 *     rung for 10, 12, 20 or 50 would re-open that.
 *   - AND THE SOURCE AGREES WITH IT. These are not steps on the source's scale either. In
 *     the source's own CSS they are `padding: .75rem 0` on .header-utility-bar
 *     .utility-navigation, `.625rem 0` on .header-bar, `3.125rem 0` on .footer-content and
 *     .footer-nav, and `1.25rem 0` on .footer-bottom — five literals in five component
 *     rules. Reproducing the source's decomposition means putting them where the source
 *     puts them, which is here.
 *   - theme.json styles.blocks cannot reach them: they are four ordinary core/group
 *     instances and a `styles.blocks.core/group` rule would land on every group on the site.
 *   - A block style variation (styles/*.json, core's `is-style-` mechanism) WOULD reach
 *     them, and is rejected on meaning rather than on mechanism: a variation is a style a
 *     user PICKS, and Twenty Twenty-Five's own section-1…5 are interchangeable colour
 *     treatments. These four are the identity of one band each. Registering them would put
 *     four meaningless options in the Styles panel of every group on the site.
 *
 * SCOPED BY className, the same hook kind as `main-navigation` next door. core/group
 * declares no `supports.customClassName: false`, so it defaults to true and the class lands
 * on the rendered wrapper. The class is doubled with .wp-block-group so a name as ordinary
 * as `footer-content` cannot reach anything that is not this block.
 *
 * EVERY DESKTOP (1440x900) VALUE HERE WAS MEASURED ON THE SOURCE, element by element, and
 * none of THOSE is arithmetic over a difference. The two @mobile overrides added 2026-09-08
 * are the one exception, stated rather than left to look like the same kind of number: the
 * source's own narrow-viewport CSS is not in this build's projection (ai/reference/,
 * ai/verify/ are forbidden to it — wp-site-build's artifact rule), so each is solved from
 * the row height ai/units.yml already measured on both origins, minus this band's own
 * already-measured content height at that viewport. Both land exactly on this theme's own
 * spacingSizes scale (0.5rem/slug-30 and 1rem/slug-40 — theme.json), which is why each is
 * written as that preset rather than as the literal px the arithmetic produced.
 *
 * AND THE VIEWPORT AT WHICH THEY TAKE OVER IS 992, NOT 576 — CORRECTED 2026-09-10 AFTER A
 * WIDTH SWEEP, and the two numbers themselves are unchanged. Both overrides were written
 * against `max-width: 575.98px` because 390x844 was the only narrow viewport with a
 * measurement and 576 is the only other boundary this theme expresses; nothing had looked
 * between 576 and 991. Swept on both origins at 480 / 540 / 600 / 768 / 900 / 992 / 1440 and
 * read on .wp-block-group.header-bar: THE SOURCE STEPS EXACTLY ONCE, at 992 — 65 tall at
 * y=50 at every width below it and 60 at y=58 at 992 and above — while this file's 576 gave
 * the build a SECOND step and a third size (53 at y=58) that the source renders at no width
 * at all, across the whole 576–991 band. 768 was the only captured viewport inside it, which
 * is why it read for two passes as a lone 768-only anomaly rather than as a band. 992 is
 * also the boundary the unit's own `behaviour` already names (Bootstrap lg, where the source
 * swaps .header-desktop for .header-mobile) and the one core/navigation's overlayMenu is set
 * to here, so the band's padding now steps with the content that fills it instead of 416px
 * earlier than it.
 *
 * @package WordPress
 * @subpackage Xperience_Starter
 * @since Xperience Starter 1.0
 */

/*
 * The blue utility strip above the main bar. Measured on the source's own
 * nav.utility-navigation inside div.header-utility-bar: padding-top 12px,
 * padding-bottom 12px, and 0 on both inline sides — the inline gutter is the container's,
 * not this band's, which is why only the block axis is stated.
 *
 * @below-992 SHRINKS THE BAND TO 8px (var --wp--preset--spacing--30, 0.5rem). ai/units.yml's
 * `header` row measured this band at 58px at 1440x900/1024x768 and 50px at 390x844, both
 * origins. The 12px above already accounts for the 58 (12+12 plus this band's own 34px-tall
 * "Contact Us" CTA, fixed separately in core-button.css). 50 - 34 = 16, halved is 8 — solved,
 * not measured at this viewport, because the source's own narrow-viewport rule is outside
 * this build's projection. THE BOUNDARY IS 991.98 AND WAS 575.98 UNTIL 2026-09-10: the width
 * sweep in this file's docblock reads the source at 50px tall at 600, 768 and 900 as well as
 * at 480 and 540, so the 8px band is what the source renders everywhere below lg and the
 * 575.98 spelling was serving 12px over 416px of that. The 8 itself is unchanged.
 */
.wp-block-group.header-utility-bar {
	padding-block: 12px;
}

@media (max-width: 991.98px) {
	.wp-block-group.header-utility-bar {
		padding-block: var(--wp--preset--spacing--30);
	}
}

/*
 * THE 12px UTILITY-BAR GUTTER, SCOPED TO THIS BAND'S OWN INNER ROW AND NOT TO THE BAND
 * ITSELF. Measured on the source: utility-bar text starts at x=84 against the logo one band
 * down at x=72 on both sides — a gutter this band alone has. `header-utility-row` is the
 * inner flex row wrapping the utility nav and the CTA (patterns/header.php), and
 * `padding-inline-start` rather than `padding-inline` is deliberate: the row's own box
 * position does not move (fixed by header-utility-bar's `constrained` layout above it), so a
 * start-only inset shifts the left (nav) child in by 12px while the right (button) child —
 * anchored by `justifyContent:space-between` to this row's own unchanged right inner edge —
 * stays exactly where it already measured correctly, x=1228 on both sides.
 */
.wp-block-group.header-utility-row {
	padding-inline-start: 12px;
}

/*
 * The main bar carrying the logo, the primary navigation and the account icons. Measured on
 * the source's div.header-bar: padding-top 10px, padding-bottom 10px, inline 0.
 *
 * @below-992 SHRINKS THE BAND'S PADDING TO 8px (var --wp--preset--spacing--30, 0.5rem), AND
 * IT WAS 16px UNTIL 2026-09-10 FOR A REASON THAT HAS NOW BEEN REMOVED. The band itself does
 * not move: ai/units.yml's `header` row measures it at 60px at 1440x900/1024x768 and 65px at
 * 390x844 on both origins, and a seven-width sweep reads 65 at 480/540/600/768/900 too.
 * What changed is WHICH DECOMPOSITION of that 65 this build uses.
 *
 * THE OLD ONE WAS 16 + 32 + 16 + 1, AND ITS 32 WAS OUR OWN DEFECT. This band's own content
 * below 992 is the drawer toggle, and the band's 1px bottom hairline sits outside the padding
 * box. The toggle measured 32px tall here because core's open button carries no padding and
 * we had sized only its svg — so the 16 was SOLVED backwards from a wrong term to make the
 * total come out right, and this file's previous note said exactly that: the source's
 * hamburger measures 56x48, "the two decompositions differ and the totals agree, so the
 * padding is what this file owes and the toggle's box is a separate difference reported
 * against core-navigation.css rather than absorbed here."
 *
 * THE NEW ONE IS 8 + 48 + 8 + 1 = 65, AND EVERY TERM IN IT IS THE SOURCE'S. The toggle is now
 * 56x48, the source's own measurement, given its control box in
 * assets/css/blocks/core-navigation.css. 65 - 1 - 48 = 16, halved is 8 — still solved rather
 * than measured at this viewport, because the source's own narrow-viewport padding rule is
 * outside this build's projection, but now solved from the SOURCE's toggle height instead of
 * from ours. It lands exactly on this theme's spacing--30 preset, the same slug the utility
 * bar above already uses, which is why it is written as the preset and not as `8px`.
 *
 * THE TWO CHANGES ARE ONE CHANGE. Either alone breaks the band: the toggle's padding without
 * this takes it to 81, this without the toggle's padding takes it to 49. Measured after both:
 * 65 at 480/540/600/768/900 and 60 at 992/1440, one step, unchanged from before.
 *
 * THE BOUNDARY IS 991.98 AND WAS 575.98 UNTIL 2026-09-10, the same correction as the utility
 * bar's and read off the same sweep: the source is 65 tall at 600, 768 and 900 too, and at
 * 575.98 this band computed a third size across that whole range that neither origin's source
 * renders at any width. It used to attribute the 1px to a hairline painted on
 * `.main-navigation` in core-navigation.css, which was the wrong element (a 366px-wide nav
 * box, not a 1440px band) and is gone — see that file's own note and patterns/header.php's
 * docblock.
 *
 * THE HAIRLINE ITSELF IS NOT IN THIS FILE AND MUST NOT BE ADDED TO IT. It is a `core/group`
 * block attribute on this same band in patterns/header.php: `style.border.bottom` with the
 * colour as `var:preset|color|body-text`. core/group declares supports.__experimentalBorder,
 * so that rung is open and the build ladder says to take it — unlike this band's padding,
 * whose own rungs are closed by the recorded spacingSizes decision above, and unlike
 * `.footer-bottom`'s border below, whose colour cannot be a preset.
 */
.wp-block-group.header-bar {
	padding-block: 10px;
}

@media (max-width: 991.98px) {
	.wp-block-group.header-bar {
		padding-block: var(--wp--preset--spacing--30);
	}
}

/*
 * The footer's first band, the one that paints `footer-content`. Measured on the source's
 * div.footer-content: 50px top and bottom. Its three columns carry a second 50px of their
 * own — that is the source's own layering, not a duplicate, and it is in core-column.css
 * because a column is a different block.
 */
.wp-block-group.footer-content {
	padding-block: 50px;
}

/*
 * The blue link band. Measured on the source's div.footer-nav: 50px top and bottom, the
 * same pair as .footer-content above and stated separately because they are two rules in
 * the source and either could move without the other.
 */
.wp-block-group.footer-nav {
	padding-block: 50px;
}

/*
 * The copyright bar. Measured on the source's div.footer-bottom: padding 20px top and
 * bottom over `border-top: 1px solid rgba(255, 255, 255, 0.3)`.
 *
 * THE RULE IS A LITERAL AND IT HAS NOWHERE ELSE TO GO. It is white at 30%, which is not a
 * palette entry and must not become one — a palette slug is a colour a client picks, and
 * this is one component's hairline. `color-mix(in srgb, var(--wp--preset--color--white)
 * 30%, transparent)` would express it through the preset and is deliberately not used: it
 * is a second serialisation of the same value that computes to `color(srgb 1 1 1 / 0.3)`
 * rather than to the `rgba()` the source reports, which would turn an exact match in the
 * comparison into a difference nobody could act on. The source writes it as
 * `hsla(0, 0%, 100%, .3)`; this is that value in the form the browser reports it.
 */
.wp-block-group.footer-bottom {
	padding-block: 20px;
	border-block-start: 1px solid rgba(255, 255, 255, 0.3);
}