/*
 * Shared public-site shell (Shared Public Page Shell pass). Every rule in
 * this file is scoped under body.hcfb-public-shell -- a class added to
 * EVERY front-end request's body_class (functions.php), homepage
 * included, so this is the single source of truth for site chrome
 * (utility bar, header row, mega-nav, footer-home) across all public
 * templates. Enqueued unconditionally (no is_front_page() gate) --
 * unlike home.css, which holds only genuine homepage CONTENT sections
 * (hero, choice, help, what's-happening, facility, impact, get-in-touch,
 * partners, the decorative footer strip) and remains body.home-only.
 *
 * History: this used to be four rule groups inside home.css, reachable
 * only on the front page. A prior, narrower pass (Food Map page-shell)
 * temporarily also matched them against a one-off body.hcfb-uses-home-
 * shell class for a single page (/food-insecurity/) -- that approach is
 * superseded by this file; every selector below was moved here, not
 * duplicated, and now serves every public template identically.
 *
 * See docs/HOMEPAGE_REDESIGN.md for the original per-rule rationale
 * (retained in the comments below) and
 * docs/FOOD_MAP_HOMEPAGE_INTEGRATION_CONTRACT.md for why the Food Map
 * page needed this in the first place.
 */

/* ------------------------------------------------------------------ */
/* Shared content-width framework                                      */
/*                                                                       */
/* One wide, centered outer measure for every public template's main    */
/* content area, matching the homepage header/footer's own inner        */
/* measure (--hcfb-home-wide, defined below) -- not theme.json's        */
/* narrower default wideSize (1200px). Plain running text (paragraphs/  */
/* lists inside Post Content) is intentionally left at theme.json's own */
/* contentSize (720px, unchanged, already narrower than this) for a     */
/* comfortable reading measure; visual modules, card grids, and query   */
/* loops explicitly opt into the full wide measure below.               */
/*                                                                       */
/* :not(.home) is deliberate and required, not decorative: body.home    */
/* (both the default homepage and the gated neighbor-journey homepage)  */
/* ALSO carries body.hcfb-public-shell (for the shared utility bar/     */
/* header row/mega-nav/footer below), but home.css/neighbor-journey.css */
/* already own #hcfb-primary-content's width there (full-bleed, no      */
/* padding, each homepage section manages its own measure). A prior     */
/* version of this rule had no exclusion; home.css's own override only  */
/* reset max-width/width, never padding-inline, so this rule's padding  */
/* silently leaked through and shrank every homepage full-bleed section */
/* by 2x its padding value -- a real, shipped regression, caught by     */
/* comparing hero width before/after. Excluding .home here keeps this   */
/* file from ever touching homepage content width again, structurally,  */
/* rather than relying on override order for a property this rule       */
/* should simply never set on that body class in the first place.       */
/* ------------------------------------------------------------------ */

body.hcfb-public-shell:not(.home) #hcfb-primary-content {
	max-width: var(--hcfb-home-wide);
	width: 100%;
	margin-inline: auto;
	padding-inline: var(--wp--preset--spacing--hcfb-lg, 2.5rem);
}

@media (max-width: 768px) {
	body.hcfb-public-shell:not(.home) #hcfb-primary-content {
		padding-inline: var(--wp--preset--spacing--hcfb-md, 1.5rem);
	}
}

@media (max-width: 480px) {
	body.hcfb-public-shell:not(.home) #hcfb-primary-content {
		padding-inline: var(--wp--preset--spacing--hcfb-sm, 1rem);
	}
}

/*
 * Query-loop / card-grid archives (search, 404's link list is plain
 * prose so it's unaffected, News/Events/Reports/category archives) sit
 * as a direct child of #hcfb-primary-content with no "wide" alignment
 * of their own, so they would otherwise inherit theme.json's narrower
 * 720px contentSize cap. Explicitly released to the same wide measure
 * as the outer shell -- this is the "archives and card grids may use
 * the full outer width" requirement. Shortcode-rendered content (e.g.
 * the Food Map's own [hcfb_food_map] output) already manages its own
 * width internally and needs no rule here. Same :not(.home) exclusion
 * as above, for the same reason -- the homepage has no wp:query blocks
 * today, but this keeps that guarantee structural, not incidental.
 */
body.hcfb-public-shell:not(.home) #hcfb-primary-content > .wp-block-query {
	max-width: none;
	width: 100%;
}

/*
 * Single-post reading measure (post-width refinement). templates/single.html
 * and templates/single-hcfb_event.html (the only two templates covering this
 * theme's three public post types -- post, hcfb_report, hcfb_event; all
 * other custom post types are 'public' => false and never reach body.single)
 * each give wp:post-content its own nested constrained layout, and leave
 * wp:post-title/wp:post-featured-image with no layout override of their
 * own -- so WordPress core's global-styles output caps all three
 * independently at theme.json's contentSize (720px), regardless of this
 * file's already-wide #hcfb-primary-content shell. That core-generated CSS
 * lives only in WordPress's runtime <style> output, not in any theme
 * stylesheet, so it cannot be edited directly -- this rule overrides its
 * effective result instead. Widens all three block types together, not
 * just post-content, so the title and featured image stay flush-aligned
 * with the body copy beneath them rather than appearing narrower than it.
 * Deliberately does not touch alignwide/alignfull children: both use their
 * own absolute (not container-relative) core rules keyed to wideSize/none,
 * so they are already unaffected by this container's own max-width.
 * !important is used because the specific core-generated rule this
 * overrides could not be inspected in a running environment to confirm
 * its own specificity/!important use; without it, this rule risks having
 * no visible effect at all if that generated rule does use !important.
 */
body.single #hcfb-primary-content .wp-block-post-title,
body.single #hcfb-primary-content .wp-block-post-featured-image,
body.single #hcfb-primary-content .wp-block-post-content {
	max-width: 820px !important;
}

/* ------------------------------------------------------------------ */
/* Single Press Release: readable, centered prose measure              */
/* ------------------------------------------------------------------ */
/*
 * Correction (2026-09-24, Ryan-directed). Measured cause at 1440px,
 * before this block: `.hcfb-release` -- the wrapper that the Press Room
 * plugin's [hcfb_press_room_release_body] shortcode outputs -- is a plain
 * child of the constrained <main>, so unlike wp-block-post-title /
 * -featured-image / -content (widened to 820px by the rule directly
 * above) WordPress core's global styles capped it at theme.json's 720px
 * contentSize. Inside that cap, the plugin's own `.hcfb-release__layout`
 * is a two-column grid -- `minmax(0, 1fr)` plus a FIXED 300px media-
 * resources sidebar, plus a gap of up to 72px -- sized for that plugin's
 * own ~1120px standalone template. 720px, less the layout's own 40px
 * inset, less 300px, less the gap, left the prose column 308px: about 33
 * characters per line. Verified by measuring the live page at 390/768/
 * 1024/1440px, not inferred.
 *
 * Explicitly NOT the staff-review control: hcfb-staff-review's "Review
 * this page" UI is entirely position:fixed, adds no padding or margin to
 * <body>/<html>, and its Frontend::gate() emits no markup, CSS or JS at
 * all unless the visitor is logged in AND holds hcfb_use_review_mode --
 * an anonymous response contains none of it. It therefore cannot reserve
 * article width. Confirmed both by reading that gate and by fetching this
 * page anonymously (zero staff-review references in the HTML).
 *
 * The correction keeps the established hierarchy -- headline (820px)
 * wider than the hero photo (780px), hero wider than the prose (46rem =
 * 736px) -- and stacks the media-resources card beneath the article at
 * the same measure instead of letting it take a third of the width. The
 * plugin's own stylesheet is deliberately left alone: the cap that caused
 * this is a theme-side concern (this file already owns the identical
 * override for the three core block types above), and the plugin's
 * standalone PHP template still wants its original two-column design.
 */
:root {
	--hcfb-release-measure: 46rem;
}

/* Escape core's generated 720px contentSize cap. !important for the same
 * reason the rule above uses it: the core-generated rule being overridden
 * lives only in WordPress's runtime <style> output and its own
 * specificity/!important use cannot be inspected from a stylesheet. */
body.single #hcfb-primary-content .hcfb-release,
body.single #hcfb-primary-content .hcfb-related-content {
	max-width: 820px !important;
}

/* Stack, don't sidebar: the article keeps the full measure and the media
 * resources card follows beneath it. `display: block` also makes the
 * plugin's own grid-template-columns (including its <=920px single-column
 * override) inert here, so there is one behaviour at every width. */
body.single #hcfb-primary-content .hcfb-release .hcfb-release__layout {
	display: block;
}

body.single #hcfb-primary-content .hcfb-release .hcfb-release__content,
body.single #hcfb-primary-content .hcfb-release .hcfb-release__resources,
body.single #hcfb-primary-content .hcfb-related-content {
	width: min(100%, var(--hcfb-release-measure));
	margin-inline: auto;
}

/* Replaces the grid gap the stacked layout no longer provides. */
body.single #hcfb-primary-content .hcfb-release .hcfb-release__resources {
	margin-top: clamp(34px, 6vw, 72px);
}

/* No longer a column beside the article, so it must not stick. */
body.single #hcfb-primary-content .hcfb-release .hcfb-resource-card {
	position: static;
}

/*
 * Typography note (deliberate, flag for review): a 46rem measure and the
 * requested 60-75 characters per line are only simultaneously achievable
 * at a body size of roughly 1.25-1.3rem. The plugin's own
 * clamp(1.06rem, 1.4vw, 1.18rem) was sized for its narrower original
 * column and measured 78 characters per line at 1440px and 96 at 1024px
 * once the prose was widened -- 1.4vw falls below the 1.06rem floor
 * around 1024px, so the text shrank exactly where the measure grew. This
 * raises the floor and the ceiling so the measured count stays inside the
 * requested band at every tested width, without touching the plugin's own
 * stylesheet or any release content. Revert this single rule if the
 * larger body text is not wanted; the width/centering corrections above
 * stand on their own.
 */
body.single #hcfb-primary-content .hcfb-release .hcfb-release__article {
	font-size: clamp(1.2rem, 1.3vw + 0.5rem, 1.3rem);
}

/* Shared "wide" inner/outer measure -- matches the approved design
 * reference's generous ~1320px editorial column, wider than theme.json's
 * default 1200px wideSize. Used by the homepage's own full-bleed bands
 * (home.css) and by every public template's shared shell below. */
:root {
	--hcfb-home-wide: 82rem;
}

body.hcfb-public-shell .hcfb-site-header--home *,
body.hcfb-public-shell .hcfb-site-footer--home * {
	box-sizing: border-box;
}

/* ------------------------------------------------------------------ */
/* Shared header shell (utility bar, header row)                       */
/* ------------------------------------------------------------------ */

body.hcfb-public-shell .hcfb-utility-bar--navy {
	background: var(--wp--preset--color--hcfb-navy);
	border-bottom-color: var(--wp--preset--color--hcfb-navy);
	/*
	 * Typography/spacing refinement pass: raised from 0.25rem (a too-thin
	 * "line" rather than a comfortable bar, per this pass's brief) to a
	 * compact-but-comfortable strip -- still clearly slimmer than the
	 * shared cream utility bar (style.css), just no longer cramped.
	 */
	padding-top: 0.65rem;
	padding-bottom: 0.65rem;
}

/*
 * Pass 5B fix (read-only audit finding): .hcfb-utility-bar is a direct
 * child of the header's default theme.json "constrained" layout, which
 * caps unexempted direct children at --wp--style--global--content-size
 * (720px), centered -- so the navy background itself was capped to a
 * narrow centered box instead of spanning the viewport. One section
 * down, .hcfb-header-row--home already carries the exact release+
 * recenter this bar was missing; this mirrors that proven pattern rather
 * than inventing a new one. Two rules, same split as that sibling:
 * outer bar released to full width (background spans edge-to-edge),
 * inner wrapper (.hcfb-utility-bar__inner, parts/header-home.html) given
 * its own centered max-width and responsive inline padding so the
 * content -- not the background -- is what stays a comfortable, fluid
 * measure.
 */
body.hcfb-public-shell .hcfb-utility-bar {
	max-width: none;
	width: 100%;
}

