/* ========================================================================== nav-offset.css — clear the FIXED top nav on app-layout pages -------------------------------------------------------------------------- PROBLEM layouts/app.php pairs the FIXED top nav (.nav / .nav.sb-chrome-nav → position:fixed; inset-block-start:0; height:var(--nav-h) — layout.css) with a plain, un-offset
. A fixed nav is removed from normal flow, so any page whose top content wrapper does NOT reserve >= var(--nav-h) of top clearance renders UNDER the nav (portal home, checkout start/return, posts feed, nutrition, exercises, courses verify, player, etc.). SCOPE (collision-safe) Scoped strictly to body.l-app — the class this file's owner adds to layouts/app.php ONLY. It therefore never touches: - marketing / auth / error (site.css sticky in-flow nav — no overlap) - dashboard / admin console (sidebar + in-flow .topbar shell; its .content also carries id="main", so scoping to body.l-app keeps this rule off it entirely) - standalone admin.php (site.css sticky nav) No blanket main{padding-top}; no edits to layout.css / components.css / primunity.css / sitebuilder.css / SiteBuilder templates / partials/nav.php / Portal. Uses var(--nav-h) so it tracks the nav height the other editor owns. NO DOUBLE-OFFSET Wrappers that already reserve their own top clearance are excluded via :has(> …) so their offset is zeroed (they keep, never stack, their space): .book-wrap calc(var(--nav-h)+var(--s-10)) (scheduling.css) — robust .crs-landing calc(var(--nav-h)+…) (course.css) — robust .section var(--s-20) top pad (layout.css) — keeps 80px .sb-site first-block clearance (sitebuilder.css)— left as-is (The tenant public SiteBuilder site (.sb-site) is intentionally left to its own clearance; a var(--nav-h)-robust fix for it must live in a SiteBuilder-owned file — reported as a blocker, not clobbered here.) :has() is pure CSS (CSP-safe) and broadly supported; the child combinator matches because every listed wrapper is yielded as the DIRECT child of
(content is emitted straight into
). ========================================================================== */ /* Default: reserve exactly the fixed-nav height on app-layout pages. */ body.l-app #main { padding-block-start: var(--nav-h); } /* Exclude wrappers that already compensate — zero the offset so nothing double-offsets; each keeps its own existing top clearance. NOTE: this list governs VERTICAL offset only; the horizontal rules below are independent of it and neither list affects the other. Re-reviewed alongside the horizontal fix — still correct, left functionally unchanged. */ body.l-app #main:has(> .book-wrap), body.l-app #main:has(> .crs-landing), body.l-app #main:has(> .section), body.l-app #main:has(> .sb-site) { padding-block-start: 0; } /* ========================================================================== HORIZONTAL ALIGNMENT — nav rail vs. page content ("this doesn't align with the top nav bar") -------------------------------------------------------------------------- PROBLEM (two independent mismatches, both horizontal — vertical is already correct at exactly var(--nav-h) and is NOT touched here) (1) WIDTH: 1320 vs 1200. layout.css:15 .nav__inner max-width: var(--container-wide) 1320px …but every other wrapper in the system uses var(--container) 1200px: layout.css:146/151 .footer__grid / .footer__bottom portal-home.css:10 .phome portal-plan.css:9 .pplan portal-settings.css:12 .pset,.pmeas portal.css:8 .portal sitebuilder.css:866 .sb-site .section > * So on app-layout pages the nav is 120px wider than all content and the brand/links overhang each content edge by 60px. site.css:275 already sets the MARKETING .nav__inner to var(--container), so 1200 is the design system's own precedent — the app bundle is the outlier. Verified safe: .nav__inner is the only LIVE --container-wide consumer on body.l-app (.hero__inner is landing.php/marketing-only, .container--wide is unused), so narrowing it introduces no new mismatch and also lines the SiteBuilder chrome nav up with .sb-site .section > *. (2) GUTTER: nav is inset, portal wrappers are not. .nav__inner and .sb-site .section > * both carry padding-inline: var(--s-6); the portal wrappers carry only max-width + margin-inline: auto. Equal max-width alone is not enough — below 1200px the portal content runs to the viewport edge while the nav stays inset, so the edges only agree on very wide screens. Matching the gutter makes them agree at EVERY width. WHY IT LIVES HERE nav-offset.css is linked from layouts/app.php AFTER primunity.css, and these selectors are body.l-app-scoped (0,2,1) vs the originals' (0,1,0) — so they win on both cascade order and specificity, including over the per-page module CSS that yield_section('head') emits after this file. No edit to layout.css / portal-*.css is required. PERMANENT HOME: fold (1) back into layout.css:15 (change --container-wide to --container) once the in-flight layout.css rewrite lands, then delete the rule below. ========================================================================== */ /* (1) Match the nav rail to the content rail every other wrapper uses. */ body.l-app .nav__inner { max-width: var(--container); } /* (2) Give the app-layout content wrappers the nav's own horizontal inset. Logical property (padding-inline) keeps RTL/LTR symmetric. Safe with the global border-box (base.css:6) + these wrappers' max-width/margin-inline: auto — the padding eats into the 1200px rail rather than adding to it, so it can never push past 100% and raise a horizontal scrollbar. */ body.l-app .phome, body.l-app .pplan, body.l-app .pset, body.l-app .pmeas, body.l-app .portal { padding-inline: var(--s-6); }