/* ============================================================================ _band-lg.css — the LARGE band. Lane `fluid:lg`. Load LAST. ---------------------------------------------------------------------------- SCOPE: 1441px and up. 1440 is a HARD CONSTRAINT (the ES artboard 4080:122) and this file is written so that it CANNOT touch it: every rule below lives inside `@media (min-width: 1441px)`. 1280 and 1440 are therefore untouched by construction, not by care — there is no rule in this file that a browser at 1280 or 1440 can even see. --------------------------------------------------------------------------- WHAT WAS MEASURED FIRST (review/fluid/probe-lg-BEFORE.json, headless Chrome on port 5141, all 20 sections at 1280 / 1440 / 1600) --------------------------------------------------------------------------- V1 already implements Salient's container verbatim: .mk-page --mk-frame: min(100vw, 1440px) .mk-container max-width: var(--mk-frame); margin-inline: auto; padding-inline: var(--mk-page-x) which is `max-width + auto margin + flat padding` — exactly the formula FLUID-SYSTEM.md §1 derives. So the SEVEN sections that inset through `.mk-container` (00, 01, 04, 05, 06, 16, 21) were already correct at 1600: measured content 1200 at left 200, identical to the model. Nothing in this file changes them. The defect is the OTHER family. Fifteen elements across eight sections are full-bleed and inset themselves with `padding: … var(--mk-page-x)` instead of going through `.mk-container`. Those keep a 120 gutter at 1600 while the container family moves to 200, so the built page has TWO DIFFERENT LEFT MARGINS above 1440. Measured, 1600px: 00-hero / 01 / 04 / 05 / 06 / 16 / 21 text left 200 <- correct 02 / 03 / 08 / 09 / 10 / 11 / 12 / 13 text left 120 <- wrong That single misalignment is what "V1 does not scale above 1440" actually is. --------------------------------------------------------------------------- THE FIX — two declarations, then the consequences of them --------------------------------------------------------------------------- Both families read the SAME two tokens. Rather than patch fifteen elements with magic numbers, this file re-points the two tokens so that every one of the ~25 existing `var(--mk-page-x)` / `var(--mk-frame)` consumers becomes correct at once: --mk-frame: 100vw --mk-page-x: calc((100vw - 1440px) / 2 + 120px) This is safe because every consumer in the build pairs them in exactly one way — `frame - 2 * page-x` — and that expression is INVARIANT under the swap: 100vw - 2 * ((100vw - 1440) / 2 + 120) = 100vw - (100vw - 1440) - 240 = 1200 at every width So `.mk-container` (max-width: frame, padding: page-x) still yields a 1200 content box; it simply gets there by growing the padding instead of by growing the auto margin. Both routes render the same box — verified, the container family's numbers are bit-identical before and after this file. And the gutter function is now the one FLUID-SYSTEM.md §1 specifies, for BOTH families: gutter(vw) = max(0, (vw - 1440) / 2) + 120 --------------------------------------------------------------------------- THE TWO CONSEQUENCES THAT NEED THEIR OWN RULES --------------------------------------------------------------------------- 1. `padding: var(--mk-page-x)` is ALL FOUR SIDES on the five editorial rails (09 §86, 10 §70, 11 §50, 12 §56, 13 §151). Growing the token would grow their TOP and BOTTOM padding too, which is a vertical change and this band has no authority over vertical rhythm. §2 below pins padding-block at 120 and lets only padding-inline move. 2. The rail and pair WIDTHS are authored as the literal sums 563 and 837: 563 = 120 + 323 + 120 gutter + text block + inner gap 837 = 120 + 597 + 120 gutter + copy measure + inner gap Only the FIRST 120 is the page gutter. The second is the internal gap between the text column and the media that sits beside it, which is a spacing token and caps at its 1280 value like every other one (§4.4). So §3 below re-expresses those widths as rail = var(--mk-page-x) + 323px + 120px copy = var(--mk-page-x) + 597px + 120px NOT as `323 + 2 * page-x`. The difference is visible: at 1920 the symmetric form would put a 360px void between the text and the photo. --------------------------------------------------------------------------- ONE FLAGGED JUDGEMENT — the media keeps bleeding, the remainder grows --------------------------------------------------------------------------- Above 1440 two things the artboards both show become impossible together: (i) the media column touches the viewport's right edge (measured: 03's images end at exactly 1280 and at exactly 1440) (ii) the SPACE_BETWEEN remainder caps at the 160 the ES frame shows because text-left + 597 + gap + 443 = vw forces gap = vw - 1240. You may have either, not both. THIS FILE CHOOSES (i). Reasons, in order: * Salient does not cap its full-bleed rows — `dna-container.md` §6, and FLUID-SYSTEM.md §5.1 flags its own cap as "a judgement, not a measurement" with a one-line revert. * Choosing (ii) leaves an 80px sliver of page ground to the right of a full-bleed photo at 1600, growing to 240 at 1920. That is the canonical "responsive is broken" look and no Salient demo does it. * (i) preserves the SPLIT better than the cap does. FLUID-SYSTEM §5.1 worried that 09-13 go to a 29/71 rail/media split at 1920 against 44/56 at 1280. That was measured with the rail frozen at 563. With the rail riding the gutter it is 803/1117 = 42/58 at 1920 — the proportion is very nearly held, and the cap is not needed to hold it. TO REVERT to (ii): add `max-width: 1440px; margin-inline: auto;` to the pair rows in §3. Nothing else changes, and 1280/1440 are unaffected either way. --------------------------------------------------------------------------- NOT FIXED HERE — filed in review/fluid/BAND-REQUESTS.md --------------------------------------------------------------------------- The CTA card's resting clip is a literal `inset(29.7778% 120px 25.5556% 120px round 4px)` inside a `data-nectar-animate-settings` attribute in index.html, written to the element inline by js/mk-expanding-card.js. CSS cannot reach it. At 1600 the card therefore rests at a 120 inset while its own copy stack (fixed below) sits at 200. BAND-REQ-LG-2. ========================================================================== */ /* ========================================================================== SINGLE-OWNER RULING — 2026-08-17, lane `fluid-apply`. §1, §2 and §3 OF THIS FILE HAVE BEEN DELETED. Everything above this comment is the lane's original reasoning and is kept verbatim as the record of the case it argued; the mechanism it argued FOR is not what ships. -------------------------------------------------------------------------- THE COLLISION. This file and `_band-xl.css` both gated every rule on `@media (min-width: 1441px)` — the identical band, not two adjacent ones — with mechanisms that cannot compose: xl leaves --mk-frame capped at 1440 and insets the five editorial rails with `--mk-xl-inset: calc(50% - var(--mk-frame)/2)`. lg released the tokens themselves (`--mk-frame: 100vw`, `--mk-container-width: 100vw`, `--mk-page-x: (100vw-1440)/2 + 120`) and then repaired the consequences. lg's §1 selected `.mk-page` — the SAME element at the SAME specificity as grid.css's own `.mk-page` rule — so source order alone decided which won. With the band sheets loaded last (the position REQ-XL-1 asks for and the position the composed six-band page was verified in), lg's release WON, and xl's `calc(50% - var(--mk-frame)/2)` therefore computed to 0. The page silently landed on lg's design while band-xl.md reported COMPLETE: measured at 1920, rail media 1117 not 877, card copy 997 not 757, crop aspect 2.48 not 1.95 — a 27% drift against xl's own 12% DEGRADED threshold. THE RULING: TAKE xl. The founder's instruction is "scale as the original template does". Salient's content-cap rule is MEASURED — read out of the vendored `style.css` (`.nectar_section.full-width-content > .row_col_wrap_12` caps at `--container-width` and centres) and then confirmed in a browser on the tether demo at four widths (`review/fluid/xl-salient-tether.json`). lg's media-touches-the-frame reading is an INFERENCE from two static frames that agree only because their page gutter happened to equal their container inset — which is the exact class of error this whole workstream exists to correct. A measurement of the template beats an extrapolation from the artboards when the two disagree above the artboards' own range. Two independent corroborations landed on the same side after the ruling: * `FLUID-SYSTEM.md` §2.3 reason 1 picks CW = 1440 precisely so the 03/08 SPACE_BETWEEN remainder caps at the 160 the ES frame shows. lg's release lets that remainder grow to 680 at 1920 — a gap size the design never displays, which is what §2.3 chose CW to prevent. * `REQ-XL-4` upgraded §5.1's cap from "a judgement" to a measurement, and reconciled it with `dna-container.md` §6 by naming the layer: Salient does not cap BACKGROUNDS, and does cap CONTENT. Both lanes' evidence is true; only one of them is about the layer under discussion. WHAT MOVED WITH THE RULING. REQ-lg-01 point 1 states that if xl wins, "02 / 03 / 08 / 18 / 19 still need an owner above 1440". They now have one: `_band-xl.css` §1b applies the SAME `--mk-xl-inset` mechanism to 02, 03 and 08. 18/19 are deliberately left uncapped — see §4 below and _band-xl.css. §4 and §5 are KEPT. Under xl's mechanism `--mk-page-x` stays 120 above 1440, so both evaluate to exactly their authored values and are inert; they are retained so this file still documents the two hooks, and so that a future decision to revert to lg's mechanism finds them already written. ========================================================================== */ /* ========================================================================== 4. THE CTA ROW'S COPY STACK 18/19 §143 sets `padding: 120px 120px 12px` as three literals, so the copy stack stays 1360 wide at 1600 while every other content box is 1200. Only the inline axis is touched; the 120/12 vertical pair is frame B's own asymmetric padding and is not this band's business. The CARD ITSELF is not reachable from CSS — see BAND-REQ-LG-2. ========================================================================== */ @media (min-width: 1441px) { .mk-page .mk-ctacard .mk-ctacard__row { padding-inline: var(--mk-page-x); } } /* ========================================================================== 5. FORWARD-COMPATIBILITY WITH grid-fluid.css — INERT TODAY, UNTESTED `review/fluid/grid-fluid.css` is not linked into the build yet (REQ-md-02). When it lands it introduces two primitives whose 563 is the same literal sum §3 replaces, so they are given the same treatment here. NEITHER SELECTOR MATCHES ANY ELEMENT IN THE CURRENT MARKUP — verified: `index.html` contains `mk-rail-images` twice and `mk-rail__text` / `mk-pair__item` zero times — so this block cannot affect any measurement in band-lg.md, and it has NOT been exercised in a browser. Delete it if grid-fluid.css is never applied. ========================================================================== */ @media (min-width: 1441px) { /* grid-fluid.css:230 — `flex: 0 0 563px; padding-inline: var(--mk-page-x)`. Left as-is that is a 563px box with 200px of padding on each side, i.e. a 163px text block. Same decomposition as §3. */ .mk-page .mk-rail__text { flex: 0 0 calc(var(--mk-page-x) + 323px + 120px); padding-left: var(--mk-page-x); padding-right: 120px; } /* grid-fluid.css:228 caps `.mk-rail` at --mk-container-width. §1 releases that token to 100vw, which turns the cap into a no-op — which IS the flagged judgement (i) in the header, expressed through the same token rather than by deleting the lines grid-fluid.css marks `CAP`. */ }