body.hcfb-public-shell .hcfb-utility-bar__inner {
	max-width: var(--hcfb-home-wide);
	width: 100%;
	margin: 0 auto;
	padding-inline: var(--wp--preset--spacing--hcfb-md);
	align-items: center;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-links {
	gap: 1.5rem;
	align-items: center;
}

/*
 * Typography/spacing refinement pass: font-size raised from 0.7rem
 * (11.2px, confirmed too small against the approved reference) to 0.9rem
 * (14.4px, inside the requested ~14-15px desktop range). Weight raised
 * from the inherited default (400) to 600 -- the same "semibold nav text"
 * weight this header's own mega-nav links/tabs already use (see
 * `.hcfb-mega-nav__link, .hcfb-mega-nav__tab` above), not a new value
 * invented for this component. `font-family` is NOT set here: these are
 * plain `<a>` elements, which inherit the theme's configured Montserrat-
 * oriented stack (theme.json's `--wp--preset--font-family--hcfb-body`)
 * from `body` by default -- confirmed via computed-style inspection
 * (`getComputedStyle(...).fontFamily` reported the correct stack, not a
 * browser default), so no explicit rule is needed here. `text-decoration:
 * none` removes the permanent underline (scoped to this bar only --
 * site-wide link underlining, e.g. the footer, is untouched); the
 * `:focus-visible` outline below is untouched by this and remains the
 * distinct, always-visible keyboard indicator (style.css's global
 * `a:focus-visible { outline: 3px solid ... }` rule, swapped to white by
 * the rule directly below this one).
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link,
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link a,
body.hcfb-public-shell .hcfb-utility-bar--navy .wp-block-search__label {
	color: var(--wp--preset--color--hcfb-surface);
	font-size: 0.9rem;
	font-weight: 600;
	letter-spacing: 0.01em;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link a,
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-phone {
	text-decoration: none;
	transition: opacity 0.15s ease;
}

/*
 * Restrained hover treatment: reduced opacity only -- a plain color-shift/
 * border-bottom was tried first but visually collided with the vertical
 * separators between the three text links (bottom + left/right borders
 * together read as a boxed button rather than a link hover). Opacity
 * alone reads cleanly next to those separators at every position (first,
 * middle, last link) and needs no reserved border space, so it can never
 * shift layout on hover either.
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link a:hover,
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-phone:hover {
	opacity: 0.75;
}

body.hcfb-public-shell .hcfb-utility-bar--navy :focus-visible {
	outline-color: var(--wp--preset--color--hcfb-surface);
}

/*
 * Utility Bar pass: right-hand group layout. `.hcfb-utility-bar__inner`
 * (space-between, set above) puts the phone group on the left and this
 * whole group on the right; this inner row keeps the three text links
 * and the search control together with generous, restrained spacing
 * between the two clusters (not stretched to space-between itself --
 * that would push the search icon away from Agency Partner Portal,
 * contradicting the approved "search sits immediately after" direction).
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__actions {
	align-items: center;
	gap: 1.75rem;
}

/*
 * Slim vertical separators between the three text links only -- expressed
 * as padding + border on each link after the first (not the shared
 * `.hcfb-utility-links` gap above, which this group overrides to 0) so the
 * separator sits at the visual midpoint between two links rather than
 * doubling up with flex gap. The search icon is a sibling of this whole
 * group (see `.hcfb-utility-bar__actions` above), not a fourth child
 * here, so it never inherits a leading separator of its own.
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links {
	gap: 0;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links .hcfb-utility-link {
	margin: 0;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links .hcfb-utility-link a {
	display: inline-block;
	padding: 0.35rem 1.5rem 0.35rem 0;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links .hcfb-utility-link:not(:first-child) {
	border-left: 1px solid rgba(255, 255, 255, 0.35);
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links .hcfb-utility-link:not(:first-child) a {
	padding-left: 1.5rem;
}

/*
 * Icon-only search toggle. Hidden by default (no JS) so a no-JS visitor
 * never sees an inert button -- assets/js/hcfb-interactive.js adds
 * `.is-enhanced` to `.hcfb-utility-search` once it has wired the toggle,
 * the same "hidden until enhanced" convention already used by
 * `.hcfb-mega-nav__mobile-trigger` above. Without that class, the search
 * block below renders in normal flow, fully visible and independently
 * operable -- a complete, working no-JavaScript search form on its own.
 * Sized to match the phone icon (18x18, see parts/header-home.html) for
 * the approved "visually balanced with the phone icon" direction.
 */
body.hcfb-public-shell .hcfb-utility-search {
	position: relative;
	display: inline-flex;
	align-items: center;
}

/*
 * Typography fix (confirmed via computed-style inspection, not assumed):
 * a plain `<button>` does not inherit `font-family` from the page by
 * default in any browser -- unlike this bar's `<a>` elements (which do
 * inherit) and the core Search block's own `<input>`/`<button>` (which
 * WordPress's own generated base styles already normalize to inherit),
 * this custom button had no such rule and measured `font-family: Arial`
 * (a browser UA default) instead of the theme's configured Montserrat-
 * oriented stack. Since this button has no visible text (icon-only, with
 * an aria-label), the bug had no visible symptom -- `font-family: inherit`
 * corrects it for any future text/tooltip and for consistency, without
 * loading a second font or changing the shared stack itself.
 */
body.hcfb-public-shell .hcfb-utility-search__toggle {
	display: none;
	align-items: center;
	justify-content: center;
	background: none;
	border: 0;
	margin: 0;
	padding: 0.4rem;
	border-radius: 999px;
	color: var(--wp--preset--color--hcfb-surface);
	font-family: inherit;
	cursor: pointer;
}

body.hcfb-public-shell .hcfb-utility-search.is-enhanced .hcfb-utility-search__toggle {
	display: inline-flex;
}

body.hcfb-public-shell .hcfb-utility-search__toggle:hover {
	background: rgba(255, 255, 255, 0.14);
}

/*
 * Once enhanced, the panel becomes a hidden-until-opened dropdown so no
 * boxed field shows by default -- anchored to this control's own right
 * edge (not the whole utility bar) so it stays visually attached to the
 * icon that opened it regardless of how many utility links sit to its
 * left. Unenhanced (no JS), no positioning applies here at all -- the
 * search block simply sits in normal flow exactly where it already was
 * before this pass, immediately after the three text links.
 */
body.hcfb-public-shell .hcfb-utility-search.is-enhanced .hcfb-utility-search__panel {
	position: absolute;
	top: 100%;
	right: 0;
	margin-top: 0.6rem;
	display: none;
	z-index: 30;
	background: var(--wp--preset--color--hcfb-navy);
	padding: 0.6rem;
	border-radius: 0.6rem;
	box-shadow: 0 12px 28px rgba(10, 12, 40, 0.28);
	width: min(20rem, calc(100vw - 2 * var(--wp--preset--spacing--hcfb-md, 1.5rem)));
}

body.hcfb-public-shell .hcfb-utility-search.is-enhanced .hcfb-utility-search__panel.is-open {
	display: block;
}

/*
 * Compact search affordance -- a small field, not a large centered one.
 * Narrowed further in pass 3 to read closer to the reference's icon-sized
 * affordance while keeping a real, natively-operable <input>/<button>
 * pair (native keyboard/tab behavior is unaffected by the show/hide
 * wrapper above -- that only toggles the ANCESTOR panel's visibility).
 *
 * Widened 36px (8.5rem -> calc(8.5rem + 36px), ~172px) per the approved
 * homepage search-widening pass. That approval originally shipped as a
 * neighbor-journey.css override scoped to body.home.hcfb-neighbor-preview
 * only (the gated alternate-homepage preview), because at the time this
 * base rule lived in home.css and was reachable only on the front page.
 * Now that this rule is the shared public-header default for every page
 * using this shell, the approved width belongs here directly -- this is
 * the correct ownership layer, not a higher-specificity patch on top of
 * it. Only the <input> grows (the core search block's own CSS gives it
 * flex-grow:1 inside .wp-block-search__inside-wrapper); the <button>
 * keeps its own explicit height/padding/font-size below, untouched, so
 * its proportions are unaffected.
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-header-search.wp-block-search {
	max-width: calc(8.5rem + 36px);
}

body.hcfb-public-shell .hcfb-utility-bar--navy .wp-block-search__input {
	height: 1.75rem;
	padding: 0.15rem 0.55rem;
	font-size: 0.8rem;
	border-color: transparent;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .wp-block-search__button {
	height: 1.75rem;
	padding: 0 0.6rem;
	font-size: 0.75rem;
}

/*
 * Utility Bar pass: below the same <=1199px width where the primary
 * mega-navigation itself switches into its mobile disclosure menu
 * (public-shell.css's existing `.hcfb-mega-nav` breakpoint, reused here
 * rather than inventing a second one), the three utility text links no
 * longer have comfortable room next to the now-longer approved labels
 * (Manage My Monthly Giving / Volunteer Login / Agency Partner Portal
 * are substantially longer than the previous Find Food / Volunteer /
 * Donor Portal trio). Rather than shrinking that text further or letting
 * the bar wrap into misaligned rows, they move into the existing
 * accessible mobile navigation body instead (see
 * `.hcfb-mega-nav__utility` below) -- this is the same existing mobile
 * menu, not a second one. The phone number and the search control both
 * stay in the utility bar at every width, matching the approved
 * direction to always preserve phone and search access.
 */
@media (max-width: 1199px) {
	body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__nav-links {
		display: none;
	}
}

/*
 * style.css carries a generic, unscoped `@media (max-width: 782px) {
 * .hcfb-utility-bar .wp-block-group { flex-direction: column } }` fallback
 * for the now-orphaned plain header/footer parts (see that file). It
 * unavoidably also matches this navy bar's own `.wp-block-group` children
 * (`.hcfb-utility-bar__phone`, `.hcfb-utility-bar__actions`), which would
 * otherwise stack the phone group above the search control instead of
 * keeping them on one row. This body.hcfb-public-shell-scoped override
 * (higher specificity than the plain rule, so it always wins regardless
 * of source order) restores a single row -- with only the phone group and
 * the search control left at this width (the nav-links group is hidden
 * above), a single row fits comfortably all the way down to 320px.
 */
@media (max-width: 782px) {
	body.hcfb-public-shell .hcfb-utility-bar--navy .wp-block-group {
		flex-direction: row;
		align-items: center;
	}
}

@media (max-width: 480px) {
	body.hcfb-public-shell .hcfb-utility-bar--navy {
		padding-top: 0.4rem;
		padding-bottom: 0.4rem;
	}
	/*
	 * Touch-target floor at the narrowest widths: the phone link's text is
	 * small (0.7rem), so the anchor gets its own vertical padding rather
	 * than relying on line-height alone.
	 */
	body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-bar__phone .hcfb-utility-link a {
		display: inline-flex;
		padding: 0.35rem 0.15rem;
	}
	body.hcfb-public-shell .hcfb-utility-search.is-enhanced .hcfb-utility-search__panel {
		width: min(17rem, calc(100vw - 2 * var(--wp--preset--spacing--hcfb-sm, 1rem)));
	}
}

/*
 * Utility Bar phone number: icon + number as one inline unit, one line,
 * vertically centered -- rejected in an earlier pass when the icon had no
 * inline width/height/stroke attributes of its own and relied entirely on
 * this stylesheet for size and color; that made it fall back to the
 * browser's default (much larger, solid black) SVG rendering. The icon in
 * parts/header-home.html now carries its own width="18" height="18"
 * stroke="currentColor" attributes, so it is correctly sized and colored
 * even before this rule runs -- these two rules only add inline layout
 * (gap, vertical centering) on top of that, they are not the only thing
 * standing between the icon and a giant black glyph.
 *
 * Selector includes the .hcfb-utility-link ancestor (not just
 * .hcfb-utility-phone) so its specificity beats the <=480px block above's
 * `.hcfb-utility-bar--navy .hcfb-utility-bar__phone .hcfb-utility-link a
 * { display: inline-flex }` rule -- without that extra class this lost
 * the specificity tie at narrow widths, silently falling back to
 * inline-block/inline-flex and baseline (not center) alignment between
 * the icon and the number.
 */
body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link .hcfb-utility-phone {
	display: inline-flex;
	align-items: center;
	gap: 8px;
	line-height: 1;
	white-space: nowrap;
}

body.hcfb-public-shell .hcfb-utility-bar--navy .hcfb-utility-link .hcfb-utility-phone svg {
	flex-shrink: 0;
}

/*
 * Pass 3 (fidelity pass 3, §3): the reference's header row is proportionally
 * shorter than this row was even after pass 2 -- a bigger logo mark, tighter
 * vertical padding, and wider (not denser) horizontal gaps between logo/nav/
 * donate together read as "shorter header, simpler nav" without removing any
 * real navigation item (the reference's own IA, fewer top-level links than
 * this site's real structure, cannot be invented -- see
 * docs/HEADER_NAVIGATION_DECISIONS.md).
 */
body.hcfb-public-shell .hcfb-header-row--home {
	position: relative;
	max-width: var(--hcfb-home-wide);
	margin: 0 auto;
	width: 100%;
	/* Global readability/header-density refinement, revised pass
	 * (2026-09-02): the first version's 0.45rem -> 0.6rem bump was too
	 * small to actually read as stronger -- 0.9rem is the real, visibly
	 * more substantial white primary nav bar this pass calls for.
	 * Horizontal padding and layout mechanics unchanged; the logo grows
	 * modestly below to stay balanced against the taller row. */
	/* Local refinement (2026-09-02): 0.9rem -> 1.05rem, a modest further
	 * increase Ryan asked for -- visible without becoming oversized. */
	/* Final modest increase (2026-09-02): 1.05rem -> 1.125rem. */
	padding: 1.125rem var(--wp--preset--spacing--hcfb-md) 1.125rem var(--wp--preset--spacing--hcfb-md);
	align-items: center;
	column-gap: var(--wp--preset--spacing--hcfb-xl);
}

/* Pass 4 (§12): larger still -- was 74px (pass 3). Only applies below the
 * >=1200px breakpoint further down, which sets its own smaller logo size
 * for the true-centered wide-desktop nav (source order makes the later,
 * more specific-width rule win at 1200px and up). */
@media (min-width: 783px) {
	body.hcfb-public-shell .hcfb-header-row--home .hcfb-logo--horizontal {
		/* Global readability pass: modest ~7% increase (86px -> 92px) to
		 * stay balanced against the taller header row above. */
		height: 92px;
	}
}

/*
 * Visual-refinement pass, wide desktop (>=1200px) only: the previous
 * page-true-center approach (`position: absolute; left: 50%; transform:
 * translate(-50%, -50%)`) measured exactly 0px off the row's own center,
 * but centering against the WHOLE row reads as unbalanced whenever the
 * logo and the CTA are very different widths (325px-ish logo vs ~124px
 * button) -- the nav ends up sitting close to the wider side (logo) and
 * far from the narrower one (CTA), which is exactly the "excessive space
 * before Make a Gift" complaint this pass fixes. A three-column grid
 * with fixed-to-content outer tracks (`auto`) for the logo and the CTA
 * and one flexible middle track (`minmax(0, 1fr)`) for the nav instead
 * centers the nav within the LEFTOVER region between logo and CTA --
 * confirmed via direct measurement to produce a symmetric gap on both
 * sides of the nav (not a symmetric gap from the row's own edges), which
 * is what actually reads as balanced. `justify-self: center` centers the
 * nav inside that one flexible track; the two `auto` tracks size exactly
 * to the logo's and the CTA's own content, so this doesn't have the
 * earlier grid attempt's `1fr`-vs-`1fr` asymmetric-growth problem (see
 * docs/HEADER_NAVIGATION_DECISIONS.md) -- there's only one flexible
 * track here, not two competing ones.
 */
@media (min-width: 1200px) {
	body.hcfb-public-shell .hcfb-header-row--home {
		display: grid;
		grid-template-columns: auto minmax(0, 1fr) auto;
		align-items: center;
	}

	body.hcfb-public-shell .hcfb-header-row--home .hcfb-logo--horizontal {
		/* Global readability pass: modest ~7% increase (72px -> 77px). */
		height: 77px;
	}

	body.hcfb-public-shell .hcfb-header-row--home .hcfb-mega-nav {
		justify-self: center;
		align-self: center;
		margin-left: 0;
	}
}

/*
 * Primary-nav pass: "Make a Gift" (formerly "Donate"). Background/text
 * colors come from the block's own has-hcfb-orange-background-color /
 * has-hcfb-navy-color classes (parts/header-home.html) -- approved
 * existing tokens, not a new hardcoded hex. min-height guarantees the
 * required 44px interactive target regardless of font metrics (0.45rem
 * padding alone does not reliably clear 44px at this font-size); the pill
 * radius (style.css's shared `.wp-block-button__link { border-radius:
 * 999px }`) and the sitewide `:focus-visible` outline (style.css) are
 * both unaffected by anything here.
 */
body.hcfb-public-shell .hcfb-donate-action .wp-block-button__link {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	/* Global readability pass: 44px -> 48px, comfortable padding to match. */
	min-height: 48px;
	padding: 0.6rem 1.4rem;
	font-size: 1rem;
	transition: filter 0.15s ease;
}

/*
 * Accessible hover/active feedback: theme.json's generic button element
 * style sets a navy `:hover` background site-wide, which would otherwise
 * silently override this button's orange background on hover (and leave
 * navy-on-navy text). `filter: brightness()` darkens the existing orange
 * itself rather than introducing a second color value, satisfying "do
 * not hard-code a new orange."
 */
body.hcfb-public-shell .hcfb-donate-action .wp-block-button__link:hover,
body.hcfb-public-shell .hcfb-donate-action .wp-block-button__link:focus-visible {
	background: var(--wp--preset--color--hcfb-orange);
	filter: brightness(0.92);
}

body.hcfb-public-shell .hcfb-donate-action .wp-block-button__link:active {
	background: var(--wp--preset--color--hcfb-orange);
	filter: brightness(0.85);
}

/*
 * Header nav visual-iteration pass: Find Food / Volunteer / Make a Gift
 * as one tiered action cluster, not three equally-weighted buttons.
 * Make a Gift (.hcfb-donate-action, above) is untouched -- still the
 * strongest, only orange-filled CTA. A tighter column-gap than
 * wp-block-buttons' own default keeps three buttons from reading as
 * loose/disconnected -- deliberately less space than sits between the
 * nav tabs and this cluster (column-gap on .hcfb-header-row--home,
 * unchanged), so the three still read as one grouped cluster.
 */
body.hcfb-public-shell .hcfb-header-actions {
	/* Final modest increase (2026-09-02): 0.65rem -> 0.9rem (~14.4px). */
	column-gap: 0.9rem;
	align-items: center;
	flex-wrap: nowrap;
}

/*
 * Find Food + Volunteer (2026-09-02, Ryan-directed reorder/recolor):
 * both filled HCFB green, navy text -- measured 6.64:1, comfortably
 * passing WCAG AA (white on this green measures only 2.05:1, well
 * under 4.5:1, confirming this codebase's own existing "navy on the two
 * lighter brand colors" contrast pairing rather than a new unapproved
 * darker green). Consistent filled treatment for both (no outline/
 * transparent tier anymore); Make a Gift (orange, below) stays the one
 * visually distinct strongest CTA.
 */
body.hcfb-public-shell .hcfb-header-actions__find-food .wp-block-button__link,
body.hcfb-public-shell .hcfb-header-actions__volunteer .wp-block-button__link {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	min-height: 47px;
	padding: 0.55rem 1.2rem;
	font-size: 0.9375rem;
	background: var(--wp--preset--color--hcfb-green);
	color: var(--wp--preset--color--hcfb-navy);
	border: 0;
	transition: filter 0.15s ease;
}

body.hcfb-public-shell .hcfb-header-actions__find-food .wp-block-button__link:hover,
body.hcfb-public-shell .hcfb-header-actions__find-food .wp-block-button__link:focus-visible,
body.hcfb-public-shell .hcfb-header-actions__volunteer .wp-block-button__link:hover,
body.hcfb-public-shell .hcfb-header-actions__volunteer .wp-block-button__link:focus-visible {
	background: var(--wp--preset--color--hcfb-green);
	color: var(--wp--preset--color--hcfb-navy);
	filter: brightness(0.92);
}


/* ------------------------------------------------------------------ */
/* Shared mega-navigation: accessible tabbed desktop nav + mobile menu */
/*                                                                      */
/* Replaces the previous plain core/navigation block (.hcfb-primary-nav,*/
/* flat links, no children -- docs/HEADER_NAVIGATION_DECISIONS.md).     */
/* Markup ships every child link visible in normal flow (no `hidden`    */
/* attribute rendered server-side -- see inc/template-tags.php's        */
/* hcfb_mega_nav shortcode) so the whole thing works with JavaScript    */
/* disabled: a plain, fully expanded, keyboard-reachable link list.     */
/* Everything below that hides/positions panels is scoped under         */
/* .hcfb-mega-nav.is-enhanced, a class assets/js/hcfb-interactive.js    */
/* adds only once it has actually run and taken over -- so a no-JS      */
/* visitor never sees CSS meant for the JS-driven interactive state.    */
/* ------------------------------------------------------------------ */

body.hcfb-public-shell .hcfb-mega-nav {
	position: relative;
	margin-left: auto;
}

/*
 * font-family: inherit is required here -- unlike the anchor-styled
 * "Make a Gift" CTA and the utility links (plain <a> tags, which inherit
 * the body's Montserrat stack automatically), this is a real <button>
 * element, and browsers' default UA stylesheet does not inherit
 * font-family onto form controls. Without this, the button silently
 * renders in the browser's own default control font (confirmed Arial)
 * instead of the theme's type system.
 */
body.hcfb-public-shell .hcfb-mega-nav__mobile-trigger {
	display: none;
	align-items: center;
	gap: 0.5rem;
	background: none;
	border: 0;
	padding: 0.5rem 0.4rem;
	cursor: pointer;
	color: var(--wp--preset--color--hcfb-navy);
	font-family: inherit;
	font-weight: 600;
	font-size: 0.9rem;
}

body.hcfb-public-shell .hcfb-mega-nav__hamburger {
	display: inline-flex;
	flex-direction: column;
	justify-content: center;
	gap: 4px;
	width: 22px;
}

body.hcfb-public-shell .hcfb-mega-nav__hamburger span {
	display: block;
	height: 2px;
	background: currentColor;
	border-radius: 1px;
	transition: transform 0.15s ease, opacity 0.15s ease;
}

/*
 * Header nav visual-iteration pass: open state ("Close") morphs the same
 * three bars into an X rather than introducing a second icon -- "the
 * existing hamburger treatment," per direct instruction. translateY
 * distance (6px) is this icon's own span height (2px) + gap (4px), so
 * the two outer bars pivot exactly through the middle bar's vacated
 * center once it fades out.
 */
body.hcfb-public-shell .hcfb-mega-nav__mobile-trigger[aria-expanded="true"] .hcfb-mega-nav__hamburger span:nth-child(1) {
	transform: translateY(6px) rotate(45deg);
}

body.hcfb-public-shell .hcfb-mega-nav__mobile-trigger[aria-expanded="true"] .hcfb-mega-nav__hamburger span:nth-child(2) {
	opacity: 0;
}

body.hcfb-public-shell .hcfb-mega-nav__mobile-trigger[aria-expanded="true"] .hcfb-mega-nav__hamburger span:nth-child(3) {
	transform: translateY(-6px) rotate(-45deg);
}

@media (prefers-reduced-motion: reduce) {
	body.hcfb-public-shell .hcfb-mega-nav__hamburger span {
		transition: none;
	}
}

/*
 * Pass 6B root-cause fix: the shared panel used to anchor to
 * `.hcfb-mega-nav` (the whole nav element, `right: 0`) -- at narrower
 * desktop widths the tab-list itself doesn't span the nav's full width
 * evenly, so anchoring to the nav's own right edge left the panel
 * visually disconnected from a tab like Find Food on the left. Making
 * THIS element (the actual five-tab wrapper, not the whole nav) the
 * positioning context, and centering the shared panel under it, is what
 * keeps the panel visually connected to the tab group regardless of
 * which tab is active -- see the panel rule below.
 */
/*
 * Breakpoint-based header pass: gap tightened from hcfb-lg (40px) to
 * hcfb-md (24px). This only ever renders at >=1200px -- the <=1199px
 * block further down fully overrides `gap` (to 0, in its own stacked
 * accordion layout) -- and it's part of what makes true nav centering at
 * 1200px geometrically possible without the tab labels feeling cramped
 * (font-size/weight untouched, only the gap between tabs is smaller).
 */
body.hcfb-public-shell .hcfb-mega-nav__list {
	position: relative;
	display: flex;
	align-items: center;
	/*
	 * Header nav visual-iteration pass (1200px fit): tightened from
	 * hcfb-md (24px) to hcfb-sm (16px) so the four now-longer-relative-to-
	 * space labels (Give Help / Our Impact / About / News & Resources) fit
	 * on one line at 1200px without wrapping -- font-size/weight
	 * untouched, only inter-tab spacing.
	 */
	gap: var(--wp--preset--spacing--hcfb-sm);
	list-style: none;
	margin: 0;
	padding: 0;
}

/*
 * Local refinement (2026-09-02, Ryan-directed): more breathing room
 * between the four tab labels at spacious widths (Ryan's own ~1534px
 * screenshot) -- wide-screen-only, so the tight 1200px fit (validated
 * down to a 12.6px nav/action safety gap) is completely untouched.
 * hcfb-md (24px) is the ORIGINAL, pre-1200px-fit-pass gap value (see
 * comment above) restored here at widths that always had the room for
 * it. 1400px leaves a 200px buffer past the 1200px fit itself, well
 * clear of that tight range.
 */
@media (min-width: 1400px) {
	body.hcfb-public-shell .hcfb-mega-nav__list {
		/* Final modest increase (2026-09-02): 24px -> 28px. */
		gap: 1.75rem;
	}
}

/*
 * Visual-refinement pass: root cause of the nav text reading "slightly
 * high" against the logo/CTA. Each `<li>` measured ~16px taller than the
 * `.hcfb-mega-nav__tab` button actually inside it (confirmed via direct
 * measurement, not assumed) -- `align-items: center` on the list above
 * only centers each LI as a whole within the row, it does not center
 * that LI's own children within the LI's own (taller) box. Making the LI
 * itself a flex container with its own `align-items: center` centers the
 * button inside it instead of leaving it flush against the LI's top
 * edge, which was the actual defect -- not a font-metrics/line-height
 * issue.
 */
body.hcfb-public-shell .hcfb-mega-nav__item {
	display: flex;
	align-items: center;
}

/*
 * Breakpoint-based header pass: horizontal padding tightened from 0.5rem
 * to 0.35rem per side -- same reasoning as the list gap above (only ever
 * visible at >=1200px; fully overridden below 1200px). Vertical padding,
 * font-size, and font-weight are all unchanged.
 */
/*
 * font-family: inherit is required for `.hcfb-mega-nav__tab` (a real
 * <button> -- browsers' UA stylesheet does not inherit font-family onto
 * form controls, confirmed rendering Arial instead of the theme's
 * Montserrat stack without this). Harmless no-op for `.hcfb-mega-nav__link`
 * (a plain <a>, which already inherits normally).
 */
body.hcfb-public-shell .hcfb-mega-nav__link,
body.hcfb-public-shell .hcfb-mega-nav__tab {
	font-family: inherit;
	/* Global readability/header-density refinement, revised pass
	 * (2026-09-02): 600 -> 700 (Montserrat Bold, already loaded for
	 * headings -- no new weight/file), and 1rem -> 1.0625rem (17px), the
	 * approved target -- the first pass's 0.95rem->1rem change was too
	 * small to read as stronger. */
	font-weight: 700;
	font-size: 1.0625rem;
	color: var(--wp--preset--color--hcfb-navy);
	text-decoration: none;
	background: none;
	border: 0;
	cursor: pointer;
	display: inline-flex;
	align-items: center;
	min-height: 46px;
	line-height: 1.2;
	/*
	 * Global readability/header-density refinement, revised pass
	 * (2026-09-02): 0.3rem -> 0.55rem per side -- the first pass's bump
	 * from the original 0.2rem was still too tight to stop tabs feeling
	 * crowded at the larger 17px/700-weight size. Re-verified at
	 * 1200-1439px (the exact range this rule targets) with the local
	 * stack; see the >=1200px letter-spacing/padding trim further down
	 * for the one additional adjustment this required to keep a single
	 * clean row instead of wrapping.
	 */
	padding: 0.7rem 0.22rem;
	white-space: nowrap;
	border-radius: 6px 6px 0 0;
}

/*
 * Pass 6A: the downward triangle caret on desktop top-level tabs read as
 * visually out of place against the supplied reference (user feedback:
 * "the arrows in the desktop navigation do not belong visually") --
 * removed for desktop. The caret element itself, and the mobile
 * accordion's use of it as an expand/collapse affordance, stays --
 * removing it there too would take away mobile's only visual cue for
 * "this row expands," with nothing replacing it. Hidden here (desktop
 * default) and explicitly re-shown inside the mobile media query below.
 * No `gap` on the tab/link rule above is needed to reserve space for it
 * any more -- `display:none` removes it from flex layout entirely, so no
 * extra icon spacing survives on desktop.
 */
body.hcfb-public-shell .hcfb-mega-nav__caret {
	display: none;
}

/* Active top-level tab: navy background, white text -- the sole active-
 * state signal on desktop now that the caret is gone (required). */
body.hcfb-public-shell .hcfb-mega-nav__tab[aria-expanded='true'] {
	background: var(--wp--preset--color--hcfb-navy);
	color: var(--wp--preset--color--hcfb-surface);
}

body.hcfb-public-shell .hcfb-mega-nav__link:hover,
body.hcfb-public-shell .hcfb-mega-nav__link:focus-visible {
	color: var(--wp--preset--color--hcfb-green);
}

/* Desktop mega panel: one large white panel beneath the nav row, sitting
 * above the hero rather than pushing it down (position: absolute takes
 * it out of normal flow entirely). Restrained shadow, no border --
 * "simple editorial styling," per this pass's brief. */
body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__panel {
	position: absolute;
	top: 100%;
	/* Centered under the tab-list wrapper (its positioned ancestor, set
	 * above) rather than right-anchored to the whole nav -- identical for
	 * every tab, so the panel never "jumps" and always reads as directly
	 * below the five-tab group as a whole, not any one tab. */
	left: 50%;
	transform: translateX(-50%);
	width: min(46rem, calc(100vw - 2rem));
	max-width: 46rem;
	background: var(--wp--preset--color--hcfb-surface);
	box-shadow: 0 18px 40px rgba(20, 21, 60, 0.16);
	border-radius: 0 0 10px 10px;
	z-index: 40;
}

body.hcfb-public-shell .hcfb-mega-nav__panel-inner {
	display: grid;
	grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
	gap: var(--wp--preset--spacing--hcfb-xl);
	padding: var(--wp--preset--spacing--hcfb-lg);
}

/*
 * Pass 6A root-cause fix: this rule used to give text-only panels (no
 * media column -- Find Food, About, News & Resources) a narrower outer
 * box than image panels (Give Help, Our Impact). Every panel shares the
 * same `right: 0` anchor above, so a narrower panel's LEFT edge lands in
 * a different place than a wider one's -- confirmed via live measurement
 * that Find Food's panel (previously 320px wide) rendered flush against
 * the panels for About/News & Resources on the right side of the row,
 * nowhere near the Find Food tab itself on the left. User-reported ("the
 * Find Food navigation panel is not appearing in the correct position")
 * and reproduced directly. Every panel must share identical outer
 * geometry regardless of content -- removed the width override entirely
 * rather than adding a one-off correction for Find Food specifically;
 * text-only panels now use the exact same outer box as image panels, a
 * single-column grid (below) simply leaves the second column empty
 * instead of occupying a whole separate, narrower panel shell.
 */
body.hcfb-public-shell .hcfb-mega-nav__panel-inner:has(> .hcfb-mega-nav__panel-links:only-child) {
	grid-template-columns: minmax(0, 1fr);
}

/*
 * Pass 6B: text-only panels (Find Food, About, News & Resources) share
 * the same full outer panel width as image panels (Give Help, Our
 * Impact) -- correct, per Pass 6A's fix -- but a single flex-column list
 * of only 4-5 short links left a large, visually unbalanced empty right
 * half. No approved local image exists for any of these three specific
 * categories (the remaining supplied photos are about people/facilities,
 * not "finding food," "about us," or "news"), so a balanced two-column
 * link layout is this pass's explicit fallback instead of forcing an
 * unrelated image in just to fill space. `column-count` (not a CSS grid
 * with `grid-auto-flow: column`) is deliberate: it flows top-to-bottom
 * within the first column before continuing into the second, which
 * matches the underlying DOM/tab order exactly -- a grid's column-flow
 * would visually reorder items in a way that no longer matches the order
 * a keyboard/screen-reader user actually reaches them in.
 */
body.hcfb-public-shell .hcfb-mega-nav__panel-inner:has(> .hcfb-mega-nav__panel-links:only-child) .hcfb-mega-nav__panel-links {
	/* `column-count` has no effect on a flex container -- `display:block`
	 * is required to switch this list from the base flex-column rule
	 * (below) into an actual CSS multi-column layout. */
	display: block;
	column-count: 2;
	column-gap: var(--wp--preset--spacing--hcfb-xl, 3rem);
}

/* This two-link panel is intentionally a vertical sequence: Events first,
 * then News. The generic two-column balancing above is for longer lists. */
body.hcfb-public-shell #hcfb-mega-panel-whats-happening .hcfb-mega-nav__panel-links {
	column-count: 1;
}

