/* ============================================================================ One Ocean — main stylesheet ============================================================================ Structure: 1. Design tokens ← EMPTY until Phase 1. Do not fill from memory. 2. Base / reset 3. Accessibility utilities 4. Layout primitives 5. Chrome (nav, footer) 6. Sections ← one banner-commented block per section, Phase 3 No build step. This file ships as authored and is cache-busted by its mtime (see ooc_asset_ver in functions.php), so an edit is live on the next request with no version bump. ========================================================================= */ /* ---------------------------------------------------------------------------- 1. DESIGN TOKENS ---------------------------------------------------------------------------- Source: Figma file KDzdMwrHDQ84s8t6bkF1tq ("OneOcean"). Read 2026-07-29 via get_variable_defs against frames 100:5838 (desktop home), 226:2032 (mobile home), 186:76 (services V2), 230:5104 (about), 130:661 (footer), plus the file's Text styles panel. Provenance per value is recorded in FIGMA.md. HARD RULE 1 — never code from a guess. A colour, size, font, radius or breakpoint that has not been READ FROM THE SOURCE does not get written here. Not from the old Lovable site, not from a screenshot, not from a reasonable assumption about what a premium seafood brand looks like. Two reasons this is a rule and not a preference: - Token NAMES lie. On a prior build a token called `bg` was #090909, near-black; the section was built light and had to be rebuilt. - A plausible-but-wrong palette is worse than none, because it looks finished and nobody re-checks it. So this block holds ONLY what has been read. Everything still unread is listed at the bottom as an explicit TODO rather than filled with a plausible value. Names below mirror the Figma style names exactly — the semantic layer (ink / surface / accent / border) is deliberately NOT mapped yet, because which literal serves which role is a design question, not a rename. -------------------------------------------------------------------------- */ /* ---------------------------------------------------------------------------- 1a. WEBFONTS ---------------------------------------------------------------------------- Self-hosted, not loaded from fonts.gstatic.com — one less third-party request, no visitor IP handed to Google (a GDPR point that has cost European sites real money), and it works offline for local fidelity runs. `unicode-range` is what makes two files cheaper than one: the browser fetches latin-ext ONLY if the page actually uses a character in that range. Do not "simplify" by dropping it — that forces both downloads on every page. Only Regular 400 exists in this family, and only h1–h5 use it. There is no italic and no bold: if a design node ever needs one, the browser will synthesise it (badly) — treat that as a spec question, not a CSS fix. `font-display: swap` shows fallback text immediately rather than blank text. ⚠️ The fidelity gate must therefore `await document.fonts.ready` before measuring, or it will occasionally screenshot Georgia and score a type miss that does not exist. -------------------------------------------------------------------------- */ /* latin-ext — accented characters only. */ @font-face { font-family: "Instrument Serif"; font-style: normal; font-weight: 400; font-display: swap; src: url("../fonts/InstrumentSerif-Regular-latin-ext.woff2") format("woff2"); unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF; } /* latin — the common case. */ @font-face { font-family: "Instrument Serif"; font-style: normal; font-weight: 400; font-display: swap; src: url("../fonts/InstrumentSerif-Regular-latin.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } :root { /* -- Colour ------------------------------------------------------------- */ /* Figma style names kept verbatim. */ --ooc-light: #F2E6D5; /* "light" — 100:5838, 226:2032 */ --ooc-light-2: #FFF9E9; /* "light 2" — all probed frames */ --ooc-navy-blue: #002765; /* "navy blue" — all probed frames */ /* Interaction states, read off the Button COMPONENT_SET (194:7) — the design DOES define hover and pressed, for both button types. These four hexes are not in the colour-styles panel; they exist only as variant fills. */ --ooc-navy-hover: #003880; /* Type=Primary, State=Hover 186:20 */ --ooc-navy-press: #001845; /* Type=Primary, State=Pressed 186:25 */ --ooc-cream-hover: #F2EDDE; /* Type=Secondary, State=Hover 191:4 */ --ooc-cream-press: #E0D9C9; /* Type=Secondary, State=Pressed 191:6 */ /* -- Type: families ----------------------------------------------------- Display is RESOLVED. Body is still a placeholder. ✅ --ooc-font-display — real. Instrument Serif Regular 400, SIL Open Font License, self-hosted from assets/fonts/ (see the @font-face block in §1a). Permanent; nothing further is owed. Georgia leads the fallback chain because it is the closest metric-ish serif if the woff2 fails. ⚠️ --ooc-font-sans — FONT-PLACEHOLDER, still a system stack. grep -rn FONT-PLACEHOLDER finds every line that has to change. Why the body face is still a placeholder even though a Suisse zip arrived: the supplied file was the Swiss Typefaces FREE TRIAL, and the trial webfonts are deliberately crippled — measured 2026-07-30 with fontTools, they carry a–z, A–Z and accents but **only the digit 0 (1–9 absent)** and almost no punctuation (no : ; ! ? ' " ( ) & @ # % © and no em/en dash). Four of five real strings from the design cannot render: "+1 347-782-6833", "©OneOcean 2026", both street addresses, and anything with a straight apostrophe. Each missing glyph silently falls back to another font mid-string, so line widths measure wrong AND look broken. Unusable for fidelity work, so the trial files were deleted rather than kept as a licence risk. Its EULA also forbids public display either way. Still owed: Suisse Int'l on a WEB licence, FOUR upright weights — Regular 400, Book 450, Medium 500, Semibold 600. No italics. See FIGMA.md → "Fonts". The swap is one value here plus a @font-face block. Nothing else in this stylesheet should need to change — every section must consume var(--ooc-font-display) / var(--ooc-font-sans), never a literal family. EXPECT BODY LINE COUNTS AND WRAP POINTS TO MOVE ON SWAP. That is the font changing, not a regression — do NOT tune sizes, leading or tracking to make the placeholder look right, or the real face will land wrong. Re-run the gate after the swap and treat the deltas as the new baseline. ---------------------------------------------------------------------- */ --ooc-font-display: "Instrument Serif", Georgia, "Times New Roman", Times, serif; /* LIGATURES ON DISPLAY TYPE. Not decoration — the design renders "refined" and "fish" with a joined f_i, and without this the browser draws a separate f and a dotted i. ⚠️ THE REASON IS letter-spacing, NOT the feature being off by default. Browsers switch ligatures OFF whenever letter-spacing is non-zero, and every display node in this file carries tracking (-2px). Measured in Chrome, "refined" at 100px: letter-spacing: 0 243.20 ligated letter-spacing: 0, liga off 243.81 not ligated letter-spacing: -2px 229.81 NOT ligated (243.81-7*2) letter-spacing: -2px + common-ligatures 229.81 still not ligated letter-spacing: -2px + "liga" 1 231.20 ligated (243.20-6*2) So `font-variant-ligatures: common-ligatures` does NOT bring them back — only font-feature-settings does. Do not "modernise" this to the font-variant syntax; it silently reverts the fix. "dlig" is carried because that is what the Figma nodes declare (100:6581, 100:6582, 228:3488, 228:3489, 228:3454). Our subset has no dlig feature at all — verified with fontTools, the woff2 exposes only ccmp/liga/ locl — so it is inert today and correct the day a fuller cut is installed. This was invisible to every geometry probe: the word occupies nearly the same box either way. It surfaced only from diffing the render against the Figma render pixel-for-pixel, which is why step 3 of the measure cycle is not optional. Paired with each `font-family: var(--ooc-font-display)` rather than set globally, because the body face wants a different list (the buttons declare "salt"/"ss01"/"ss04"/"ss06", which the placeholder does not have). */ --ooc-font-display-features: "liga" 1, "dlig" 1; /* FONT-PLACEHOLDER → Suisse Int'l (4 upright weights, see above). A neo-grotesk system stack, the closest basic match to Suisse Int'l. Note no system font has a real 450 cut, so --ooc-weight-book will be rounded by the browser until the licensed font lands. */ --ooc-font-sans: system-ui, -apple-system, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; /* -- Type: scale -------------------------------------------------------- */ /* Desktop values, from the Text styles panel. Mobile does NOT redefine these as variables — mobile sizes are set per text node and must be measured per section, not derived from this scale. */ /* ⚠️ h3's tracking is the ONLY one Figma stores as a PERCENT (-1%), not pixels — so it is -0.01em, i.e. -0.64px at 64px, NOT -1px. Reading the number without its unit produces a 0.36px-per-character drift that the gate would flag as a type miss with no obvious cause. */ --ooc-h1-size: 130px; --ooc-h1-lh: 130px; --ooc-h1-ls: -2px; --ooc-h2-size: 100px; --ooc-h2-lh: 100px; --ooc-h2-ls: -2px; --ooc-h3-size: 64px; --ooc-h3-lh: 68px; --ooc-h3-ls: -0.01em; --ooc-h4-size: 48px; --ooc-h4-lh: 48px; --ooc-h4-ls: -1px; --ooc-h5-size: 32px; --ooc-h5-lh: 36px; --ooc-h5-ls: 0; --ooc-body-m-size: 16px; --ooc-body-m-lh: 20px; --ooc-body-m-weight: 600; --ooc-body-s-size: 14px; --ooc-body-s-lh: 20px; --ooc-body-s-weight: 450; /* Body weights actually used by text nodes — NOT just the two the named text styles declare. Measured across 2,778 text segments on HP + IPs + Animation. `Medium 500` appears 712 times and has no text style at all. */ --ooc-weight-regular: 400; --ooc-weight-book: 450; --ooc-weight-medium: 500; --ooc-weight-semibold: 600; /* -- Container ---------------------------------------------------------- */ /* Reference frames: desktop HP V1 = 1440, mobile HP Mobile = 393 (NOT 375). Gutter derived by measuring the left/right inset of every non-hidden grandchild of both frames — 20px is the modal value at both widths, giving a 1400px desktop content column and 353px on mobile. */ --ooc-container-max: 1440px; --ooc-container-pad: 20px; /* mobile @393 */ --ooc-container-pad-lg: 20px; /* desktop @1440 */ /* -- Chrome heights ------------------------------------------------------ */ /* Desktop: the `main nav` component (211:3041) is 1440×80 — measured. Mobile: there is NO nav frame in the design, so this is DERIVED per Hard rule 2 and the derivation is recorded here. The logo (226:2206) is 56 tall at y=20 and the trigger (226:2265) is 44 tall at y=26 — both centre on y=48, so a 96px header with centred items reproduces both exactly. */ /* Dropdown chevron shape (100:5905) as a mask, so currentColor colours it. */ --ooc-chevron: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20width%3D%2216%22%20height%3D%2216%22%20viewBox%3D%220%200%2016%2016%22%20fill%3D%22none%22%3E%3Cpath%20d%3D%22M12.5%208L8.5%2012L4.5%208%22%20stroke%3D%22%23000%22%20stroke-width%3D%221.5%22%20stroke-linecap%3D%22square%22%2F%3E%3C%2Fsvg%3E"); /* Scroll-cue arrow (100:5982 / 228:2276) as a mask, so it takes currentColor. */ --ooc-arrow: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2020%2020%22%20fill%3D%22none%22%3E%3Cpath%20d%3D%22M10%203v14M4%2011l6%206%206-6%22%20stroke%3D%22%23000%22%20stroke-width%3D%221.5%22%2F%3E%3C%2Fsvg%3E"); /* Attribute separator (228:3791) as a mask, so it takes currentColor. */ --ooc-attr-sep: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2010%208%22%3E%3Cpath%20d%3D%22M4.85613%200C5.9842.106753%207.01272.240298%207.9512.851512C8.99869%201.5341%209.75945%202.53235%209.95141%203.67901C10.1339%204.73293%209.79736%205.80527%209.02714%206.6256C7.88485%207.8294%206.78759%207.92004%205.12393%208C4.1973%207.79466%203.26591%207.59245%202.34876%207.36136C1.38658%207.11959.628226%206.82927.201644%205.9698C-.227307%205.10698.0902462%204.14557.573705%203.35937C1.46242%201.92155%203.07159.503205%204.85613%200Z%22%2F%3E%3C%2Fsvg%3E"); /* Carousel pagination blob (228:3893, the first of its four paths) as a mask. ⚠️ NOT the same blob as --ooc-attr-sep: the control points differ and this one carries a y offset. Reusing the separator here would be close enough to look right and wrong enough to be a defect. */ --ooc-carousel-dot: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2015%2012%22%3E%3Cpath%20d%3D%22M6.68462%200.119027C8.31506-0.211%2010.5191%200.155788%2011.9268%201.08873C13.498%202.13062%2014.6392%203.65432%2014.9271%205.40454C15.2008%207.01323%2014.696%208.65002%2013.5407%209.90214C11.8273%2011.7396%2010.1814%2011.878%207.68589%2012C6.29594%2011.6866%204.89886%2011.3779%203.52313%2011.0252C2.07987%2010.6562%200.942339%2010.213%200.302466%208.90115C-0.340961%207.58417%200.135369%206.1167%200.860558%204.91665C2.19363%202.722%203.31332%201.27411%206.68462%200.119027Z%22%2F%3E%3C%2Fsvg%3E"); /* Numbered-badge blob (100:6754 / 230:3908) as a mask, so it takes a colour. The SAME blob as the carousel's drag cue (122:292) uniformly scaled — 77/77.6816 and 61/61.4034 — but that one ships as an SVG file because it carries a second navy arrow path and a mask can only hold one colour. Desktop draws it 77x61 and mobile 60x48, a NON-uniform scale (x by 60/77, y by 48/61), so size it `100% 100%` and never `contain`. Design fills it `light 2` #FFF9E9. */ --ooc-badge-blob: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20viewBox%3D%220%200%2077%2061%22%3E%3Cpath%20d%3D%22M34.3144%200.605053C42.684%20-1.07259%2053.9979%200.791924%2061.2242%205.53438C69.2899%2010.8307%2075.1477%2018.5761%2076.6258%2027.4731C78.0309%2035.6506%2075.4396%2043.9709%2069.509%2050.3359C60.7133%2059.6763%2052.2645%2060.3796%2039.4542%2061C32.3192%2059.4067%2025.1475%2057.8378%2018.0854%2056.0447C10.6766%2054.1689%204.83734%2051.9162%201.55266%2045.2475C-1.75027%2038.5529%200.694896%2031.0932%204.41753%2024.993C11.2606%2013.8369%2017.0084%206.47674%2034.3144%200.605053Z%22%2F%3E%3C%2Fsvg%3E"); --ooc-nav-h: 96px; --ooc-nav-h-lg: 80px; /* -- Fluid display ramp -------------------------------------------------- */ /* Linear interpolation between the two reference widths, so each expression is EXACT at 393 and at 1440 and proportional between (Hard rule 3). Verified: h1 = 1.936rem + 6.877vw → 58.00px @393, 130.00px @1440. The ramp is per-step because the design's scale is NOT uniform — 130→58 is ×0.45 while 48→40 is ×0.83. One global multiplier would be wrong. Bounds are `rem`, not `px`: a px-bounded clamp() ignores the reader's browser font-size entirely, which fails WCAG 1.4.4. Keeping a rem term in the preferred value preserves user scaling and still lands on the designed px at both references. */ --ooc-fluid-h1: clamp(3.625rem, 1.936rem + 6.877vw, 8.125rem); /* 58 → 130 */ --ooc-fluid-h2: clamp(3.125rem, 1.952rem + 4.776vw, 6.25rem); /* 50 → 100 */ --ooc-fluid-product: clamp(2.5rem, 2.312rem + 0.764vw, 3rem); /* 40 → 48 */ --ooc-fluid-h5: clamp(1.75rem, 1.656rem + 0.382vw, 2rem); /* 28 → 32 */ --ooc-fluid-legal: clamp(0.75rem, 0.703rem + 0.191vw, 0.875rem); /* 12 → 14 */ --ooc-fluid-wordmark: clamp(7.75rem, 0.337rem + 30.18vw, 27.5rem); /* 124 → 440 */ /* body M (16) and body S (14) are NOT fluid — identical at both references. */ /* An ALIAS, not a new ramp. The h4 token is 48px and the file's only measured 48→mobile pair is the product name (48 → 40, docs/mobile-first.md §2), so a second 48px heading must ride the same ramp or the two would disagree at 393 for no reason. Named for the type token rather than the section that first needed it; `--ooc-fluid-product` stays as the existing consumers' name so this is additive. */ --ooc-fluid-h4: var(--ooc-fluid-product); /* 40 → 48 */ /* Contact details value — Figma 234:7943 / 234:7952, the h3 token at 64/68. ⚠️ THE MOBILE END IS DERIVED, NOT READ (Hard rule 2): no inner page has a mobile frame. 32 is not a guess — it is the largest step in the file's OWN measured scale (the h5/card step, 32 at both widths) at which the longest REAL value still fits the mobile card. The stacked card's inner width at 393 is 353 − 2×20 = 313, and Instrument Serif runs ≈0.42em average. The longest value is now "info@oneoceanusa.com", 20 characters (2026-08-06: the three personal addresses were replaced by one general mailbox), giving 313 / (20 × 0.42) ≈ 37.3px. The original derivation used the 22-character "steven@oneoceanusa.com" → ≈33.9px. THE ANSWER IS UNCHANGED AND THE MARGIN ONLY GREW: 32 clears both, and the next step up (40) clears neither. Kept at 32 rather than re-derived upward, because a shorter address is not a reason to grow type the design never drew. Re-gate if a mobile inner-page frame ever lands, or if a longer address is ever published here. */ --ooc-fluid-detail: clamp(2rem, 1.2493rem + 3.0564vw, 4rem); /* 32 → 64 */ /* An ALIAS, exactly as `--ooc-fluid-h4` is one. The product detail page's "You May Also Like" (223:881) is the h3 token at 64/68/-1%, the same token the contact detail value above rides. Its mobile end is derived from a different constraint than that card's, but a type token that resolved to two different sizes at 393 would be a token in name only — so the second consumer rides the first one's ramp, and the name says which token it is rather than which section wanted it. */ --ooc-fluid-h3: var(--ooc-fluid-detail); /* 32 → 64 */ } /* Read 2026-07-31 off the Contact frame, which is the first node in the file to apply either of them. Both were on the "STILL UNREAD" list below until now. */ :root { /* The `White` colour style. Distinct from `light 2` (#FFF9E9) and NOT interchangeable with it: the form card 234:7747 is pure #FFFFFF sitting on a #F2E6D5 page, and the details card's own heading 234:7791 is #FFFFFF while the phone/email values beside it are #FFF9E9. Two creams and a white, all in one 690px card — probed at 100% modal share rather than eyeballed, because at that separation they are indistinguishable by eye and a fills dump reports only whichever one you happened to open. */ --ooc-white: #FFFFFF; /* `White` — 234:7747, 234:7791 */ /* The input hairline. Figma names it `dark-900-o10`; it is BLACK at 10%, not a tint of the navy, so it warms/cools with whatever it sits on rather than matching the text. Reproducing it as navy-at-10% was the obvious wrong move — it reads visibly bluer against #FFFFFF. */ --ooc-hairline: rgba(0, 0, 0, 0.1); /* 234:7885 stroke */ } /* ⛔ STILL UNREAD — do not invent these. Each is a real Figma style that none of the probed frames applies at frame level; read it from the node that uses it, at the section build that needs it, then add it above with its node: Navy/Primary, Navy/Dark, Red/Accent, Cream/Base, Cream/Warm, Cream/Light, Gray/Dark, Gray/Medium, Gray/Light (colour styles) --ooc-radius (no probed node reported one; the chrome uses 6px buttons and a 12px drawer card, both read straight off their nodes) ✅ `White` came off the list 2026-07-31 — see the block above. */ /* ---------------------------------------------------------------------------- 2. BASE -------------------------------------------------------------------------- */ *, *::before, *::after { box-sizing: border-box; } html { -webkit-text-size-adjust: 100%; } body { margin: 0; /* Horizontal overflow is a gate failure at every breakpoint. Catching it at the root makes an offending child obvious instead of silently scrolling the whole page. */ overflow-x: hidden; /* The document's base face. Without this every element that does not set its own font-family inherits the BROWSER DEFAULT — the first capture of the header measured `font-family: Times` on the nav links for exactly this reason, while every other property matched the design. A missing base font is invisible in review (Times is not obviously "wrong", just wrong) and silently poisons every type measurement, so it belongs here at the root rather than being repeated per component. */ font-family: var(--ooc-font-sans); font-size: var(--ooc-body-m-size); line-height: var(--ooc-body-m-lh); /* The PAGE background. HP V1 (100:5838) is filled #F2E6D5 and most sections have NO fill of their own — they show this through. Defaulting sections to `light 2` made section 2 visibly too pale against the design. */ background: var(--ooc-light); } img, picture, video, canvas, svg { display: block; max-width: 100%; } /* Wide content (tables, code) scrolls inside its own container — the page body must never scroll horizontally. ⚠️ `display: block` MAKES A TABLE STOP LAYING OUT AS A TABLE. table-layout goes inert, and every column percentage then resolves against the shrink-to- fit content width instead of the table's — /services' 1400-wide grid measured 711 with four columns at 186/116/224/186. This is a safe DEFAULT for a table nobody designed (one pasted into a prose page, where overflowing the viewport is the worse failure), and it is wrong for a table that has its own scroll container. `.data-table__table` opts back out; see the note there. Anything else that ships a designed table must do the same. */ table { display: block; overflow-x: auto; } a { color: inherit; } button { font: inherit; } /* ---------------------------------------------------------------------------- 3. ACCESSIBILITY UTILITIES ---------------------------------------------------------------------------- Design-neutral, so they are safe to define before tokens exist. -------------------------------------------------------------------------- */ .screen-reader-text { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; border: 0; } /* Visible on keyboard focus so the skip link actually works. */ .skip-link:focus { position: fixed; top: 0; left: 0; z-index: 9999; width: auto; height: auto; margin: 0; padding: 0.75rem 1rem; clip-path: none; white-space: normal; } @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } /* ---------------------------------------------------------------------------- 4. LAYOUT PRIMITIVES ---------------------------------------------------------------------------- The content column. Values are token-driven and therefore inert until Phase 1 — see the note in section 1. FLUID RULE (Hard rule 3): sections must be pixel-exact at the two Figma reference widths and PROPORTIONAL between them. Express in-section geometry as a % of this content box (plus aspect-ratio canvases), never as fixed px carried across the whole breakpoint range. The symptom of breaking this is dead space around ~860px, which is why the gate checks 860 and 1100 as well as 375 and 1440. ── DESKTOP COMPOSITION CAP: 1440. Approved by Vitaliy 2026-07-31. ───────── The mirror of the 560px MOBILE cap approved the same day, decided for the same reason and with the same status: the file has artboards at 393 and 1440 and NOTHING ELSE, but the theme renders every width. Below 1440 the fluid rule governs. ABOVE 1440 the design specifies nothing, and the measured consequence of leaving that undecided was the page splitting into two layouts that fight each other — five sections froze at 1440 while four kept tracking the viewport. At 2560 the products grid measured 2520 wide directly above a carousel frozen at 1440: a 540px edge mismatch on each side, product cards inflated 453 -> 827 under a heading the `clamp()` ramp had already stopped at 100px, and 1,249px of extra page height bought with no extra content. THE RULE: above 1440 the CONTENT stops and centres; only the fills the design itself draws edge-to-edge keep bleeding. Concretely — bleeds the hero video, `products` #FFF9E9, `site-footer` #FFF9E9 caps every content column, at var(--ooc-container-max) `newsletter` is NOT in the bleed list on purpose: 100:6850 is a 1400-wide card with a 20px radius inset in the page, not a band, so it caps like content. Sections with an empty fills array (numbered-list, coverage) have nothing to bleed, so capping them is invisible apart from the alignment it buys. ⚠️ THE BLEED LIST HAS GROWN THREE TIMES SINCE. scripts/check-composition-cap .mjs is the authority — read BLEEDS there, not this line. Two of the entries are NOT fills and are worth knowing about: `statement` / `collage` empty fills arrays, bleeding on Vitaliy's call 2026-08-02 ("background taking full width"), the texture having been a 1440 island either side. `carousel` 2026-08-02 the section's fills are empty, but `gallery` 100:6692 is x0 w1440 — drawn at the FULL frame width, against a header at x20 w1400. The file distinguishes them, so this one IS design-backed even though the section fill is not. In every case the CONTENT still freezes; that half of the rule has never been relaxed and is what TARGETS in the script asserts. ⚠️ DERIVED, NOT READ (Hard rule 2), exactly like the 560 mobile cap. 1440 is in the file as a FRAME width; "hold it as a ceiling" is an engineering call, not a measurement. If the designer ever supplies a wide artboard or states a preferred >1440 behaviour, this becomes a read value and every section that caps here must be re-gated. Recorded in FIGMA.md -> "Also decided". ⚠️ The gate cannot see a violation of this rule at 1440/1100/860/393 — every width it captures is at or below the cap, which is exactly why the split above shipped at 100%. e2e captures 1920 as well; keep it there. -------------------------------------------------------------------------- */ .container { width: 100%; max-width: var(--ooc-container-max); margin-inline: auto; /* padding-inline, not `padding: y 0` — a shorthand here silently clobbers the horizontal gutter, which cost a debugging session on a prior build. */ padding-inline: var(--ooc-container-pad); } @media (min-width: 1025px) { .container { padding-inline: var(--ooc-container-pad-lg); } } /* A light-leading page must clear the fixed nav; a dark full-bleed hero sits underneath it. The body class is set once in PHP (ooc_nav_variant) so this never needs a per-template override. */ body.nav-light main { padding-top: var(--ooc-nav-h); } @media (min-width: 1025px) { body.nav-light main { padding-top: var(--ooc-nav-h-lg); } } /* ---------------------------------------------------------------------------- 5. CHROME ---------------------------------------------------------------------------- Header — Figma desktop `main nav` 211:3041 (1440×80) · mobile logo 226:2206 + trigger 226:2265 · drawer 230:5103 Footer — Figma desktop 130:661 (1440×604) · mobile 230:4332 (393×846) MOBILE FIRST: everything below the media query is the 393 design. The single `min-width: 1025px` block is the 1440 design. Authoring it the other way round is what leaks desktop values into the middle band and produces the ~860px dead space the gate checks for. Trap banked from prior builds, live in this file: a scrolled-state `backdrop-filter` on the header makes it a containing block for position:fixed children, which clips the drawer to the header's height. If a scrolled treatment is added later, disable the filter while the drawer is open. Related: state-dependent chrome has TWO sets of computed styles — probe the at-top state on a FRESH load (scroll classes linger), then the scrolled state separately. -------------------------------------------------------------------------- */ /* -- Shared button --------------------------------------------------------- Figma 100:5974 (header), 226:2265 (mobile trigger), 230:4608 (drawer close), 230:5069 (drawer CTA). Identical treatment, three heights — so height is the only thing a context overrides. Note letter-spacing is −2 PERCENT here, not px → -0.02em. */ .ooc-button { display: inline-flex; align-items: center; justify-content: center; gap: 10px; min-height: 44px; /* mobile trigger 226:2265 — also the 44×44 minimum tap target, so never shrink it */ padding-inline: 20px; border: 0; border-radius: 6px; background: var(--ooc-light-2); color: var(--ooc-navy-blue); font-family: var(--ooc-font-sans); font-size: var(--ooc-body-m-size); font-weight: var(--ooc-weight-medium); line-height: var(--ooc-body-m-lh); letter-spacing: -0.02em; text-decoration: none; cursor: pointer; transition: background-color 120ms ease; } /* Secondary is the default treatment — it is what the header CTA, the mobile trigger, the drawer Close and the drawer CTA all use (all cream-on-navy). */ .ooc-button:hover { background: var(--ooc-cream-hover); } .ooc-button:active { background: var(--ooc-cream-press); } /* Primary (194:7 Type=Primary) — navy fill, cream text, 48 tall. Not used by the chrome; defined here because it is half the component set and sections will need it, so the states live in one place rather than being rediscovered. */ .ooc-button--primary { min-height: 48px; background: var(--ooc-navy-blue); color: var(--ooc-light-2); } .ooc-button--primary:hover { background: var(--ooc-navy-hover); } .ooc-button--primary:active { background: var(--ooc-navy-press); } /* NOT FROM THE DESIGN — the file defines no focus state for any control. Shipping without a visible focus ring is a WCAG 2.4.7 failure, so this is a deliberate, flagged addition using the design's own palette rather than an invention of new colour. Replace it if a focus state is ever designed. */ .ooc-button:focus-visible, .site-header__link:focus-visible, .site-nav a:focus-visible, .site-nav__disclosure:focus-visible, .site-footer a:focus-visible, .site-drawer__menu a:focus-visible { outline: 2px solid currentColor; outline-offset: 3px; border-radius: 2px; } /* ✅ BOTH VARIANTS NOW EXIST — light RESOLVED 2026-07-31 from `main nav` 234:7413 (the Contact frame's instance). This block previously said "ONLY THE DARK VARIANT EXISTS" and refused to invent the light colours; that refusal is discharged, because a node finally uses them. ⚠️ THE BAR IS STILL TRANSPARENT — that was the thing worth checking, and it is the opposite of what "light header" usually means. Sampling a blank strip of the rendered node (x560 y8, 120x24) reads **#F2E6D5 at 100% modal share over 2,880px** — the page colour showing through, not a fill of its own. So this is NOT a solid bar: it is the same transparent header with the ink inverted. Giving it a background would have been the obvious, wrong move. GEOMETRY IS IDENTICAL between the two instances — menu left 20 / top 32 gap 24, logo 80x71 top 10 centred, actions right 20 / top 20 gap 24, CTA h42 radius 6 px20. Nothing below touches layout; every rule is paint only. The three paint deltas, read from the node: ink #FFF9E9 -> #002765 links, Login, and the logo (currentColor) CTA secondary -> PRIMARY navy fill + cream text, i.e. the exact swap of the dark bar's cream-on-navy chevron no change it is a mask on currentColor already, so it inverts for free — see the note in the desktop block ⚠️ THE MOBILE TRIGGER IS A DERIVATION (Hard rule 2), not a read. No mobile frame exists for ANY inner page, so nothing in the file shows this bar at 393. `.site-header__toggle` is an `.ooc-button`, i.e. cream-on-cream, which would be invisible against a light page — the same failure this block was written to prevent, just one breakpoint over. It takes the primary treatment because that is what the desktop instance does to its sibling CTA. Flagged here rather than passed off as spec; re-gate it if a mobile inner-page frame ever lands. */ /* ⚠️ `nav-stuck` IS LISTED SEPARATELY, NOT FOLDED INTO `nav-light`. The sticky header first inverted by having main.js add `nav-light` to the body — reusing the treatment rather than restating it, which was right about the COLOURS and wrong about the class. `nav-light` also carries LAYOUT: `body.nav-light main { padding-top: var(--ooc-nav-h) }` reserves the bar's height on pages whose first section is not a full-bleed hero. Adding it mid-scroll therefore pushed the entire page down 80px in one frame — the residual jump Vitaliy reported after the position fix ("still jumping when white background appearing, but visually less then it was"). So the ink rules name both states and the layout rule names only one. */ body.nav-light .site-header__brand, body.nav-light .site-nav a, body.nav-light .site-nav__disclosure, body.nav-light .site-header__link, body.nav-stuck .site-header__brand, body.nav-stuck .site-nav a, body.nav-stuck .site-nav__disclosure, body.nav-stuck .site-header__link { color: var(--ooc-navy-blue); /* I234:7413;100:5900 / ;136:1122 */ } /* The CTA and the mobile trigger swap to the primary variant. Restating the three values rather than adding `.ooc-button--primary` in PHP: the variant is a property of the PAGE, not of the button, so a template that hard-coded the class would ship the wrong colour the moment a page's leading section changed. min-height is deliberately NOT restated — 42px (CTA) and 44px (tap target) are set elsewhere and must survive. */ body.nav-light .site-header__actions .ooc-button, body.nav-light .site-header__toggle, body.nav-stuck .site-header__actions .ooc-button, body.nav-stuck .site-header__toggle { background: var(--ooc-navy-blue); /* I234:7413;100:5974 */ color: var(--ooc-light-2); /* I234:7413;100:5975 */ } body.nav-light .site-header__actions .ooc-button:hover, body.nav-light .site-header__toggle:hover, body.nav-stuck .site-header__actions .ooc-button:hover, body.nav-stuck .site-header__toggle:hover { background: var(--ooc-navy-hover); } body.nav-light .site-header__actions .ooc-button:active, body.nav-light .site-header__toggle:active, body.nav-stuck .site-header__actions .ooc-button:active, body.nav-stuck .site-header__toggle:active { background: var(--ooc-navy-press); } /* -- Header ---------------------------------------------------------------- */ .site-header { /* ⚠️ FIXED AT ALL TIMES, and that IS the smoothness fix. This was `absolute`, switching to `fixed` when the sticky state engaged — and swapping the positioning scheme mid-scroll is a jump by construction: the bar leaves the document and is re-pinned to the viewport in one frame, with a drop-in animation replaying on top of it. Vitaliy: "it is jumping on scroll can you make it smoother." Fixed throughout, nothing MOVES at all. Only paint changes — a background fades in and the ink inverts — so there is no geometry to stutter. At scroll 0 fixed and absolute put the bar in exactly the same place, which is why every measured value on every page is unchanged. */ position: fixed; inset-block-start: 0; inset-inline: 0; z-index: 100; height: var(--ooc-nav-h); /* The fade. `background-color` and `box-shadow` here; the INK transitions are on the elements that carry colour, further down. */ transition: background-color .28s ease, box-shadow .28s ease; } /* The colour inversion fades with the bar rather than snapping a frame later. Kept on one line per group so the property list cannot drift from the rules that actually set these colours (`body.nav-light …`). */ .site-header__brand, .site-nav a, .site-nav__disclosure, .site-header__link { transition: color .28s ease; } .site-header__actions .ooc-button, .site-header__toggle { transition: background-color .28s ease, color .28s ease; } @media (prefers-reduced-motion: reduce) { .site-header, .site-header__brand, .site-nav a, .site-nav__disclosure, .site-header__link, .site-header__actions .ooc-button, .site-header__toggle { transition: none; } } /* ---- STICKY ON SCROLL — DERIVED, no node. Vitaliy 2026-08-05 ------------- "lets do header sticky on scroll it will have white background and invert font color and button color and logo color." ⚠️ THE FILE DRAWS NO SCROLLED STATE. `main nav` 211:3041 is one 1440x80 symbol with a transparent bar; there is no second frame showing it over content. So this is a derivation, like the Products panel — recorded in FIGMA.md rather than passed off as read. ⚠️ IT INVERTS BY REUSING `nav-light`, NOT BY RESTATING IT. main.js adds the page's own light class when the header sticks, so the brand, the links, the disclosure chevron, the header link, the CTA and the mobile trigger all take the treatment ALREADY READ from `234:7413` — the Contact frame's light nav instance. Restating those colours here would be a second source of truth that drifts the first time one of them changes; the only thing this block adds is what the light instance has no opinion about, because it never sits over content: a fill and the fact of being fixed. The fill is `--ooc-light-2` #FFF9E9, not #FFFFFF. "White background" is the ask; #FFF9E9 is this site's white — every panel the design calls white is that value (`products`, `coverage`, `site-footer`), and a true #FFFFFF bar would be the only one on the page. */ body.nav-stuck .site-header { background: var(--ooc-light-2); /* The design gives the bar no border anywhere. A hairline is what stops it dissolving into a cream section scrolling underneath it — the same 1px navy the product cards rule themselves with, at low alpha so it reads as a shadow rather than a drawn line. */ box-shadow: 0 1px 0 rgb(0 39 101 / .08); } /* ⚠️ THE DROP-IN ANIMATION IS GONE. It existed to cover the absolute -> fixed swap, and it was half the jump it was meant to hide: `both` fill mode meant it replayed on every re-stick, so scrolling up and down across the threshold re-ran a 220ms slide each time. With the bar permanently fixed there is nothing to slide in — it is already there, and only its paint changes. */ .site-header__inner { display: flex; align-items: center; /* 96px tall + 56px logo → top 20 ✓ 96px tall + 44px trigger → top 26 ✓ both exactly as designed, no offsets */ justify-content: space-between; height: 100%; padding-inline: var(--ooc-container-pad); /* DESKTOP COMPOSITION CAP (§4). The bar itself is transparent over the hero, so there is no fill to bleed — only the logo/nav/CTA row, which `space- between` otherwise pushes to the viewport edges: measured 1440 → 2560 wide, tearing the nav away from the hero headline it is meant to sit above. Inert below 1440. */ max-width: var(--ooc-container-max); margin-inline: auto; } /* The links and the Login/Contact pair are drawer-only on mobile. */ .site-header__primary, .site-header__actions { display: none; } .site-header__brand { display: inline-flex; align-items: center; color: var(--ooc-light-2); /* the inlined SVG is currentColor */ text-decoration: none; } .site-header__logo { display: block; width: 63px; /* mobile logo 226:2206 = 63×56 */ height: 56px; } .site-header__logo svg { display: block; width: 100%; height: 100%; } .site-header__toggle { flex: 0 0 auto; } /* -- Mobile drawer — Figma 230:5103 ---------------------------------------- */ .site-drawer { position: fixed; inset: 0; z-index: 200; /* Design stacks TWO black rects at 20% and 30% (230:5075, 230:5076). Composited that is 1 − (0.8 × 0.7) = 0.44, so one layer is equivalent and avoids a second paint. */ background: rgb(0 0 0 / 0.44); } /* `hidden` alone loses to `display: fixed`-style rules in some resets, so make the attribute authoritative. */ .site-drawer[hidden] { display: none; } /* Scroll-lock the page behind the modal. Without this, momentum scrolling on iOS moves the document under the drawer. */ body.nav-open { overflow: hidden; } .site-drawer__card { position: absolute; inset: 10px 10px auto 10px; /* card is inset 10 and NOT full height */ display: flex; flex-direction: column; /* ⚠️ The card is 607 tall as drawn (230:5103) and sized by its content, which was safe while the content was three links. Expanding Products adds seven rows: measured 870 against an 852 viewport, so the last products sat below the fold with nothing to scroll. `dvh` not `vh` for the same reason the hero uses it — `vh` is the LARGEST viewport on mobile and would leave the bottom under the URL bar. */ max-height: calc(100dvh - 20px); overflow-y: auto; overscroll-behavior: contain; padding: 10px; border-radius: 12px; background: var(--ooc-navy-blue); color: var(--ooc-light-2); } .site-drawer__top { display: flex; align-items: center; justify-content: space-between; margin-block-end: 50px; /* Frame 2007 gap */ } .site-drawer__logo { display: block; width: 63px; height: 56px; } .site-drawer__logo svg { display: block; width: 100%; height: 100%; } .site-drawer__menu { margin: 0; padding: 0; list-style: none; } /* Dividers are 1px rects in the design (230:5081 etc) with a 12px gap either side: divider, 12, item(52), 12, divider … Expressed as a border plus symmetric padding, one
  • is 1 + 12 + 52 + 12 = 77, and 4 items plus the closing border is 4×77 + 1 = 309 — the measured height of `menu` 230:5034. */ .site-drawer__menu > li { border-block-start: 1px solid var(--ooc-light-2); padding-block: 12px; } .site-drawer__menu > li:last-child { border-block-end: 1px solid var(--ooc-light-2); } /* ---- The drawer's Products disclosure — Vitaliy 2026-08-05 -------------- "mobile menu when i click on products it wont open". It was a plain link and navigated, which is correct behaviour for a link and the wrong behaviour for a row with a catalogue behind it. The row is a BUTTON now and /products/ is the first entry inside, because a 52px touch target has no room for two controls doing different things — see inc/nav-dropdown.php. ⚠️ TEXT ONLY. The desktop panel is six 216px cards; stacked into a 393-wide drawer that is 607 tall to begin with, that is not a menu. "keep it simple for mobile" is taken literally: names, and the way back to the full page. */ .site-drawer__disclosure { /* Matches `.site-drawer__menu a` exactly — same face, size, leading and target — so the row does not read as a different KIND of thing just because it opens rather than navigates. */ /* ⚠️ A BUTTON INHERITS NONE OF `.site-drawer__menu a`. Those properties are on the anchor selector, so the button rendered at the UA's default font in a 353x20 box — under the 44x44 tap floor this project checks, and visibly a different kind of row from the two beside it. Restated here rather than widening the anchor selector, so the link rule stays a statement about links. */ display: flex; align-items: center; min-height: 52px; width: 100%; justify-content: space-between; gap: 12px; padding: 0; border: 0; background: none; color: inherit; font-family: var(--ooc-font-display); font-feature-settings: var(--ooc-font-display-features); font-size: 40px; font-weight: 400; line-height: 52px; letter-spacing: 0; text-align: start; cursor: pointer; } .site-drawer__disclosure:focus-visible { outline: 2px solid currentColor; outline-offset: 3px; border-radius: 2px; } .site-drawer__disclosure-icon { flex: none; width: 20px; height: 20px; background-color: currentColor; -webkit-mask: var(--ooc-chevron) center / 20px 20px no-repeat; mask: var(--ooc-chevron) center / 20px 20px no-repeat; transition: transform .18s ease; } @media (prefers-reduced-motion: reduce) { .site-drawer__disclosure-icon { transition: none; } } .site-drawer__disclosure[aria-expanded="true"] .site-drawer__disclosure-icon { transform: rotate(180deg); } .site-drawer__submenu { list-style: none; margin: 0 0 8px; padding: 0 0 0 20px; display: flex; flex-direction: column; } .site-drawer__submenu[hidden] { display: none; } .site-drawer__menu .site-drawer__submenu a { /* ⚠️ SCOPED THROUGH `.site-drawer__menu` ON PURPOSE. `.site-drawer__submenu a` alone ties `.site-drawer__menu a` on specificity (0,1,1) and loses on source order, so these rendered at the top level's 40px/52 — measured — and a second rank that is the same size as the first is not a second rank. This selector is (0,2,1) and wins wherever it sits in the file. Smaller is also what keeps the card on screen: seven 52px rows plus the two other links is what pushed it to 870 in an 852 viewport. 44 keeps the tap target above the 44x44 floor this project checks for. */ min-height: 44px; font-size: 24px; line-height: 44px; } .site-drawer__menu a { display: flex; align-items: center; min-height: 52px; font-family: var(--ooc-font-display); /* 40px Instrument Serif, not the body face — 230:5036 */ font-feature-settings: var(--ooc-font-display-features); font-size: 40px; font-weight: 400; line-height: 52px; letter-spacing: 0; color: inherit; text-decoration: none; } .site-drawer__cta { margin-block-start: 120px; /* SPACE_BETWEEN resolves to 120 in the 587-tall inner (230:5102) */ min-height: 52px; justify-content: space-between; } .site-drawer__cta-icon { flex: none; width: 30.363px; /* I230:5069;186:17 */ height: 24px; } /* ⚠️ THE DRAWER'S CHEVRON IS 20px WHERE THE DESKTOP NAV'S IS 16 (230:5041 against 100:5905), and the row is `justify-between` with a 4px right inset rather than an 8px gap. Same per-item trigger as the desktop rule above — the design marks Products as the only dropdown — but it does NOT inherit it, because that rule is scoped to `.site-nav` and this menu is not in one. It rendered with no chevron at all until this was written. */ .site-drawer__menu .menu-item-has-children > a, .site-drawer__menu .has-dropdown > a { display: flex; align-items: center; justify-content: space-between; padding-inline-end: 4px; /* 230:5039 pr-[4px] */ } .site-drawer__menu .menu-item-has-children > a::after, .site-drawer__menu .has-dropdown > a::after { content: ""; flex: none; width: 20px; /* 230:5041 */ height: 20px; background-color: currentColor; -webkit-mask: var(--ooc-chevron) center / 20px 20px no-repeat; mask: var(--ooc-chevron) center / 20px 20px no-repeat; } /* -- Footer --------------------------------------------------------------- */ .site-footer { position: relative; /* `clip`, not `hidden`: the wordmark bleeds past both edges by design, and `hidden` would make this a scroll container and trip the overflow gate. */ overflow: clip; /* First row is at y=50 on both breakpoints. The BOTTOM differs: mobile legal ends at 836 in an 846-tall footer (10), desktop legal ends at 584 in 604 (20). Assuming one value for both left mobile 10px too tall. */ padding-block: 50px 10px; background: var(--ooc-light-2); color: var(--ooc-navy-blue); font-family: var(--ooc-font-sans); } .site-footer__inner { position: relative; z-index: 1; /* above the decorative wordmark */ display: grid; gap: 40px; /* measured row gap: 138→178, 232→272, 418→458 */ padding-inline: var(--ooc-container-pad); /* DESKTOP COMPOSITION CAP (§4). The footer's #FFF9E9 fill stays full-bleed — it is on .site-footer, not here — while the link columns stop at the 1400 content column. Without this the desktop track is `auto auto auto 1fr` with Contacts justified to the end, so the right-hand column tracks the viewport: measured 1440 → 1920 → 2560, i.e. Contacts sitting 560px right of where 130:716 puts it at 2560. Inert below 1440. */ max-width: var(--ooc-container-max); margin-inline: auto; } /* Mobile: heading BESIDE its list, list column starting at x=148 (230:4419). 148 + 205 = 353 = the mobile content column. */ .site-footer__group { display: grid; grid-template-columns: 148px 1fr; align-items: start; } .site-footer__heading { margin: 0; font-size: var(--ooc-body-m-size); font-weight: var(--ooc-weight-semibold); line-height: var(--ooc-body-m-lh); letter-spacing: 0; } .site-footer__menu { margin: 0; padding: 0; list-style: none; display: grid; gap: 14px; /* Frame 1991 itemSpacing */ } .site-footer__body, .site-footer__menu a, .site-footer__address { font-size: var(--ooc-body-m-size); font-weight: var(--ooc-weight-book); line-height: var(--ooc-body-m-lh); letter-spacing: 0; } .site-footer__menu a { color: inherit; text-decoration: none; } .site-footer__body { display: grid; gap: 14px; } .site-footer__address { margin: 0; font-style: normal; /*
    italicises by default */ /* 22px, NOT the 20px body-M leading. Read off 230:4380 / 230:4384, which are lineHeight PIXELS 22 while every other footer string is 20. Three wrapped lines × 22 = the node's measured 66px height; at 20px the group came out 12px short and pushed everything below it up. The addresses are the only footer text with their own leading — do not "tidy" this to the token. */ line-height: 22px; } /* Legal: mobile stacks the links and bottom-right-aligns the copyright (230:4405 VERTICAL gap 4 · 230:4404 at x268 → right edge 373). */ .site-footer__legal { display: grid; grid-template-columns: 1fr auto; align-items: end; /* Design separation from the last group is 212 (ends 580 → legal at 792), but .site-footer__inner already contributes its 40px grid row-gap, so the margin is 212 − 40. Setting the full 212 double-counted the gap and put legal at 820 instead of 792. */ margin-block-start: 172px; font-size: var(--ooc-fluid-legal); } .site-footer__legal-menu { margin: 0; padding: 0; list-style: none; display: grid; gap: 4px; } .site-footer__legal-menu a { color: inherit; text-decoration: none; } .site-footer__copyright { margin: 0; text-align: end; } /* Decorative wordmark + image. Bleeds both edges on purpose. */ .site-footer__decor { position: absolute; inset-block-end: 0; inset-inline: 0; z-index: 0; display: grid; /* Pin the column to the container width. Without this the implicit column is sized by its widest item — the max-content wordmark, ~417px at mobile — and the image's percentage width then resolves against THAT, coming out 15px too wide and 12px too tall. The wordmark still overflows this column on purpose; that is the bleed. */ grid-template-columns: minmax(0, 1fr); place-items: end center; pointer-events: none; /* DESKTOP COMPOSITION CAP (§4). This is what the decor image's percentage width resolves against, so uncapped it grew 580 → 773 → 1031 (40.28% of the viewport instead of 40.28% of the frame). Capping the CONTAINER rather than the image keeps one source of truth for both children. The wordmark deliberately still overflows this box — that is the bleed, and it needs no cap of its own: --ooc-fluid-wordmark is already clamp()ed to 440px, so it measures a constant 1493.9px wide and simply re-centres. At 1920 it spans the capped box ±27px, which is the same ±19.5px-ish bleed 130:663 draws at 1440. Do NOT add overflow:clip here to "tidy" that — it would cut the bleed the design asks for. */ max-width: var(--ooc-container-max); margin-inline: auto; } .site-footer__wordmark { display: block; grid-area: 1 / 1; width: max-content; font-family: var(--ooc-font-display); font-feature-settings: var(--ooc-font-display-features); font-size: var(--ooc-fluid-wordmark); /* Box height matches the node so the glyphs sit where the design puts them: 230:4334 is 110 tall at 124px (110/124 = 0.887). Desktop overrides. */ line-height: 0.887; letter-spacing: -2px; /* mobile 230:4334 */ color: var(--ooc-navy-blue); /* ⚠️ THE WORDMARK HANGS OFF THE BOTTOM OF THE FOOTER. 230:4334 spans 772–882 in an 846-tall footer, so 36px of it is clipped away. Bottom- aligning it inside the footer — which is what `place-items: end` does on its own — floats the whole word up into the link columns and it collides with the addresses. This negative margin is the clipping. */ margin-block-end: -36px; /* ⚠️ THE WORDMARK IS 10% OPACITY (130:663 and 230:4334 both opacity 0.1). Its FILL is solid #002765 with paint-opacity 1, so reading the fill alone — as the first pass did — produces a solid navy slab that swallows the legal line sitting on top of it. Node opacity and paint opacity are different properties and only the paint one shows up in a fills dump. The gate did not catch it either, because nothing asserted opacity; it is asserted now. */ opacity: 0.1; } .site-footer__decor-img { grid-area: 1 / 1; align-self: end; width: 71.4%; /* 280.6 / 393, exact — % of the viewport, not px, so it scales through the band */ /* ⚠️ THE TWO BREAKPOINTS CROP THE SAME PHOTO DIFFERENTLY. 230:4335 is scaleMode CROP at 280.6x257.4 (ratio 1.09); 130:664 is FILL at 580x385 (ratio 1.51). Letting `height: auto` derive from the export's own aspect gave a mobile image 66px too short and 66px too low. Pinning aspect-ratio per breakpoint and cover-fitting reproduces both crops from ONE asset — otherwise this needs a with two exports. */ aspect-ratio: 280.6 / 257.4; height: auto; object-fit: cover; object-position: center; /* The image runs PAST the footer's bottom edge and is clipped, rather than sitting flush on it: 230:4335 spans 602.1–859.5 in an 846-tall footer. */ margin-block-end: -13px; } /* "keep it simple for mobile" — Vitaliy 2026-08-05. Below 1025 the primary nav is not on screen at all (the drawer replaces it), and the drawer lists Products as a plain link to /products/, which is what it has always done and what it keeps doing. The disclosure button and the panel are rendered in the markup at every width — the panel because it is a sibling of the header inner rather than something conditionally printed, the button because the menu filter cannot know the viewport — so both are hidden here rather than left to inherit nothing. Mobile-first: the desktop block below is what turns them on. */ .site-nav__disclosure, .site-nav__panel { display: none; } /* ==== DESKTOP — the 1440 design ========================================== */ @media (min-width: 1025px) { .site-header { height: var(--ooc-nav-h-lg); } /* Links · logo · actions, in source order. The logo lands dead-centre because the outer columns are equal 1fr. */ .site-header__inner { display: grid; grid-template-columns: 1fr auto 1fr; align-items: start; /* each column carries its measured y */ } .site-header__primary { display: block; margin-block-start: 32px; /* `menu` 100:5898 y=32 */ } .site-nav { display: flex; gap: 24px; /* 100:5898 itemSpacing */ margin: 0; padding: 0; list-style: none; } /* ⚠️ THE DISCLOSURE IS COLOURED WITH THE LINKS, NOT BY INHERITANCE. The chevron used to be an `::after` ON the anchor, so the comment below — "it takes currentColor and therefore flips with the header treatment" — was true for free. Moving it onto a sibling