/*
 * Food Finder visual foundation. Every rule in this file is scoped under
 * body.hcfb-food-finder-experience (added in functions.php only when
 * templates/template-food-finder.html is the active page template — see
 * hcfb_is_food_finder_template() there), so nothing here can affect the
 * homepage, any other landing template, or a normal interior page.
 *
 * This page needs exactly one release, not the full "prominent page"
 * shell treatment (assets/css/prominent-sections.css's
 * hcfb-prominent-experience context): public-shell.css's
 * `body.hcfb-public-shell:not(.home) #hcfb-primary-content` rule already
 * gives every non-home template a centered, padded ~82rem (1312px) shell
 * unconditionally — exactly the wide, contained measure this page wants.
 * The only thing missing is that `.wp-block-post-content` itself carries
 * no align="wide"/"full" of its own, so WordPress core's layout support
 * still caps it at theme.json's contentSize (720px) as a literal `width`,
 * not just `max-width` — a child can never exceed a definite-width parent.
 * Releasing only that one property here (not padding-inline, not
 * margin-block-start, not the shared blockGap seam fixes those other
 * templates need) is deliberate: this page has exactly one direct child
 * of wp:post-content (the [hcfb_food_finder] shortcode's own <section>),
 * so there is no multi-section seam to fix, and the shell's existing
 * padding-inline is exactly the breathing room the finder's own edge-to-
 * edge card/map panels want to sit inside rather than break out of.
 *
 * Net effective content width: ~82rem shell minus 2 * the shell's own
 * 2.5rem padding-inline ≈ 1232px on desktop — inside the requested
 * ~1200–1280px target.
 */
body.hcfb-public-shell.hcfb-food-finder-experience #hcfb-primary-content .wp-block-post-content {
	max-width: none;
	width: 100%;
}