and spans the TRUE viewport, so there is no inset to subtract and the offset is the reference's own 12px + rail. Measured with the old calc still in place: logo at 28px, 16px short — the subtraction was compensating for a box offset that no longer exists. The 12px is the reference's literal .navbar padding and has no token: the scale's 8 -> 12 presets resolve to --wp--custom--gap--* customs that step at breakpoints, whereas this value is flat at every width. Colour is NOT set here. Link colour, background and the CTA's style variation stay with theme.json presets and block style variations so the owner keeps them in the Site Editor (AGENTS.md §0). These variants govern placement and transparency only. top is section-inset (16px) plus the admin-bar offset, matching the default sticky header below and the reference's own permanent .header-block margin-top: 16px (never a hero-only value, never zero once scrolled). Expanded from the reference's `inset: 0 0 auto` shorthand to longhand sides so the top slot can carry that calc() while right/bottom/ left stay the reference's literal 0/auto/0 — inset's shorthand can't mix a token+var() calc in one slot with plain values in the others. */ /* The variant class is applied by the template, so it lands on the OUTER

template-part wrapper. The inner .idia-header group is what actually carries the background, the border and — because it is a constrained group — WordPress's own `has-global-padding` rail. Both elements therefore need addressing, and the rail is why: Measured with the offset on the wrapper alone, the logo sat at 60px = the variant's 28px offset PLUS the inner group's 32px global padding. That is AGENTS.md §8.1a's `has-global-padding` trap, two levels each supplying a rail. The fix is NOT to subtract 28 from the offset — that is the compensating offset §8.1 forbids — but to keep the horizontal offset on one element and zero the other's rail, scoped to this variant so no other section's `has-global-padding` is affected. */ .idia-header--over-hero, .idia-header--over-hero-dark { position: absolute; top: calc(var(--wp--custom--section-inset) + var(--wp-admin--admin-bar--height, 0px)); right: 0; bottom: auto; left: 0; z-index: 3; padding-left: calc(12px + var(--wp--custom--rail)); padding-right: calc(12px + var(--wp--custom--rail)); border-radius: var(--wp--custom--radius--8); background-color: transparent; } /* The inner group: drop the rail it would otherwise re-apply (the offset above is the variant's only horizontal padding) so the hero shows through. Also drop the pattern's own padding-bottom: 24px block attribute. That value is right for the default solid bar (top/bottom breathing room on a filled background) but the reference's own .navbar has NO bottom padding at all — its row height is padding-top + content only, confirmed via inspect_design on stodio.webflow.io/contact: .navbar computed padding-bottom: 0px, height 85px, vs ours at 130px before this fix (the missing 24px accounted for most of that 45px gap). Scoped to the two variants so the default sticky bar keeps its own bottom padding. padding-bottom needs !important: the block sets padding-bottom as a real style attribute (so the owner can edit top padding from the Dimensions panel), which core renders as an inline `style` on the element — inline styles beat any external stylesheet selector regardless of specificity, the same reason the background-color rule below already needs it. */ .idia-header--over-hero > .idia-header, .idia-header--over-hero-dark > .idia-header { padding-left: 0; padding-right: 0; padding-bottom: 0 !important; } /* Background needs !important, and this is the one place it is unavoidable rather than a shortcut. The pattern sets backgroundColor as a real block attribute — deliberately, so the site owner can change the default header's colour from the Site Editor (AGENTS.md §0) — and WordPress renders that as core's own preset class: .has-base-background-color { background-color: ...!important } The !important is core's, in its global stylesheet, on a single class. No selector can outrank it, so the choice is between matching it here or removing the block attribute — and removing it would take the default header's background out of the owner's hands to fix a variant that is the exception. Scoped to the two variant classes, so the default header is untouched and the Styles panel still drives it. */ .idia-header--over-hero > .idia-header, .idia-header--over-hero-dark > .idia-header { background-color: transparent !important; } /* The reference drops .navbar's padding-top from 32 to 24 at <=991 and holds a flat 24 down through 479 — reproduced in the breakpoint blocks below. */ /* Light hero (contact, projects, single-project): the card is #f3f3f3, on which the header's default `main` link colour is already correct, so no colour override is needed — and the black-on-transparent logo is right as uploaded, which is why there is deliberately no invert() here. */ /* Dark hero (front page): the hero is a dark photograph, so links must be base (white). The pattern sets `main` (near-black) as a link-colour block attribute, which is right for the solid bar every other page renders, and theme.json's core/navigation styles add a `primary` rule on top — measured before this rule, the homepage nav read rgb(224,225,25), the yellow primary, against a dark photo. Restated here for the dark variant only. Both are presets, so the owner still changes the actual colours in the Site Editor; this only decides WHICH preset applies over a dark hero. The selector carries the variant class plus the same two classes core's own navigation rule uses, so it wins on specificity without !important. */ .idia-header--over-hero-dark .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__container a, .idia-header--over-hero-dark .idia-header__nav a, .idia-header--over-hero-dark { color: var(--wp--preset--color--base); } /* The logo: core/site-logo holds exactly one image and the uploaded mark is black on transparent, correct for the solid bar and for this variant's own scrolled state. Over the photograph it needs the white version, and invert(1) on a pure-black-on-transparent mark yields exactly that — so the owner can still replace the logo from Appearance → Editor with no code change, which a hardcoded second would have prevented. */ .idia-header--over-hero-dark:not(.idia-header--solid) .wp-block-site-logo img { filter: invert(1); } .idia-header--over-hero-dark.idia-header--solid .wp-block-site-logo img { filter: none; } /* Colour transition for the transparent -> solid handover. The colours themselves are block attributes and presets, not written here. No transform entry: this header no longer animates position (see the removed reveal-on-scroll-up behaviour above), only colour. */ .idia-header--over-hero, .idia-header--over-hero-dark { transition: background-color 400ms cubic-bezier(0.32, 0.72, 0, 1), border-color 400ms cubic-bezier(0.32, 0.72, 0, 1), color 400ms cubic-bezier(0.32, 0.72, 0, 1); } /* Nav link type on the over-hero variants — matched to the reference's .nav-link: regular weight with body line-height and tracking, so the nav reads as navigation rather than a row of small headings. The size is the block's own `small` preset (18px) and is deliberately not restated. */ .idia-header--over-hero .idia-header__nav a, .idia-header--over-hero-dark .idia-header__nav a { font-weight: var(--wp--custom--font-weight--regular); line-height: var(--wp--custom--line-height--body); letter-spacing: var(--wp--custom--letter-spacing--body); transition: color 400ms cubic-bezier(0.32, 0.72, 0, 1); } .idia-header--over-hero .idia-header__nav a:hover, .idia-header--over-hero .idia-header__nav .current-menu-item > a, .idia-header--over-hero-dark .idia-header__nav a:hover, .idia-header--over-hero-dark .idia-header__nav .current-menu-item > a, /* The dark variant's base-colour rule above (line ~310) restates itself via `...responsive-container:not(.is-menu-open) .wp-block-navigation__container a` at (0,4,1) — one class ahead of the plain `.current-menu-item > a` rule just above (0,3,1) — so it silently overrode the active-link colour at rest, not only in the solid state. Matched here at (0,5,1) to win. */ .idia-header--over-hero-dark .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__container .current-menu-item > a { color: var(--wp--preset--color--primary-dark); } /* Dark-offset focus ring, so it reads against any photograph including a light one where a plain white ring would disappear. */ .idia-header--over-hero-dark a:focus-visible { outline: 2px solid var(--wp--preset--color--base); outline-offset: 3px; box-shadow: 0 0 0 5px rgba(0, 0, 0, 0.45); } /* ---- Solid state, dark over-hero variant only ---- Once the hero has scrolled past (--solid, set by the IntersectionObserver in header-scroll.js), the bar switches to the same solid treatment every other page's header uses: base background and `main` link colour, logo un-inverted. No positioning change — this header is `position: absolute` over the hero (see the shared rule above) and simply scrolls away with it once the hero is gone. It used to also reveal itself as a `position: fixed` bar on an upward scroll (`--nav-revealed`); that has been replaced by a sitewide back-to-top FAB (assets/js/back-to-top.js), so there is no reason for this one header to re-pin itself to the viewport. Restated at the same specificity as the transparent rules above, which is why the background needs !important here too — it is overriding the same core preset class, not this file. No border: the reference's .navbar has none at any state, including this scrolled-solid one — confirmed, the reference has no scrolled/solid navbar variant at all. */ .idia-header--over-hero-dark.idia-header--solid > .idia-header { background-color: var(--wp--preset--color--base) !important; } .idia-header--over-hero-dark.idia-header--solid .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__container a, .idia-header--over-hero-dark.idia-header--solid .idia-header__nav a, .idia-header--over-hero-dark.idia-header--solid { color: var(--wp--preset--color--main); } /* The current-menu-item highlight above is set at (0,4,1) — already ahead of the plain `.idia-header__nav a` half of the solid-state repaint two rules up (0,3,1), but that repaint's OTHER selector, `...responsive-container:not(.is-menu-open) .wp-block-navigation__container a`, is (0,5,1): the variant+solid compound (2 classes) plus responsive-container, :not(.is-menu-open), and container (3 more). That beats the current-menu-item rule regardless of source order, so the active-page highlight was silently erased the moment header-scroll.js added --solid. Restated with the same responsive-container/:not/container prefix, swapping in .current-menu-item > a for the bare a, to reach (0,6,1) and win outright. */ .idia-header--over-hero-dark.idia-header--solid .idia-header__nav .current-menu-item > a, .idia-header--over-hero-dark.idia-header--solid .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__container .current-menu-item > a { color: var(--wp--preset--color--primary-dark); } @media (prefers-reduced-motion: reduce) { /* The transparent -> solid handover is a colour change only now (the position transform it used to share this declaration with is gone — see the comment above), so this simply applies that colour change instantly instead of animating it. */ .idia-header--over-hero, .idia-header--over-hero-dark, .idia-header--over-hero .idia-header__nav a, .idia-header--over-hero-dark .idia-header__nav a { transition: none; } } /* Header CTA — the plain system button. Step 6 removed the whole pre-step-5 override that used to sit here: a literal 9999px radius (the pill token is 44px), a hardcoded primary background and base colour, font-size x-small, padding 16/24, and a background-color + transform transition. Every one of those fought theme.json's elements.button, which already supplies base font-size, weight 500, padding 12/20 and the pill -> 16px hover. Colour now comes from the block's style variation, so the site owner can switch this button between Brand, Light and Dark from the editor's Styles panel instead of it being locked to red by this file. Step 5's .idia-hero-card__nav rules are deliberately NOT copied across: those exist because the hero nav is transparent over a photograph. The global header is a solid light bar and needs none of that treatment. */ .idia-header__cta-button .wp-block-button__link { display: inline-flex; align-items: center; gap: var(--wp--preset--spacing--8); transition: border-radius var(--wp--custom--transition) cubic-bezier(0.32, 0.72, 0, 1); } /* Trailing arrow — moved to a real .idia-btn-icon element in assets/css/button-roll.css (step 7), so button-roll.js can clone it for the hover text/icon roll; a pseudo-element cannot be cloned. Same glyph, same mechanism, shared by every button on the site. */ @media (prefers-reduced-motion: reduce) { .idia-header__cta-button .wp-block-button__link { transition: none; } } .idia-header__cta-button .wp-block-button__link:focus-visible { outline: 2px solid var(--wp--preset--color--primary-dark); outline-offset: 2px; } /* ---- Burger breakpoint: 991, matching the reference ---- The reference collapses to the burger at <=991. Core's `overlayMenu: mobile` collapses at a hardcoded 600px — NOT the 782px often assumed; 782 appears in core's navigation stylesheet only for submenu positioning and admin-bar offsets, and there is no setting or filter for the 600. Measured on /about/ before this change: burger hidden at 600, visible at 599. So the block is set to `overlayMenu: always` (the burger is the block's own state at every width, with no core breakpoint involved) and the horizontal row is restored here above 991. That inverts the control: the breakpoint becomes a theme value in one media query instead of a core constant we cannot reach. The overlay markup, the toggle button, its aria wiring and the focus trap are all core's own and unchanged. */ @media ( min-width: 992px ) { /* Above the breakpoint: the responsive container behaves as a plain horizontal row and the toggle is hidden. Mirrors what core's own min-width rule does at 600, applied at our breakpoint instead. */ .idia-header__nav .wp-block-navigation__responsive-container:not(.is-menu-open) { display: block; width: 100%; position: relative; z-index: auto; background-color: inherit; } .idia-header__nav .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__responsive-container-content { display: flex; } .idia-header__nav .wp-block-navigation__responsive-container-open, .idia-header__nav .wp-block-navigation__responsive-container:not(.is-menu-open) .wp-block-navigation__responsive-container-close { display: none; } } /* Core gives the burger toggle a hardcoded 3px border-radius, matching no token on our scale. It was invisible before this step because the button only rendered below 600px, on widths the audit does not walk for these pages; with overlayMenu "always" it renders at every width, so the audit now sees it. Normalised to the 8px token — the same radius the over-hero bar uses, and flat at every breakpoint. */ .idia-header__nav .wp-block-navigation__responsive-container-open, .idia-header__nav .wp-block-navigation__responsive-container-close { border-radius: var(--wp--custom--radius--8); } @media ( max-width: 991px ) { /* Reference .navbar padding-top: 32 above 991, 24 from 991 down to 479. No preset reproduces that curve — --wp--preset--spacing--32 resolves to 28px at this exact breakpoint (AGENTS.md §8.4), not 24px, so the pattern's block attribute (32px, correct above 991) needs a CSS override here rather than a different preset. The over-hero modifier class lives on the outer

wrapper, not on .idia-header itself (see the template-part className in front-page.html etc.), so this is excluded via the ancestor rather than the element's own class. The over-hero variants set their own padding-top in the block below, since they start from 24px, not this element's 32px base. */ :not(.idia-header--over-hero):not(.idia-header--over-hero-dark) > .idia-header { padding-top: var(--wp--preset--spacing--24); } /* No room for a true third column at this width: the CTA is hidden and the row becomes logo + burger. The grid collapses to two tracks with the toggle pushed to the right edge, so there is no centre column to claim and nothing to centre. The old `position: static; transform: none` reset that used to sit here is gone — it existed only to undo the desktop absolute-centring, which no longer exists. */ .idia-header__inner { grid-template-columns: 1fr auto; } nav.idia-header__nav { grid-column: 2; justify-self: end; } /* body prefix matches core's own body .is-layout-flex{display:flex} global-styles rule on this element's generated layout class — a bare class selector loses that specificity fight and the button stays visible despite this rule, confirmed via computed styles. */ body .idia-header__cta { display: none; } } /* ---- Over-hero responsive, from the reference ---- The reference drops .navbar's padding-top from 32 to 24 at <=991 and holds a flat 24 all the way down through 479, and raises the radius to 12 at 479. Padding is set here rather than as a block attribute because these variants are applied by the template, not by the pattern — there is no inline block-support style to outrank, so no !important is needed. Two tokens express the flat 24, because the spacing presets are named for their DESKTOP px and step down at breakpoints (AGENTS.md §8.4) — the slug is not the value at every width. Read out of style.css rather than assumed: preset 24 -> 24px flat at 1440/991/767, dropping to 16px only <=479 preset 32 -> 28px at <=991, 32px at <=767, 24px at <=479 So preset 24 is correct from 991 down to 480, and preset 32 is the token that resolves to 24px at <=479. */ @media (max-width: 991px) { .idia-header--over-hero, .idia-header--over-hero-dark { padding-top: var(--wp--preset--spacing--24); } } @media (max-width: 479px) { .idia-header--over-hero, .idia-header--over-hero-dark { padding-top: var(--wp--preset--spacing--32); /* The reference goes to radius 12 here. NOT --radius--12, which is the obvious choice and is wrong: the radius tokens are named for their DESKTOP value and several step down — style.css redefines --radius--12 to 4px inside this exact media query, so it would render a third of the reference's value while reading as 12. --radius--8 and --radius--16 are flat at every width; 12, 24 and 32 step. --radius--16 is therefore the stable token, but it resolves to 16px, not 12px. Carried over from contact-hero.css as a known 4px deviation rather than resolved: the honest fix is a flat 12px token, which is Tobi's call to add, not mine to invent (AGENTS.md §8.4). */ border-radius: var(--wp--custom--radius--16); } /* The reference adds a further 12px on .nav-link-block at its narrowest breakpoint, taking its logo to 12 + 20 + 12 = 44 — LARGER than its own 767 value of 32. That is stodio's own inconsistency; the owner confirmed matching it exactly rather than smoothing it, so it is reproduced here and must not be "corrected". Left edge only. */ .idia-header--over-hero, .idia-header--over-hero-dark { padding-left: calc(12px + var(--wp--custom--rail) + 12px); } }