body.hcfb-public-shell .hcfb-mega-nav__panel-links {
	list-style: none;
	margin: 0;
	padding: 0;
	display: flex;
	flex-direction: column;
	gap: 0.15rem;
}

body.hcfb-public-shell .hcfb-mega-nav__panel-inner:has(> .hcfb-mega-nav__panel-links:only-child) .hcfb-mega-nav__panel-links li {
	break-inside: avoid;
	margin-bottom: 0.15rem;
}

body.hcfb-public-shell .hcfb-mega-nav__panel-links a {
	display: block;
	padding: 0.65rem 0.75rem;
	border-radius: 6px;
	color: var(--wp--preset--color--hcfb-navy);
	text-decoration: none;
	font-weight: 600;
}

body.hcfb-public-shell .hcfb-mega-nav__panel-links a:hover,
body.hcfb-public-shell .hcfb-mega-nav__panel-links a:focus-visible {
	background: var(--wp--preset--color--hcfb-navy);
	color: var(--wp--preset--color--hcfb-surface);
}

/*
 * Utility Bar pass: hidden by default (desktop -- the same three links
 * are visible directly in the utility bar there, see
 * `.hcfb-utility-bar__nav-links` below); the <=1199px media query further
 * down switches this to `display: block`, matching the width where the
 * utility bar hides its own copy of these links.
 */
