/**
 * Real masonry layout for the front page's module rows.
 *
 * File Name:     front-page-layout.css
 * Version:       1.4.0
 * Last Modified: 2026-09-21
 * Package:       TheHomepageExtensions / Assets
 *
 * CSS multi-column, not CSS Grid: grid locks items into fixed rows, so a
 * short column leaves a dead gap beside a tall one instead of letting
 * shorter columns backfill (David, 2026-09-21: "the gaps above them where
 * column content falls short does not work — we need a real Masonry type
 * of layout"). Multi-column's `column-fill: balance` (the default) actively
 * equalizes column heights, which is real masonry packing with zero JS.
 *
 * Trade-off, deliberate: reading order becomes top-to-bottom-then-next-
 * column instead of left-to-right-across-a-row, since that's how content
 * flows into columns. Each wp:column is kept as one unbreakable masonry
 * unit (break-inside: avoid) rather than breaking individual feed-modules
 * out further — matches the existing template structure (e.g. Local News +
 * Weather Alerts already intentionally grouped in one column).
 *
 * Selectors are compounded with .wp-block-columns (not just the bare
 * .thp-columns--N class): core's own `.wp-block-columns{display:flex}` rule
 * has identical specificity to a single class selector and would win on
 * source order otherwise (confirmed the hard way earlier today — the first
 * cut of this file used bare class selectors and the breakpoints silently
 * never applied).
 */

/*
 * Full width + matching edge gutter (David, 2026-09-21): the old site goes
 * full width, with an edge margin equal to the space between columns --
 * not a narrow centered container. Two wrong approaches tried and reverted
 * before landing here: a CSS max-width/center hack, then a shell
 * `align:"full"` + columns `align:"full"` combo that over-corrected (the
 * `alignfull` class breaks a block out past its ancestor's own padding
 * entirely, so the shell's padding-inline was being bypassed and content
 * ran flush to the browser edge with zero gutter).
 *
 * Actual fix lives in the template markup, not here: the shell Group block
 * has `layout:{"type":"default"}` (the real value for "Inner blocks use
 * content width" OFF -- not `"flow"`, which is invalid and breaks the
 * block entirely) and the columns block carries no align attribute at all.
 * With no width constraint imposed and no align breakout, the columns
 * block renders at exactly 100% of the shell's own content box -- which is
 * already inset by the shell's padding-inline (the same spacing token as
 * the column-gap below), so the edge gutter matches the inter-column gap
 * automatically. This is a per-block attribute on this one template, not a
 * fleet-wide layout default -- see ROADMAP.md for the deferred fleet-wide
 * question.
 */

/*
 * Identity block moved inside the first masonry column (David, 2026-09-21:
 * "The identity block is the same width as a column so that subsequent
 * columns flow around it").
 *
 * Nav (David, 2026-09-21, second pass): "the menu hamburger should behave
 * like the Branding block" -- i.e. in-flow at the top of its own column,
 * not an absolute overlay (the overlay was floating on top of column
 * content, colliding with the Your Weather heading). It's placed as the
 * first block inside the LAST wp:column in the template, so multi-column's
 * document-order flow always lands it in the rightmost rendered column at
 * any column-count. Only at the single-column breakpoint does it get
 * pulled back to absolute -- "when we are down to one column the Branding
 * and Menu will share that top row" -- since at 1 column, DOM order alone
 * would put it at the very bottom (last block in source order) instead of
 * beside Identity at the top.
 */
.thp-homepage-shell {
	position: relative;
}

.thp-nav-fixed {
	display: flex;
	justify-content: flex-end;
	margin-block-end: var(--wp--preset--spacing--40, 2rem);
}

@media (max-width: 599px) {
	.thp-nav-fixed {
		position: absolute;
		inset-block-start: var(--wp--preset--spacing--40, 2rem);
		inset-inline-end: var(--wp--preset--spacing--40, 2rem);
		margin-block-end: 0;
		z-index: 10;
	}
}

.wp-block-columns.thp-columns--4,
.wp-block-columns.thp-columns--2 {
	display: block;
	column-gap: var(--wp--preset--spacing--40, 2rem);
}

.wp-block-columns.thp-columns--4 {
	column-count: 4;
}

.wp-block-columns.thp-columns--2 {
	column-count: 2;
}

.wp-block-columns.thp-columns--4 > .wp-block-column,
.wp-block-columns.thp-columns--2 > .wp-block-column {
	display: inline-block;
	inline-size: 100%;
	break-inside: avoid;
	vertical-align: top;
	margin-block-end: var(--wp--preset--spacing--40, 2rem);
}

@media (max-width: 1199px) {
	.wp-block-columns.thp-columns--4 {
		column-count: 3;
	}
}

@media (max-width: 899px) {
	.wp-block-columns.thp-columns--4,
	.wp-block-columns.thp-columns--2 {
		column-count: 2;
	}
}

@media (max-width: 599px) {
	.wp-block-columns.thp-columns--4,
	.wp-block-columns.thp-columns--2 {
		column-count: 1;
	}
}

/*
 * Hamburger + overlay menu sizing (David, 2026-09-21: "hamburger has to be
 * bigger, menu has to be bigger"). The 90px hamburger value is the old
 * site's own proven size, reused deliberately rather than picked fresh.
 * The header row itself stays outside the masonry flow above — a fixed
 * top bar, not a packable item.
 */
.wp-block-navigation__responsive-container-open svg {
	inline-size: 90px;
	block-size: 90px;
}

.wp-block-navigation__responsive-container-content .wp-block-navigation-item__content {
	font-size: 2rem;
	font-weight: 700;
}

/*
 * Listen Now audio player (David, 2026-09-21: "fix ... the Listen now
 * block"). The native browser <audio controls> element has a built-in
 * minimum width (browser-dependent, commonly 200-300px) that doesn't
 * respect a parent's narrower width on its own -- it was sized for the
 * old two-column-wide treatment; the unified masonry merge put it in a
 * quarter-width column instead, where the native control could overflow.
 */
.wp-block-audio {
	max-inline-size: 100%;
}

.wp-block-audio audio {
	inline-size: 100%;
}