/* * Fix: mobile menu doesn't open to full screen (worked on some pages, * not others). * * Root cause: assets/css/styles.css gives .site-header an unconditional * `backdrop-filter: blur(18px)` rule. Per spec, `backdrop-filter` (like * `transform`/`filter`/`perspective`) makes an element the *containing * block* for any `position: fixed` descendant. The mobile ".main-nav" * panel is a descendant of ".site-header" and relies on * "position:fixed;inset:0" to fill the screen -- but with that containing * block in place, "inset:0" fills the ~70-96px header bar instead of the * viewport. Because every page shares the same header.php, this isn't a * per-page CSS difference -- inconsistent behaviour across pages points * to caching (a caching/minification plugin serving an old CSS bundle on * some URLs) rather than the theme. To make this fix immune to that * class of problem entirely, nav-portal.js also moves the panel to be a * direct child of on every page load, so it can never again be * trapped inside a containing block the header (or any plugin) creates, * on any page, regardless of caching. */ @media (max-width: 1000px) { .site-header { backdrop-filter: none !important; -webkit-backdrop-filter: none !important; } } /* * nav-portal.js moves .main-nav to and toggles this class instead * of relying on the ".nav-toggle:checked ~ .main-nav" sibling selector, * which stops matching once the panel is no longer a sibling of the * checkbox. These rules replace that selector's job and additionally * force the open panel to fill the viewport and sit above the WP admin * toolbar (shown only to logged-in users). */ @media (max-width: 1000px) { .main-nav.nav-open { transform: none !important; position: fixed !important; inset: 0 !important; top: 0 !important; width: 100% !important; height: 100vh !important; height: 100dvh !important; max-height: none !important; display: flex !important; flex-direction: column !important; overflow-y: auto !important; z-index: 100000 !important; } } body.admin-bar .main-nav.nav-open { top: 32px !important; height: calc(100vh - 32px) !important; height: calc(100dvh - 32px) !important; } @media (max-width: 782px) { body.admin-bar .main-nav.nav-open { top: 46px !important; height: calc(100vh - 46px) !important; height: calc(100dvh - 46px) !important; } } /* * Fix: mobile menu worked right after a page loaded, then stopped working * once loading finished (and worked on short pages like Contact, not on * long ones like Home/Process). * * Root cause: assets/css/styles.css also has `.motion-ready body{overflow-x: * clip}`. app.js adds the "motion-ready" class to once it runs -- * which is *after* the browser reports the page interactive, explaining * why a click during that brief window (before the class lands) still * worked. In modern browsers, `overflow: clip` on an element behaves like * `contain: paint` for descendants: it establishes a containing block for * `position: fixed` elements, same class of bug as the .site-header fix * above -- except this time on itself, which is where nav-portal.js * moves the panel specifically to escape that kind of problem. Since body's * own height is its full scrollable content height (short on Contact, * very long on Home/Process), the panel would size/position itself against * that instead of the viewport -- fine-ish on a short page, broken on a * long one. Lifting the clip only while the panel is actually open is safe: * it exists to stop motion/parallax effects bleeding horizontally during * normal scrolling, and the open panel is an opaque full-screen overlay * covering everything anyway. Both axes are reset (not just overflow-x) * because the CSS Overflow spec pairs a "clip" axis with a non-"visible" * computed value on the other axis too, so leaving overflow-y alone could * still leave a containing block in place. */ body:has(> .main-nav.nav-open) { overflow: visible !important; } /* * Fix: the burger/close (X) icon disappears behind the open panel, making * it impossible to close the menu. * * Root cause: nav-portal.js moves .main-nav to be a *sibling* of * .site-header (both direct children of ), so the panel's * z-index:100000 (needed to clear the WP admin bar above) is now compared * directly against .site-header's own z-index (80) -- and loses. Since an * element's z-index can never lift it above its own parent's stacking * context, simply raising the button's z-index wouldn't help; the header * itself has to be raised. The original static design already reserves * space for the header to stay visible above the open panel (.main-nav * has "padding-top: 80px" specifically for this), so this restores that * intent rather than working around it. */ @media (max-width: 1000px) { body:has(> .main-nav.nav-open) .site-header { z-index: 100001 !important; } }