/*
 * Background-scroll lock while the full-viewport mobile navigation panel
 * is open (class toggled by assets/js/hcfb-interactive.js). The panel
 * itself (`.hcfb-mega-nav__body`, `position: fixed`) keeps its own
 * `overflow-y: auto` regardless, so the open menu remains fully
 * scrollable on its own -- this only prevents the page underneath it
 * from also scrolling.
 */
body.hcfb-mega-nav-scroll-lock {
	overflow: hidden;
}

body.hcfb-public-shell .hcfb-mega-nav__utility {
	display: none;
}

/*
 * Mobile-menu action group (2026-09-15, Ryan-directed visual refinement):
 * hidden by default (desktop) -- same pattern as `.hcfb-mega-nav__utility`
 * above and `.hcfb-mega-nav__mobile-trigger` further up -- and only
 * switched on inside the <=1199px mobile-menu breakpoint below. Desktop
 * navigation is completely untouched by this rule.
 */
body.hcfb-public-shell .hcfb-mega-nav__mobile-actions {
	display: none;
}

body.hcfb-public-shell .hcfb-mega-nav__utility-list {
	list-style: none;
	margin: 0;
	padding: 0;
}

body.hcfb-public-shell .hcfb-mega-nav__utility-link {
	display: flex;
	align-items: center;
	min-height: 44px;
	padding: 0.65rem var(--wp--preset--spacing--hcfb-md);
	color: var(--wp--preset--color--hcfb-navy);
	text-decoration: none;
	font-weight: 600;
	font-size: 0.9rem;
}

body.hcfb-public-shell .hcfb-mega-nav__utility-link:hover,
body.hcfb-public-shell .hcfb-mega-nav__utility-link:focus-visible {
	background: var(--wp--preset--color--hcfb-cream);
}

body.hcfb-public-shell .hcfb-mega-nav__panel-media img {
	display: block;
	width: 100%;
	height: 100%;
	object-fit: cover;
	border-radius: 8px;
	max-height: 20rem;
}

/*
 * Pass 6B: raised from 1180px to 1350px. Centering the panel under the
 * tab-list wrapper (above) means its horizontal position now tracks
 * where that wrapper actually sits, which shifts further right as the
 * viewport narrows (nav's own `margin-left: auto`). Confirmed via live
 * measurement that the full 46rem-wide panel centered under the tab-list
 * overflowed the viewport at 1280px specifically (scrollWidth 1302 vs
 * clientWidth 1280) even though 1280px sat outside the old 1180px
 * threshold. This pass is explicitly tested at 1024px and 900px too.
 *
 * Pass 6D: this breakpoint's other two rules (forcing every panel to a
 * single column and hiding `.hcfb-mega-nav__panel-media` outright) are
 * removed here -- they had the side effect of hiding Give Help's and Our
 * Impact's contextual images at every width from 900px to 1350px (not
 * just Find Food's newly-restored one), which this pass's explicit
 * "keep the image clearly visible... at 1024px" requirement rules out.
 * The width shrink alone (34rem instead of 46rem) already resolves the
 * original overflow this breakpoint exists for -- confirmed via direct
 * re-measurement at 1280/1024/900px with the image panel now two-column
 * at all three: no overflow at any of them (see home.css Pass 6D test
 * coverage in tests/browser/public-home.spec.ts for the live numbers).
 */
@media (max-width: 1350px) {
	body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__panel {
		width: min(34rem, calc(100vw - 2rem));
	}
}

/*
 * Breakpoint-based header pass: widened from <=899px to <=1199px so the
 * full desktop tab row (which needs real horizontal room to stay legible
 * and centered -- see the >=1200px rule further below) never gets
 * squeezed or wrapped at tablet/small-desktop widths. Below 1200px this
 * file falls back to the same disclosure-menu presentation as true
 * mobile, just at a wider range -- not a second, different pattern.
 */
