/* * Home hero card — hero over a customizable background image, rendered as an * inset card surface (16px from the page edge, rounded, overflow hidden) and * sized by content plus vertical padding rather than by any viewport unit. * Only enqueued on pages carrying .idia-hero-card — see * maybe_enqueue_hero_card() in functions.php. */ /* ---- Wrapper: inset only, no rail ---- The wrapper reproduces the reference's .header-block: a 16px inset from the page edge (via .is-surface-card in style.css) and NOTHING else — no padding of its own. WordPress adds .has-global-padding to it because it is a constrained-layout group, which puts the 32px rail OUTSIDE the cover. Measured before this rule at 1440/991/767/479: wrapper 16/1408 with padding-inline 32/32/20/20, so the cover started at 48/48/36/36 and ran 1344/895/695/407 — 64px (40px below 767) narrower than the reference's .hero-section, which is the full 1408/959/735/447 at x=16. The background and image surface were therefore short by that much at every width. The reference puts the rail INSIDE the box, on .container. Zero it here and supply it on the inner container instead (see below), which moves the box out to full width without moving any text. Scoped to .idia-hero-card__wrapper deliberately. .has-global-padding is on 8-10 elements per page and every other section depends on it — a general rule here would move /about, /contact and every inner page. */ .idia-hero-card__wrapper.has-global-padding { padding-left: 0; padding-right: 0; } /* ---- Card inner layout ---- The Cover block doesn't expose a way to add a custom class to its own inner-container div, so this targets it structurally instead of by class. .idia-hero-card itself is also a flex container (core's own .wp-block-cover base style), and contentPosition: "top left" gives it core's is-position-top-left class, which sets align-items: flex-start on THIS element. That means its flex child — .wp-block-cover__inner-container — is sized by its own content on the cross axis, not stretched to the card's full height, no matter what height value is set on the child itself: setting an explicit height on the child doesn't fix this either — confirmed in the browser that height:100% on the inner container computes short of the card's actual height (a known percentage-height quirk in flex cross-axis sizing), where plain height:auto plus the parent's align-items:stretch resolves correctly. So the fix is two parts: override align-items on the parent, and leave the child's height at auto rather than fighting it with a percentage. Selector matches core's own .wp-block-cover.is-position-top-left (two classes) plus .idia-hero-card, so three classes beats it on specificity without needing !important — core's rule only sets align-items, nothing else on this block needs to survive from it. */ .wp-block-cover.is-position-top-left.idia-hero-card { align-items: stretch; /* Radius set here, not as a block border-radius attribute, because no border-radius PRESET can step at a breakpoint. WordPress emits every preset at :root, and a var() inside a custom-property declaration is substituted where that property is DECLARED — so --wp--preset--border-radius--xl bakes in --wp--custom--radius--24's :root value (24px) and never sees the `html body` override that steps it to 16px at <=767px (style.css). Measured: with the xl preset on the block, the cover computed 24px at 767 and 479 while the wrapper correctly computed 16px. Referencing the custom property directly on an element (rather than inside another custom property) resolves at use time and therefore steps correctly: 24/24/16/16 across 1440/991/767/479, matching the reference's .hero-section. This is the same token .is-surface-card applies to the wrapper, so the two corners agree; the wrapper's overflow:hidden clips this one anyway, but they are kept in sync rather than left to differ. */ border-radius: var(--wp--custom--radius--24); /* Kept for the hero's own absolutely-positioned children. It is no longer the containing block for the nav: the nav is now the global header template part, a sibling of
, so it anchors to the initial containing block instead — see .idia-header--over-hero-dark in assets/css/header.css. */ position: relative; /* No min-height here on purpose. The hero is sized by content plus the inner container's vertical padding (see below), never by a viewport unit — the reference has no viewport-height rule on the hero at any width, and an earlier min-height:92vh was removed because it left ~131px of dead space below the CTA row at 1440px. Worth knowing about core, though it is not acted on here: WordPress injects an inline `@media (max-width: 781px) { .wp-block-cover:not (.has-aspect-ratio) { min-height: 430px !important; } }` — found by walking document.styleSheets in-browser, not documented anywhere. It is !important, so no plain selector can beat it regardless of specificity. Below 782px it therefore sets a 430px floor on this cover. In practice the hero's own content + padding exceeds 430px at those widths, so the floor never binds and nothing counteracts it. If that ever changes, measure it before adding a rule. */ } /* .idia-hero-card is flex-direction: row (core's own .wp-block-cover base style, untouched by the align-items override above — that override only reaches the cross axis, height). On a row, width is the main axis, and the inner-container's default flex-grow: 0 leaves it shrunk to its own content width instead of spanning the card — confirmed in the browser: without flex-grow: 1 the inner-container stops hundreds of px short of the card's right edge, which is what was pulling the bottom-right actions block back toward the left instead of the true right edge. */ .idia-hero-card > .wp-block-cover__inner-container { display: flex; flex-direction: column; flex-grow: 1; justify-content: space-between; /* Vertical padding is what sizes the hero — there is no min-height on the cover (see above). These two tokens reproduce the reference's .hero-section padding: spacing--196 resolves 196/120/80/140px and spacing--hero-bottom resolves 44/36/24/24px across 1440/991/767/479, both through their own breakpoint steps in style.css, so no media query is needed here. padding-bottom was spacing--44 (44/44/36/32) until the geometry pass against the live reference: it matched only at 1440 and ran 8/12/8px long at the other three widths. spacing--hero-bottom exists solely to carry the reference's 44/36/24/24 curve, exactly as spacing--196 carries the top one. This is the rail — 32px at >=768px, 20px below, stepping on its own through --wp--custom--rail in style.css, matching .container in the reference exactly. It lives HERE and not on the wrapper: the wrapper's own has-global-padding is zeroed above so the cover can span the full inset width, so this is the only place the rail is applied. Applying it in both places doubles it to 64px and pushes every text element 32px right — if the h1 or badge move off 48/48/36/36, that is what happened. */ padding-top: var(--wp--preset--spacing--196); padding-bottom: var(--wp--preset--spacing--hero-bottom); padding-left: var(--wp--custom--rail); padding-right: var(--wp--custom--rail); } /* ---- Lower row ---- Meta stats (left) and the existing actions column (right) side by side, both anchored to the row's bottom edge so short and tall content align on their baseline rather than their tops. */ .idia-hero-card .idia-hero-card__lower { align-items: flex-end; /* Separation from the intro paragraph above. The inner container's own blockGap (spacing--24) is what applied here before, which put 24px between the intro and this row against the reference's 80px — measured 80/80/80/48 across 1440/991/767/479 on stodio.webflow.io, where it comes from .hero-content-wrapper's top padding. spacing--80 (80/60/40/40) is the closest token in the scale: exact at 1440, short by 20/40/8 at the narrower widths. No closer token exists — the next candidates are spacing--120 (120/80/60/80) and spacing--64 (64/52/48/24), both worse overall. Left on the existing token rather than adding a new one; if the narrower breakpoints need to match the reference exactly, that is a new spacing token and an explicit decision. Two things here are load-bearing against core, which sets this gap via ":root :where(.is-layout-flow) > * { margin-block-start: ... }": 1. The property is margin-block-start, matching core's. A margin-top declaration does not override a margin-block-start one on the same element regardless of specificity — they are different properties, and the logical one resolves last. 2. The selector is scoped to .idia-hero-card, not the bare .idia-hero-card__lower class. Core's selector scores (0,1,0) — :root contributes one class-equivalent, :where() contributes zero — which TIES a single class. Ties go to source order, and core emits its rule in an inline