/* Mobile (<=1199px, matching the breakpoint already used by every other
 * homepage section's mobile-stacking rule in this file): distinct
 * pattern, not the desktop mega-panel forced narrow -- a hamburger
 * trigger opening a stacked disclosure menu, each item its own
 * expand/collapse accordion using the exact same tab/panel markup and
 * JS, just repositioned by CSS instead of absolutely positioned. */
@media (max-width: 1199px) {
	body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__mobile-trigger {
		display: inline-flex;
	}

	/*
	 * Real bug found+fixed verifying this pass: `.hcfb-mega-nav` (this
	 * element's own containing block, via its `position:relative`) is
	 * only as wide as the trigger button itself at mobile widths -- it
	 * does not stretch to the header row's full width. `position:
	 * absolute` + `left:0; right:0` on this body therefore resolved
	 * against THAT narrow box, not the viewport, rendering the entire
	 * mobile menu as a ~148px-wide column instead of full-width --
	 * confirmed via live measurement (bodyRect.width ~148px at a 390px
	 * viewport). That narrow, overlapping rendering was also confirmed to
	 * break WebKit's default Tab sequence into it entirely (a real
	 * layout defect causing a real keyboard-accessibility failure, not
	 * the already-documented/expected "WebKit excludes links" limitation
	 * -- these items are buttons, and direct .focus() worked fine, only
	 * sequential Tab skipped them). `position:fixed` makes the viewport
	 * itself the containing block regardless of the narrow positioned
	 * ancestor, which is what correctly spans the full width and
	 * resolved the Tab-order issue too.
	 */
	body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__body {
		display: none;
		position: fixed;
		left: 0;
		right: 0;
		top: var(--hcfb-mega-nav-mobile-top, 0);
		background: var(--wp--preset--color--hcfb-surface);
		box-shadow: 0 14px 30px rgba(20, 21, 60, 0.18);
		z-index: 50;
		max-height: calc(100vh - var(--hcfb-mega-nav-mobile-top, 0px));
		overflow-y: auto;
	}

	body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__body.is-open {
		display: block;
	}

	/*
	 * Mobile-menu action group (2026-09-15, Ryan-directed visual
	 * refinement, replacing the earlier single full-width Volunteer-only
	 * treatment): three equal-width stacked buttons -- Volunteer, Find
	 * Food, Make a Gift -- directly beneath the close control, with the
	 * compact header pills hidden while open (see the
	 * `.hcfb-header-actions` rule below) so exactly one rendering of each
	 * action is ever visible. Padding is deliberately tight (hcfb-xs top,
	 * a modest gap between buttons) -- the previous single-button
	 * treatment's larger hcfb-sm top padding read as excessive empty
	 * space around the close control once reviewed against a real
	 * device/screenshot.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__mobile-actions {
		display: flex;
		flex-direction: column;
		gap: 0.5rem;
		padding: var(--wp--preset--spacing--hcfb-xs) var(--wp--preset--spacing--hcfb-md) var(--wp--preset--spacing--hcfb-xs);
	}

	/*
	 * Every one of the three actions gets an identical box regardless of
	 * which color tier it is -- same height/width/radius/typography/
	 * padding, per direct instruction -- so only background/text color
	 * differ (Find Food/Volunteer green+navy already come from the
	 * `.hcfb-header-actions__find-food`/`__volunteer` rule above; Make a
	 * Gift's orange+navy already come from its own `has-hcfb-*-color`
	 * utility classes, WordPress core's generated color CSS).
	 *
	 * Real bug found+fixed verifying this pass: this file's own compact-
	 * pill sizing overrides for narrow widths (`.hcfb-header-actions__
	 * find-food .wp-block-button__link`/`.hcfb-donate-action
	 * .wp-block-button__link`, further down in this same breakpoint --
	 * padding 0.4rem 0.6rem, font-size 0.9rem, meant for the CLOSED
	 * header's compact cluster) are EXACTLY as specific as a plain
	 * `.hcfb-mega-nav__mobile-actions .wp-block-button__link` selector
	 * (three classes deep either way) and appear later in this file, so
	 * they were silently winning here on source order alone -- confirmed
	 * via computed style (Find Food/Make a Gift rendering at 0.9rem/
	 * compact padding while Volunteer, which has no such competing rule,
	 * rendered correctly at this rule's own values). Adding the
	 * `.wp-block-button` class into this selector (four classes, not
	 * three) is what genuinely outranks those rules regardless of source
	 * order, with no `!important` needed.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__mobile-actions .wp-block-button .wp-block-button__link {
		display: flex;
		align-items: center;
		justify-content: center;
		width: 100%;
		min-height: 48px;
		padding: 0.65rem 1rem;
		border-radius: 8px;
		font-weight: 700;
		font-size: 1rem;
		text-decoration: none;
		box-sizing: border-box;
	}

	/*
	 * While the mobile menu is open, the compact header action pills
	 * (Find Food / Make a Gift -- Volunteer is already hidden at this
	 * width regardless, see that rule above) are replaced by the
	 * equal-width stacked group above -- showing both at once would
	 * duplicate every destination twice on screen and in the
	 * accessibility tree. Keyed off the same `body.hcfb-mega-nav-scroll-
	 * lock` class assets/js/hcfb-interactive.js already adds/removes
	 * exactly when the mobile panel opens/closes (see that file's
	 * closeMobileBody()/trigger click handler) -- no new JS needed. Kept
	 * inside this same <=1199px breakpoint (not unscoped) so it stops
	 * applying the instant a resize crosses back above it, exactly like
	 * every other rule in this block -- desktop can never end up with
	 * this rule in effect.
	 */
	body.hcfb-public-shell.hcfb-mega-nav-scroll-lock .hcfb-header-actions {
		display: none;
	}

	body.hcfb-public-shell .hcfb-mega-nav__list {
		flex-direction: column;
		align-items: stretch;
		gap: 0;
		padding: var(--wp--preset--spacing--hcfb-sm) 0;
	}

	/*
	 * Root-cause fix (mobile accordion-panel defect): `.hcfb-mega-nav__item`
	 * is `display:flex` unscoped (desktop-only reason -- centers the tab
	 * button vertically inside its own <li>, see that rule's own comment).
	 * Its default flex-direction is row. On desktop that's invisible
	 * because the panel is `position:absolute` and out of flow, so being a
	 * flex sibling of the tab button never mattered -- but the override
	 * below already correctly puts the panel back into normal flow at this
	 * width (`position:static`), which makes it a REAL second flex item in
	 * that same row, sized to shrink-fit its content beside the tab
	 * button instead of stacking beneath it (confirmed via computed
	 * styles: panel width 165.594px, not full-width, with the tab button
	 * to its left). Column direction + stretch is what makes the panel
	 * actually render directly under its own tab, full width, in normal
	 * flow, pushing every following <li> down -- the missing piece, not
	 * the position/left/transform reset already present below.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__item {
		flex-direction: column;
		align-items: stretch;
	}

	body.hcfb-public-shell .hcfb-mega-nav__link,
	body.hcfb-public-shell .hcfb-mega-nav__tab {
		width: 100%;
		justify-content: space-between;
		padding: 0.85rem var(--wp--preset--spacing--hcfb-md);
		min-height: 44px;
		border-radius: 0;
	}

	/*
	 * Pass 6A: the desktop top-level caret was removed entirely (user
	 * feedback: it looked visually out of place there) -- but on mobile
	 * it is the only visual cue that a row expands/collapses, and
	 * removing it without an equally clear replacement is explicitly
	 * disallowed by this pass's brief, so it stays here, mobile-only.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__caret {
		display: inline-block;
		width: 0;
		height: 0;
		border-left: 4px solid transparent;
		border-right: 4px solid transparent;
		border-top: 5px solid currentColor;
		flex-shrink: 0;
		transition: transform 0.15s ease;
	}

	body.hcfb-public-shell .hcfb-mega-nav__tab[aria-expanded='true'] .hcfb-mega-nav__caret {
		transform: rotate(180deg);
	}

	/*
	 * Real bug found+fixed (mobile-menu pass): the desktop rule above
	 * anchors this panel with `left: 50%; transform: translateX(-50%)`
	 * for its absolute-positioned centering. `position: static` here
	 * cancels the positioning scheme (so `left` stops applying), but
	 * `transform` is independent of `position` and still applied,
	 * shifting the panel left by half its own (now full, ~390px) width --
	 * confirmed via direct measurement (panel `x: -195` at a 390px
	 * viewport, clipping roughly the left half of its content off-screen
	 * and making it look like an unintended two-column layout). Both
	 * `left` and `transform` must be explicitly reset here, not just
	 * `position`.
	 */
	body.hcfb-public-shell .hcfb-mega-nav.is-enhanced .hcfb-mega-nav__panel {
		position: static;
		left: auto;
		transform: none;
		width: auto;
		max-width: none;
		box-shadow: none;
		border-radius: 0;
		background: var(--wp--preset--color--hcfb-cream);
	}

	body.hcfb-public-shell .hcfb-mega-nav__panel-inner {
		grid-template-columns: minmax(0, 1fr);
		padding: 0 var(--wp--preset--spacing--hcfb-md) var(--wp--preset--spacing--hcfb-md);
	}

	/* Images stay a desktop-only enrichment -- keeps the mobile accordion
	 * compact, per this pass's "avoid creating a huge decorative empty
	 * region" guidance for decorative imagery generally. */
	body.hcfb-public-shell .hcfb-mega-nav__panel-media {
		display: none;
	}

	body.hcfb-public-shell .hcfb-mega-nav__panel-links a {
		min-height: 44px;
		display: flex;
		align-items: center;
	}

	/*
	 * Utility Bar pass: the three utility-bar text links, hidden from the
	 * utility bar itself at this same width (see `.hcfb-utility-bar__nav-
	 * links` above), reachable here instead -- the existing mobile
	 * navigation body, not a second menu. A top border separates it from
	 * the primary section list above.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__utility {
		display: block;
		border-top: 1px solid var(--wp--preset--color--hcfb-border, #d8d3c6);
		margin-top: var(--wp--preset--spacing--hcfb-sm);
		padding-top: var(--wp--preset--spacing--hcfb-sm);
	}
}

@media (max-width: 1199px) and (prefers-reduced-motion: reduce) {
	body.hcfb-public-shell .hcfb-mega-nav__caret {
		transition: none;
	}
}

/*
 * Header-row overflow fix (visual-polish pass, Primary Header/Navigation):
 * confirmed via live screenshot at 390px that the mobile trigger's visible
 * "Open menu" text no longer fits next to the logo on the header row's
 * first line and overflows/clips at the viewport edge -- 500px (where the
 * text still fits) does not have this problem. Below this breakpoint the
 * trigger goes icon-only, matching the exact established pattern this
 * file's sibling stylesheet (style.css) already uses for the logo's own
 * narrow-mobile fallback. The button's aria-label (inc/template-tags.php)
 * carries the accessible name once this text is hidden -- display:none
 * content is excluded from the accessible-name computation, so the label
 * alone would otherwise leave the button unnamed here. min-width/
 * min-height hold the touch target at 44px now that the text no longer
 * pads the button out to that size on its own. (The header row itself no
 * longer wraps onto a second line at this width at all -- see the
 * Primary-nav pass rule below.)
 */
@media (max-width: 480px) {
	body.hcfb-public-shell .hcfb-mega-nav__trigger-label {
		display: none;
	}

	body.hcfb-public-shell .hcfb-mega-nav__mobile-trigger {
		min-width: 44px;
		min-height: 44px;
		justify-content: center;
		padding: 0.5rem;
	}
}

/*
 * Primary-nav pass: one clean mobile header row -- logo left, "Make a
 * Gift" + the hamburger grouped together on the right, replacing the
 * previous behavior where the row wrapped onto a second line (this
 * file's own now-outdated comment above documented that wrap as
 * intentional; it no longer is). Root cause: `column-gap:
 * var(--wp--preset--spacing--hcfb-xl)` is 4rem (64px) -- generous by
 * design for desktop's wide row, but with two 64px gaps plus logo/
 * trigger/button content that no longer fits under ~390px, forcing a
 * wrap. `flex-wrap: nowrap` plus a much smaller mobile-only gap keeps
 * everything on one row down to 320px.
 *
 * Visual grouping uses `order` (not a DOM change): DOM order stays
 * [logo, nav, donate-wrap] site-wide so the desktop tab order (nav
 * before "Make a Gift", the approved order) is completely unaffected.
 * At this width, the desktop tab list itself is not in the tab order
 * anyway -- `.hcfb-mega-nav__body` is `display: none` until opened, so
 * the nav element's only focusable child while closed is the hamburger
 * trigger. `margin-left: auto` on the now-second-in-order donate-wrap
 * pushes it (and the trigger after it) to the row's right edge as one
 * cluster, while logo stays pinned left -- the same "one item absorbs
 * the remaining space" pattern already used for `.hcfb-mega-nav`'s own
 * desktop `margin-left: auto` (reset to 0 here so it no longer competes).
 */
@media (max-width: 1199px) {
	body.hcfb-public-shell .hcfb-header-row--home {
		flex-wrap: nowrap;
		justify-content: flex-start;
		column-gap: 0.6rem;
	}

	body.hcfb-public-shell .hcfb-header-row--home .hcfb-header-actions {
		order: 2;
		margin-left: auto;
		flex-shrink: 0;
	}

	body.hcfb-public-shell .hcfb-header-row--home .hcfb-mega-nav {
		order: 3;
		margin-left: 0;
		flex-shrink: 0;
	}

	body.hcfb-public-shell .hcfb-logo-link {
		min-width: 0;
	}

	/*
	 * Header nav visual-iteration pass: horizontal padding tightened
	 * further (0.85rem -> 0.6rem) so this button sits more comfortably
	 * beside the logo, Find Food, and the menu trigger now that there are
	 * two buttons here instead of one. Vertical padding, font-size, and
	 * min-height (44px, from the unscoped base rule above) are all
	 * unchanged -- tap height and text size are untouched, only the
	 * button's own left/right padding shrinks.
	 */
	body.hcfb-public-shell .hcfb-donate-action .wp-block-button__link {
		padding: 0.4rem 0.6rem;
		font-size: 0.9rem;
		white-space: nowrap;
	}

	/*
	 * Header nav visual-iteration pass: below the desktop breakpoint,
	 * "Volunteer" drops out of the COMPACT header cluster -- it stays
	 * fully reachable via Give Help's own dropdown/mobile-accordion entry
	 * (same /give-help/volunteer/ destination) and, since the mobile-menu
	 * action-group pass below, via its own prominent stacked button once
	 * the menu is open -- so hiding the second, faster compact-pill path
	 * here loses no destination. "Find Food" stays visible at every
	 * width: it no longer has any other reachable entry point now that it
	 * is out of the informational nav, so it keeps the same
	 * compact-at-narrow-width treatment "Make a Gift" already had.
	 */
	body.hcfb-public-shell .hcfb-header-actions__volunteer {
		display: none;
	}

	/*
	 * Mobile-menu action group (2026-09-15): this Volunteer button reuses
	 * the `.hcfb-header-actions__volunteer` class purely for its
	 * established green/navy color treatment (see that rule further
	 * down) -- it is a DIFFERENT rendering of the action than the compact
	 * header cluster's own, and must not inherit the compact cluster's
	 * "hidden below desktop" rule directly above. More specific than that
	 * rule (three classes deep, not two), so this correctly wins.
	 */
	body.hcfb-public-shell .hcfb-mega-nav__mobile-actions .hcfb-header-actions__volunteer {
		display: block;
	}

	body.hcfb-public-shell .hcfb-header-actions__find-food .wp-block-button__link {
		padding: 0.4rem 0.6rem;
		font-size: 0.9rem;
		white-space: nowrap;
	}
}

/*
 * Header nav visual-iteration pass: adding a second persistent button
 * (Find Food, alongside the already-existing Make a Gift) left no room
 * under ~480px -- confirmed via direct measurement that logo + both
 * buttons + the hamburger trigger no longer fit on one nowrap line down
 * to 320px the way logo + one button previously did (see the "Primary-
 * nav pass" note above: that layout was already tuned with zero spare
 * width for exactly one button). Rather than shrinking Find Food or Make
 * a Gift to the point of illegibility to force one line, this lets the
 * row wrap in this narrow range only: logo stays alone on the first line
 * (unchanged position/size), Find Food + Make a Gift + the hamburger
 * trigger wrap together, still right-aligned as one cluster, onto a
 * second line. 480px and up is unaffected (already fits on one line,
 * confirmed by direct measurement, so it keeps the single-row nowrap
 * layout above unchanged).
 */
@media (max-width: 479px) {
	body.hcfb-public-shell .hcfb-header-row--home {
		flex-wrap: wrap;
		row-gap: 0.5rem;
	}
}


/* ------------------------------------------------------------------ */
/* Shared footer shell: wide 3-column layout                           */
/* ------------------------------------------------------------------ */

/*
 * Pass 6A root-cause note (padding-top): the footer block's own inline
 * `style="padding-top:var(--wp--preset--spacing--hcfb-2xl)"`
 * (parts/footer-home.html) resolves to 0px -- confirmed via
 * getComputedStyle -- since that token is empty/unresolved in this
 * environment (the same pre-existing, out-of-scope issue documented
 * elsewhere for this token). `padding-bottom` on that same inline style
 * uses `hcfb-lg`, which does resolve, so only the top side was silently
 * losing its padding. `!important` is required here only because it must
 * beat that inline style's specificity, not to override a deliberate
 * design choice.
 */
/*
 * Staff Review Round 1 (logos pass): "Our Partners & Affiliations" light
 * band directly above the navy footer. Same full-bleed-buster treatment as
 * `.hcfb-site-footer--home` below -- this group also uses a "constrained"
 * block layout, which without this override would cap it at the theme's
 * default content-size instead of spanning the page. Padding is
 * deliberately modest on both sides ("do not make this section taller than
 * necessary," this pass's brief).
 */
body.hcfb-public-shell .hcfb-partners-section {
	max-width: none;
	width: 100%;
	padding: var(--wp--preset--spacing--hcfb-md, 1.5rem) var(--wp--preset--spacing--hcfb-sm, 1rem);
}

body.hcfb-public-shell .hcfb-partners-heading {
	margin: 0 0 var(--wp--preset--spacing--hcfb-sm, 1rem);
}

/*
 * Staff Review Round 1 (final visual tweaks pass): the previous identical-
 * bounding-box treatment (every logo forced into the same fixed width x
 * height box, NCF's own aspect ratio letterboxed inside it) kept NCF from
 * dominating, but capped every OTHER logo down to NCF's own comfortable
 * size in the process -- all four read as too small at normal viewing
 * distance. Back to a shared-height/auto-width model (each mark keeps its
 * own native aspect ratio, `object-fit: contain` is a defensive backstop
 * only), with the shared height increased noticeably, and NCF given its
 * own smaller height via the modifier rule below rather than forcing
 * every logo into one identical width.
 */
/*
 * Ryan review pass: the row's own content (4 logos + gaps) was much
 * narrower than the section around it, and `justify-content: center`
 * clustered that narrow content in the middle -- reading as "compressed
 * into the center of a much wider section." A larger column-gap gives the
 * logos real breathing room at desktop widths (row-gap kept modest so
 * wrapped rows on narrower screens don't get pushed too far apart
 * vertically), and a wider-but-still-restrained max-width (up from the
 * site's shared 82rem content width) gives the row itself a bit more room
 * to work with on very large screens, without ever reaching the section's
 * own edges (`.hcfb-partners-section`'s horizontal padding above still
 * guarantees that).
 */
body.hcfb-public-shell .hcfb-partners-row {
	--hcfb-partner-logo-h: clamp(2.75rem, 4.4vw, 4.6rem);
	display: flex;
	flex-wrap: wrap;
	align-items: center;
	justify-content: center;
	/*
	 * Staff Review comment 6797 (2026-09-24, Ryan-directed): "space out a
	 * little more" -- column gap increased modestly on top of the
	 * existing hcfb-xl token rather than replacing it with a new preset.
	 */
	gap: var(--wp--preset--spacing--hcfb-md, 1.5rem) calc(var(--wp--preset--spacing--hcfb-xl, 4rem) + 1rem);
	list-style: none;
	margin: 0 auto;
	padding: 0;
	max-width: 88rem;
}

body.hcfb-public-shell .hcfb-partners-row__item {
	display: flex;
	align-items: center;
	justify-content: center;
}

body.hcfb-public-shell .hcfb-partners-row__logo {
	display: block;
	width: auto;
	height: var(--hcfb-partner-logo-h);
	max-width: 100%;
	object-fit: contain;
}

/*
 * NCF/Blueprint Partner's lockup is a much wider ~3.87:1 ratio than the
 * other three marks (~1.3-2.2:1 -- Feeding America, Feeding Florida,
 * United Way). At the shared row height above it would render
 * substantially wider than every other logo and read as dominating the
 * row again, exactly the problem the old fixed-box treatment was
 * introduced to fix. A smaller height for this one mark keeps its
 * rendered WIDTH in the same range as the row's next-widest logo (United
 * Way) instead of shrinking every other logo to match it.
 */
body.hcfb-public-shell .hcfb-partners-row__logo--ncf-blueprint-partner {
	height: clamp(1.7rem, 2.7vw, 2.9rem);
}

/*
 * Staff Review comment 6797 (2026-09-24, Ryan-directed): Feeding America
 * and Feeding Florida read smaller than United Way at the same shared
 * row height. Measured why (PIL bounding-box of each PNG's non-white
 * content against its own canvas, same "perceived weight" technique
 * already used for Charity Navigator/GuideStar and this NCF mark above):
 * United Way's artwork fills ~93.9% of its canvas height edge-to-edge;
 * Feeding America's fills only ~72.5% (a lot of empty canvas below the
 * wordmark) and Feeding Florida's ~79.9% (it carries a third tagline
 * line the other two don't). Scaling each one's height by
 * 0.939/its-own-ratio brings its actual visible mark back to the same
 * perceived size as United Way's, without touching United Way or
 * NCF/Blueprint Partner.
 */
body.hcfb-public-shell .hcfb-partners-row__logo--feeding-america {
	height: clamp(3.56rem, 5.7vw, 5.96rem);
}

body.hcfb-public-shell .hcfb-partners-row__logo--feeding-florida {
	height: clamp(3.23rem, 5.17vw, 5.41rem);
}

/*
 * Mobile: a restrained single row wrapping naturally can leave one logo
 * stranded alone on its own line at narrow widths (4 items, uneven
 * widths). An explicit 2-column grid reads more intentional than that --
 * "2-column ... based on what reads best," this pass's brief.
 */
@media (max-width: 600px) {
	body.hcfb-public-shell .hcfb-partners-row {
		--hcfb-partner-logo-h: clamp(2rem, 9vw, 2.9rem);
		display: grid;
		grid-template-columns: 1fr 1fr;
		justify-items: center;
		align-items: center;
		gap: var(--wp--preset--spacing--hcfb-md, 1.5rem) var(--wp--preset--spacing--hcfb-sm, 1rem);
	}

	body.hcfb-public-shell .hcfb-partners-row__item {
		width: 100%;
	}

	body.hcfb-public-shell .hcfb-partners-row__logo--ncf-blueprint-partner {
		height: clamp(1.25rem, 6vw, 1.9rem);
	}

	body.hcfb-public-shell .hcfb-partners-row__logo--feeding-america {
		height: clamp(2.59rem, 11.66vw, 3.76rem);
	}

	body.hcfb-public-shell .hcfb-partners-row__logo--feeding-florida {
		height: clamp(2.35rem, 10.58vw, 3.41rem);
	}
}

/*
 * Pass 6B: this footer measured ~591px tall (desktop) before this pass --
 * "visually too large" per this pass's brief, target ~400-480px. The 4rem
 * top padding was the single largest fixed contributor; halving it here is
 * one of several compounding reductions in this section (see the
 * column-row gaps and Quick Links two-column layout below) rather than one
 * large cut, since no single rule accounted for the whole excess.
 */
body.hcfb-public-shell .hcfb-site-footer--home {
	max-width: none;
	width: 100%;
	padding-top: var(--wp--preset--spacing--hcfb-2xl, 3.5rem) !important;
}

body.hcfb-public-shell .hcfb-footer-inner {
	max-width: var(--hcfb-home-wide);
	margin: 0 auto;
	width: 100%;
}

/*
 * Pass 6A root-cause fix: WordPress's default flex-layout block support
 * CSS applies `align-items: center` to `.is-layout-flex` unless a rule
 * here overrides it -- confirmed via live measurement that the three
 * columns' headings ("Contact" / "Quick Links") landed ~0px, ~107px, and
 * ~183px from the row's own top edge respectively, each column
 * individually centered within the row's cross-axis height (tallest
 * column's height) rather than starting flush together. `flex-start`
 * makes every column begin at the same top position regardless of its
 * own content height -- this is what "aligned headings and content
 * starts" (this pass's brief) actually required; no per-column
 * adjustment was needed once the real cause was fixed.
 */
body.hcfb-public-shell .hcfb-footer-columns {
	align-items: flex-start;
	/*
	 * Pass 6A: --wp--preset--spacing--hcfb-2xl resolves to an empty
	 * string in this environment (the same pre-existing, out-of-scope
	 * token issue documented in Pass 5G/6 for other sections) -- an
	 * unresolved var() with no fallback invalidates the whole
	 * column-gap/row-gap declaration, which is why the three columns
	 * measured with a literal 0px gap between them before this fix,
	 * despite "column-gap" being declared. Explicit fallbacks restore
	 * real, controlled spacing regardless of whether the token ever
	 * resolves.
	 *
	 * Pass 6B: the fallback values themselves are reduced from the
	 * original 4rem/2rem -- still generous column separation, but this
	 * pass's brief specifically calls out "excessive" footer spacing as a
	 * defect to correct, not just a gap to keep resolvable.
	 */
	column-gap: var(--wp--preset--spacing--hcfb-2xl, 2.5rem);
	row-gap: var(--wp--preset--spacing--hcfb-xl, 1.5rem);
	margin-bottom: var(--wp--preset--spacing--hcfb-md, 2rem);
}

/*
 * Pass 6A: genuinely even columns (originally three, now four as of the
 * Staff Review Round 1 footer content pass), per this pass's explicit
 * brief -- superseding Pass 3's original "unequal columns, links column
 * deliberately wider" reasoning. A single shared rule (equal flex-basis,
 * equal max-width, no per-column override) is what keeps them balanced
 * regardless of how much content any one of them happens to hold.
 */
body.hcfb-public-shell .hcfb-footer-columns > * {
	flex: 1 1 0;
	min-width: 13rem;
	/* A generous cap, not the binding constraint -- with the shared
	 * --hcfb-home-wide inner width (82rem) and the gap above, four equal
	 * flex-basis:0 columns naturally settle around 22-23% each well
	 * before reaching this cap. */
	max-width: 22rem;
}

/*
 * Pass 6A note (superseded by Pass 6B, see below): originally centered
 * the brand column vertically within the row so the ~120px wordmark
 * wasn't stranded at the top of a tall empty column.
 *
 * Pass 6B: this pass's explicit brief is the opposite instruction -- align
 * the wordmark near the top of the footer, not vertically centered within
 * a tall empty column. With the row's other columns also considerably
 * shorter now (Quick Links compacted to two columns below, Contact copy
 * kept compact), the "dead zone" `align-self: center` was compensating
 * for is much smaller to begin with, and centering a short column inside
 * even that smaller remainder still reads as "the logo floating in
 * empty space" rather than "aligned with its neighbors." Reverting to the
 * row's own `align-items: flex-start` (i.e. no per-column override) is
 * what "near the top" actually requires.
 */

/*
 * Pass 6: the separate standalone icon mark (.hcfb-footer-mark,
 * [hcfb_logo context="footer-mark"]) that used to render above this same
 * wordmark was removed -- "no unnecessary duplicate marks," per this
 * pass's brief; the wordmark below already carries the full brand
 * identity on its own. Sized a bit larger than Pass 5's wordmark-only
 * size now that it is the column's sole brand element, for a "strong,
 * simple brand presentation" without a second mark competing for space.
 */
/*
 * Homepage Polish Pass 6D root-cause fix: the rule this replaced
 * (`height: 120px; width: auto; max-width: 100%;`) sets a FIXED height and
 * lets `max-width` independently cap the width -- two constraints on two
 * different dimensions, resolved against two different things (a pixel
 * value vs. the brand column's box), neither deferring to the other. The
 * intrinsic ratio (this file: 1101x292, ~3.77:1) only actually gets used
 * to derive `width:auto` when nothing else already constrains width first.
 * Confirmed via direct measurement at every required breakpoint: whenever
 * the auto-ratio width this logo would need at 120px tall (~452px) exceeded
 * the brand column's own width, `max-width: 100%` clipped the WIDTH down to
 * fit the column while `height` stayed pinned at 120px regardless -- e.g.
 * at 1024px the column measured ~289px wide, so the image rendered
 * 289x120 (a 2.41:1 box) instead of its true 3.77:1 ratio, a 36% ratio
 * distortion. Only mobile (≤480px, where the column is wide enough
 * relative to the smaller fixed height that max-width never actually
 * engaged) happened to render correctly -- not because the rule was
 * sound, but because that specific combination of numbers never hit the
 * conflict.
 *
 * The fix inverts which dimension is the free (auto) one: `height: auto`
 * always derives from whatever width is actually rendered, so there is
 * exactly one active size constraint (`width`, via `max-width`) at any
 * given viewport -- never two independent ones fighting over the same
 * box. `object-fit: contain` is a defensive backstop only (a plain
 * `width`+`height:auto` image never needs it to avoid distortion, since
 * its box always already matches its intrinsic ratio) in case any future
 * rule ever reintroduces an explicit height here.
 *
 * Sizing itself is intentionally smaller than the previous 120px-tall
 * attempt: the previous size was "oversized" per direct user feedback on
 * the 1024px screenshot (a defect independent of the distortion bug,
 * confirmed separately) -- this footer wordmark is a secondary brand
 * mark, not the page's primary logo (that's the header's), so a size in
 * the header logo's own neighborhood (44px/36px tall) reads as
 * appropriately "prominent but balanced" rather than dominating a
 * ~30%-width footer column. `clamp()` scales it smoothly between a
 * comfortable mobile floor and a modest desktop ceiling rather than
 * jumping between fixed breakpoint sizes.
 */
body.hcfb-public-shell .hcfb-site-footer--home .hcfb-logo--footer {
	width: clamp(11.25rem, 16.5vw, 15rem);
	height: auto;
	max-width: 100%;
	object-fit: contain;
}

/*
 * Staff Review Round 1 -- footer content pass: generalized from the former
 * Contact-column-only rule (font-size/line-height) and Quick-Links-only
 * heading-alignment fix to apply uniformly across all four content columns
 * (brand/hours/help/social), now that real content -- not just Quick Links --
 * lives in more than one of them. The underlying root cause the heading fix
 * addresses is unchanged from Pass 6A: every column uses a "constrained"
 * layout, and WordPress's global `.is-layout-constrained` styles apply
 * auto left/right margins to any non-full-width child, which visibly
 * shrink-wraps and centers heading/nav elements (their shrink-to-fit width
 * leaves room for the auto margin to act) but not plain paragraphs (already
 * naturally full-width, so the same auto margin has nothing to shift).
 */
body.hcfb-public-shell .hcfb-footer-col .has-small-font-size,
body.hcfb-public-shell .hcfb-footer-col address {
	font-size: 1.1rem;
	line-height: 1.6;
}

body.hcfb-public-shell .hcfb-footer-col address {
	font-style: normal;
}

body.hcfb-public-shell .hcfb-footer-col h2,
body.hcfb-public-shell .hcfb-footer-col h3 {
	font-size: 1.15rem;
	width: 100%;
	margin-top: 0;
	margin-bottom: 0.5rem;
	margin-left: 0;
	margin-right: 0;
}

/*
 * Pass 6B: tightened from the default block spacing (~1em top+bottom per
 * paragraph) so short stacked lines (address/hours/CTA copy) read as one
 * compact block rather than adding significant extra column height.
 */
body.hcfb-public-shell .hcfb-footer-col p {
	margin-top: 0;
	margin-bottom: 0.5rem;
}

body.hcfb-public-shell .hcfb-footer-col p:last-child {
	margin-bottom: 0;
}

body.hcfb-public-shell .hcfb-footer-address-block {
	margin-bottom: 0.75rem;
}

body.hcfb-public-shell .hcfb-footer-address-block:last-of-type {
	margin-bottom: 1rem;
}

/*
 * Ryan review pass: the Hours column's heading and paragraph margins were
 * both the same flat 0.5rem, so "Hours of Operation" → its own hours read
 * with the exact same gap as "Hours of Operation"'s hours → "Food
 * Donation Hours" (a genuinely new, distinct subsection) -- no visual
 * hierarchy between "heading to its own details" and "one subsection to
 * the next." Tightening the heading's own bottom margin keeps it close to
 * its details; `p + h3` only adds extra top space where a paragraph is
 * directly followed by a new heading, i.e. exactly at a subsection
 * boundary, leaving the unrelated existing paragraph-to-paragraph spacing
 * (Fort Myers hours → Collier hours, both still under "Food Donation
 * Hours") untouched.
 */
body.hcfb-public-shell .hcfb-footer-col--hours h3 {
	margin-bottom: 0.25rem;
}

body.hcfb-public-shell .hcfb-footer-col--hours p + h3 {
	margin-top: 0.75rem;
}

/*
 * Staff Review Round 1 (final visual tweaks pass): the phone icon and
 * number previously just flowed inline with no defined gap between the
 * SVG and the text, reading as crowded. A real flex gap (not a literal
 * space/&nbsp; in the markup) keeps `tel:+12393347007` and the visible
 * "(239) 334-7007" text exactly as they were -- only the layout between
 * icon and text changed. Scoped to the footer's own brand column only;
 * the header utility bar's phone link has its own separate styling.
 */
body.hcfb-public-shell .hcfb-footer-col--brand .hcfb-utility-phone {
	display: inline-flex;
	align-items: center;
	gap: 0.5rem;
}

body.hcfb-public-shell .hcfb-footer-col--help .wp-block-navigation-item > a {
	font-size: 1.05rem;
	line-height: 1.8;
}

/*
 * Pass 6A: the same WordPress default-flex-centering root cause as the
 * heading fix above, on the link list itself -- the vertical
 * core/navigation block's own container defaults to
 * `align-items: center`, indenting/centering every link instead of
 * keeping them flush-left under the (now flush-left) "Quick Links"
 * heading. Confirmed visually before this fix: the link list sat
 * noticeably indented from the heading directly above it.
 */
/*
 * Pass 6A root-cause note: core/navigation renders as
 * <nav class="wp-block-navigation">, wrapping the actual
 * <ul class="wp-block-navigation__container"> -- the OUTER <nav> is the
 * real flex child of this column, and it is the one WordPress applies
 * automatic centering margins to (same auto-margin-on-a-flex-child
 * behavior as the heading fix above). Fixing only the inner <ul> (a
 * first attempt) had no visible effect, since the <ul> was already
 * correctly full-width *within* the <nav>'s own narrow, centered box --
 * confirmed by inspecting the actual rendered markup rather than
 * assuming which element needed the fix.
 */
body.hcfb-public-shell .hcfb-footer-col--help nav.wp-block-navigation {
	width: 100%;
	margin-left: 0;
	margin-right: 0;
}

body.hcfb-public-shell .hcfb-footer-col--help .wp-block-navigation__container {
	align-items: flex-start;
	width: 100%;
	margin-left: 0;
	margin-right: 0;
}

/*
 * Pass 6B: seven links stacked in one column ran to ~210px tall (7 lines
 * at line-height 1.8/1.05rem) -- the single largest content-height
 * contributor in the whole footer, and this pass's brief explicitly asks
 * for a two-column desktop arrangement. `column-count` (not CSS grid's
 * `grid-auto-flow: column`) flows the existing DOM order top-to-bottom in
 * column one before continuing into column two, so it changes only the
 * visual arrangement -- keyboard/tab order and reading order both stay
 * exactly the list's existing order (Find Food, Give Help, Donor Portal,
 * Careers / Contact, Privacy Policy, Accessibility). Same technique
 * already used for the mega-nav text-only panels above, including the
 * same `display: block` requirement -- `column-count` has no effect on
 * the `align-items: flex-start` flex container the rule just above this
 * one establishes.
 */
body.hcfb-public-shell .hcfb-footer-col--help .wp-block-navigation__container {
	display: block;
	column-count: 2;
	column-gap: var(--wp--preset--spacing--hcfb-xl, 2rem);
}

body.hcfb-public-shell .hcfb-footer-col--help .wp-block-navigation-item {
	break-inside: avoid;
}

/*
 * Pass 6B: two columns need real width to avoid cramping ("do not turn
 * the panel into a cramped grid" -- this pass's brief applies the same
 * standard to the footer) -- the shared column max-width above
 * (27rem) is generous enough at desktop widths, but at the column's
 * smallest allowed width (14rem, `.hcfb-footer-columns > *`'s min-width)
 * two columns of "Accessibility"/"Donor Portal"-length links would wrap
 * mid-word. Reverting to a single column below 900px (the same breakpoint
 * already used elsewhere in this file for the header/nav responsive
 * switch) keeps mobile/narrow-tablet links comfortably readable; this
 * width is always well above the row's mobile-stacked full-viewport width
 * in practice, so this rule is a real safeguard, not dead code.
 */
@media (max-width: 900px) {
	body.hcfb-public-shell .hcfb-footer-col--help .wp-block-navigation__container {
		column-count: 1;
	}
}

/*
 * Pass 6B root-cause fix: WordPress's default `.is-layout-flex` support
 * CSS applies `align-items: center` here (the same recurring root cause
 * already fixed on the heading and nav elements above, in Pass 6A) --
 * confirmed via computed rect that `.hcfb-social-row`, the one child in
 * this column without its own explicit full-width override, sat centered
 * ~84px in from the column's left edge instead of flush under the link
 * list above it. "Social icons directly beneath the link grid" means
 * flush-left with it, not centered independently of it.
 */
/*
 * Ryan review pass: reduced from --hcfb-md (1.5rem/24px) to --hcfb-sm
 * (1rem/16px). This gap applies uniformly between every direct child of
 * this column (heading → 211 link → "Quick Links" heading → nav list), so
 * it was the actual, dominant source of the "Need Help Now?" → 211 link
 * spacing -- the child margins below turned out NOT to be the real lever
 * here (see that rule's own comment): a flex `gap` and a child's own
 * margin both add on top of each other rather than one overriding the
 * other, so tightening this shared value (rather than only the child
 * margins) is what actually pulls the heading and its link together,
 * while still leaving a reasonable, consistent gap before "Quick Links"
 * and its own link list.
 */
body.hcfb-public-shell .hcfb-footer-col--help {
	display: flex;
	flex-direction: column;
	align-items: flex-start;
	gap: var(--wp--preset--spacing--hcfb-sm, 1rem);
}

/*
 * Staff Review Round 1 -- footer content pass: same root cause as the
 * `.hcfb-social-row` override just below (WordPress's global
 * `.is-layout-constrained` auto-margin centering, `!important`, beating
 * `align-items: flex-start` above) now also visibly shrink-wraps and
 * centers the 211 CTA paragraph -- confirmed via computed rect it sat
 * offset from the column's left edge instead of flush under "Need Help
 * Now?" above it, the one child in this column without its own explicit
 * full-width heading override or `.hcfb-social-row`'s own `!important`.
 *
 * Ryan review pass root-cause note: `margin-top` here was never actually
 * winning against `.hcfb-footer-col p`'s own `margin-top: 0` (that plain
 * class+tag selector is MORE specific than a single class selector, so it
 * always overrode this rule's margin-top regardless of source order or
 * declared value -- confirmed via computed style, not assumed). Restated
 * with the `p` tag included so this rule's specificity actually matches
 * (and, by later source order, wins); set to 0 since the column gap
 * reduction above is now what supplies the (intentionally tightened)
 * space above this link.
 */
body.hcfb-public-shell p.hcfb-footer-211-cta {
	margin-left: 0 !important;
	margin-right: 0 !important;
	margin-top: 0;
}

/*
 * Ryan review pass: "Need Help Now?" and the 211 line should read as one
 * clear content group. Scoped to this column's h3 only (Quick Links, the
 * other heading in this column, is an h2 and is unaffected).
 */
body.hcfb-public-shell .hcfb-footer-col--help h3 {
	margin-bottom: 0.25rem;
}

/*
 * Local footer tweaks pass: "Call United Way's 211 Line" previously read
 * as a regular small footer link, easy to miss next to the address/hours
 * copy around it -- per Harry's request (old-site screenshot as tone
 * guidance) it now reads as a real call-to-action: noticeably larger and
 * bolder than the surrounding footer text, in the site's brand-orange CTA
 * color (the same accent already used for primary actions elsewhere --
 * hero CTA, header "Make a Gift"), with a phone icon for an immediate
 * visual cue. Restrained on purpose -- no background pill/button
 * treatment, no oversized type -- so it stays a prominent LINK, not a
 * competing button, and doesn't fight the rest of the footer for
 * attention. Underline intentionally off by default (the size/weight/
 * color/icon combination is already a strong, unambiguous affordance for
 * an isolated single-line CTA, not body text with adjacent link/non-link
 * copy) and restored on hover/focus alongside the color swap to white,
 * matching every other footer link's existing hover/focus treatment
 * (style.css's `.hcfb-site-footer a:hover, :focus-visible`).
 */
body.hcfb-public-shell .hcfb-footer-211-cta a {
	display: inline-flex;
	align-items: center;
	gap: 0.5rem;
	font-size: 1.2rem;
	font-weight: 800;
	color: var(--wp--preset--color--hcfb-orange);
	text-decoration: none;
}

body.hcfb-public-shell .hcfb-footer-211-cta a:hover,
body.hcfb-public-shell .hcfb-footer-211-cta a:focus-visible {
	color: var(--wp--preset--color--hcfb-surface);
	text-decoration: underline;
}

body.hcfb-public-shell .hcfb-footer-211-cta svg {
	flex-shrink: 0;
	width: 1.2rem;
	height: 1.2rem;
}

/*
 * Pass 5 (§4): slightly more breathing room between icons (was 0.75rem).
 * Pass 6B: margin-top fallback reduced from 1rem to 0.5rem -- part of
 * this pass's "space between links and social icons" reduction.
 *
 * Pass 6B root-cause fix (margin-left/right): this column
 * (`.hcfb-footer-col--help`) is a "constrained"-layout block, and
 * WordPress's global styles unconditionally apply
 * `.is-layout-constrained > :where(...) { margin-left: auto !important;
 * margin-right: auto !important; }` to every one of its direct children
 * that isn't full-width -- confirmed via `document.styleSheets`
 * inspection that this exact `!important` rule (not a flex default) was
 * centering this element ~83px in from each side, independent of the
 * `align-items: flex-start` fix above (an auto margin always wins over
 * align-items regardless of specificity). The "Quick Links" heading and
 * the nav element above never visibly needed this same override because
 * both are already `width: 100%`, leaving zero slack for an auto margin
 * to distribute either way; this element's width is intrinsic
 * (shrink-wrapped to its icons), so it actually had slack to center
 * within, and needs its own `!important` to beat WordPress's.
 */
body.hcfb-public-shell .hcfb-social-row {
	display: flex;
	flex-wrap: wrap;
	gap: 1rem;
	list-style: none;
	margin: var(--wp--preset--spacing--hcfb-sm, 0.5rem) 0 0;
	margin-left: 0 !important;
	margin-right: 0 !important;
	padding: 0;
}

body.hcfb-public-shell .hcfb-social-row a {
	display: flex;
	align-items: center;
	justify-content: center;
	width: 2.25rem;
	height: 2.25rem;
	border-radius: 999px;
	background: var(--wp--preset--color--hcfb-surface);
}

body.hcfb-public-shell .hcfb-social-row svg {
	width: 1.1rem;
	height: 1.1rem;
	fill: var(--wp--preset--color--hcfb-navy);
}

/*
 * Staff Review Round 1 (logos pass): Charity Navigator / GuideStar trust
 * marks, centered and visually self-contained -- a small credential row
 * distinct from the left-aligned four-column grid above it, so it doesn't
 * read as a fifth column competing with addresses/hours/211 (this pass's
 * brief). The divider that used to sit on `.hcfb-footer-legal` (below)
 * moves up to here, since this section is now the first thing below the
 * four-column grid.
 */
/*
 * Final footer polish: explicit margin-bottom added below the trust-marks
 * row -- without it, this section's gap from the legal paragraph
 * immediately after it was only the theme's default inter-block spacing,
 * which read as "tucked into the legal copy" rather than its own
 * intentional area (this pass's brief). Legal copy/wording itself
 * (`.hcfb-footer-legal`, below) is untouched -- this is spacing on the
 * trust-marks section's own box, not a change to the legal block.
 */
body.hcfb-public-shell .hcfb-trust-marks-section {
	max-width: var(--hcfb-home-wide);
	margin: 0 auto;
	padding-top: var(--wp--preset--spacing--hcfb-md, 1.5rem);
	margin-bottom: var(--wp--preset--spacing--hcfb-md, 1.5rem);
	border-top: 1px solid rgba(255, 255, 255, 0.2);
}

body.hcfb-public-shell .hcfb-trust-marks-heading {
	margin: 0 0 var(--wp--preset--spacing--hcfb-sm, 1rem);
}

body.hcfb-public-shell .hcfb-trust-marks-row {
	display: flex;
	flex-wrap: wrap;
	align-items: center;
	justify-content: center;
	gap: var(--wp--preset--spacing--hcfb-lg, 2.5rem);
	list-style: none;
	margin: 0;
	padding: 0;
}

/*
 * Staff Review homepage polish pass: the prior homepage-polish bump (~25%,
 * to clamp(3.1rem, 5vw, 4.4rem)) still read as too small to make out the
 * baked-in "Four-Star"/"Platinum" artwork at normal desktop viewing
 * distance -- confirmed by direct visual inspection. Sized up again to
 * roughly the smallest step where that artwork (small five-star row plus
 * "FOUR-STAR" caption; circular "Platinum" seal text) is comfortably
 * legible without reading as oversized against the rest of the footer.
 * Both supplied source files are square (554x554, 2000x2000), but their
 * MARKS are not equally inset from those canvas edges (see the two
 * modifier rules below) -- shared height plus width:auto is still the
 * right base (no distortion), the per-mark override is what balances
 * perceived weight.
 */
body.hcfb-public-shell .hcfb-trust-marks-row__logo {
	display: block;
	width: auto;
	height: clamp(4.5rem, 7vw, 6.5rem);
	max-width: 100%;
	object-fit: contain;
}

/*
 * Staff Review Round 1 (final visual tweaks pass): Charity Navigator's
 * badge fills almost its entire square canvas edge to edge, while
 * GuideStar's circular seal sits well inset from its own canvas with a
 * lot of transparent margin around it -- at the same bounding height
 * (confirmed by direct visual inspection composited on the footer's navy
 * background) Charity Navigator reads substantially heavier. Sized
 * individually for roughly equal perceived weight instead of an
 * identical box: Charity Navigator down slightly, GuideStar up
 * slightly, landing close to the same overall average size as before.
 */
body.hcfb-public-shell .hcfb-trust-marks-row__logo--charity-navigator {
	height: clamp(4rem, 6.2vw, 5.8rem);
}

body.hcfb-public-shell .hcfb-trust-marks-row__logo--guidestar {
	height: clamp(5rem, 7.8vw, 7.2rem);
}

/*
 * Staff Review Round 1 -- footer content pass: the legal/registration
 * paragraph and the USDA equal-opportunity-provider link, in their own
 * group below the four content columns. A capped measure keeps the long
 * registration sentence from stretching the full footer width into one
 * hard-to-read line. The divider that used to live here moved up to
 * `.hcfb-trust-marks-section` above, once that section became the first
 * thing below the four-column grid.
 */
body.hcfb-public-shell .hcfb-footer-legal {
	max-width: var(--hcfb-home-wide);
	margin: 0 auto;
	padding-top: var(--wp--preset--spacing--hcfb-md, 1.5rem);
}

/*
 * Staff Review homepage polish pass: the legal/registration paragraph,
 * the equal-opportunity-provider link, and the bottom copyright line are
 * the least-important reading in the footer (fine print, not the wording
 * itself, which is unchanged) -- a modest step down from the theme's
 * "small" preset (0.875rem) reads as deliberately de-emphasized fine
 * print rather than shrinking to a size that would compromise
 * readability. Still a real rem value (scales with user font-size
 * preferences, never a fixed px), well above any WCAG minimum.
 */
body.hcfb-public-shell .hcfb-footer-legal p,
body.hcfb-public-shell .hcfb-footer-copyright {
	font-size: 0.8125rem;
}

body.hcfb-public-shell .hcfb-footer-legal p {
	max-width: 50rem;
}

/*
 * Visible keyboard-focus indicator for every footer link -- the browser
 * default focus ring is frequently a blue similar in luminance to this
 * section's navy background (low contrast); this footer explicitly uses
 * the same light "surface" color as its text/icons so a keyboard user can
 * always see which link is focused.
 */
body.hcfb-public-shell .hcfb-site-footer--home a:focus-visible {
	outline: 2px solid var(--wp--preset--color--hcfb-surface);
	outline-offset: 2px;
}

/*
 * Pass 4 (§1): a single, reusable class for every local-review/dev-only
 * annotation across the homepage (rights labels, preview badges,
 * provisional-use prose, "heading placeholder" parentheticals, etc.) --
 * consolidates what was previously several one-off selectors
 * (.hcfb-footer-placeholder-copy above stays as-is, already working) into
 * one class so future annotations only need one thing to remember. Applies
 * the identical `hcfb-clean-screenshot` body-class mechanism (functions.php)
 * as the request-scoped `?hcfb_clean_screenshot=1` toggle. Never removes
 * anything for a normal visitor/developer request -- only this one visual-
 * review capture mode.
 */
body.hcfb-clean-screenshot .hcfb-clean-hide {
	display: none;
}

/*
 * Pass 6B: at stacked (mobile/narrow) widths the footer columns lay out
 * full-height one after another rather than side-by-side, so unlike the
 * desktop row (where a column's height only matters if it's the *tallest*
 * one) every column's height adds directly to the page's total. This
 * targeted mobile tightening (reduced outer padding and inter-column gap)
 * claws back what it reasonably can without shrinking type below a
 * comfortable, touch-friendly size.
 */
@media (max-width: 900px) {
	body.hcfb-public-shell .hcfb-site-footer--home {
		padding-top: var(--wp--preset--spacing--hcfb-2xl, 2rem) !important;
	}

	body.hcfb-public-shell .hcfb-footer-columns {
		row-gap: var(--wp--preset--spacing--hcfb-lg, 1.25rem);
		margin-bottom: var(--wp--preset--spacing--hcfb-md, 1.25rem);
	}
}