/* ============================================================================ _band-xl.css — the ABOVE-THE-ARTBOARDS band. Lane: `fluid:xl`. ---------------------------------------------------------------------------- OWNS: viewport widths >= 1441px only. Nothing in this file may match at or below 1440px. Every rule is inside `@media (min-width: 1441px)`, and that is a hard structural guarantee, not a convention — the two Figma artboards (EN 1280, ES 1440) are hard constraints and this file must be provably unable to touch them. A rule outside that block is a bug. WHAT FIGMA SAYS ABOUT THIS BAND: nothing. There is no artboard above 1440. So the authority here is the founder's correction — "It also needs to scale effectively for all devices AS DESIGNED IN THE SALIENT TEMPLATE ... It needs to scale for the size of the screen as the original template does." — which makes SALIENT'S OWN MEASURED BEHAVIOUR the reference. Everything below is argued from a measurement of Salient, not from taste. --------------------------------------------------------------------------- THE ONE RULE SALIENT ACTUALLY APPLIES ABOVE ITS CONTAINER WIDTH --------------------------------------------------------------------------- Read from Salient's shipped `style.css` (vendored verbatim in this build at vendor/.../css/build/style.q-98889c766d.css): .nectar_section.full-width-content > .row_col_wrap_12 { margin: 0 auto; max-width: var(--container-width, 1425px); width: 100%; padding: 0 var(--container-padding); box-sizing: border-box; } i.e. even inside a section explicitly marked FULL-WIDTH-CONTENT, Salient caps the CONTENT at `--container-width` and centres it. The only things allowed to escape are (a) `.row-bg-wrap` / `.row-bg-layer` — the BACKGROUND layers, which get `left:50%; margin-left: calc(-50vw + …)` — and (b) a row the author explicitly marked `.wpb_row.full-width-content`. VERIFIED IN A BROWSER, not just read. Salient's `tether` demo on the local mirror (127.0.0.1:5010), CW = 1425, CP = 40, measured at four widths: vw .container .nectar_section.fwc .wpb_row.fwc .row-bg-wrap left / width > .row_col_wrap_12 (both forms) 1280 0 / 1425(clamped) 0 / 1280 0 / 1280 0/1280 · 40/1200 1440 7.5 / 1425 7.5 / 1425 0 / 1440 0/1440 · 47.5/1345 1680 127.5 / 1425 127.5 / 1425 0 / 1680 0/1680 · 167.5/1345 1920 247.5 / 1425 247.5 / 1425 0 / 1920 0/1920 · 287.5/1345 Content caps and centres. Backgrounds bleed. That is the whole rule, and it is the rule this file applies. --------------------------------------------------------------------------- THE MEASURE QUESTION — "guard against absurdly long line lengths" --------------------------------------------------------------------------- Salient's answer at 1920 is: THE CONTAINER CAP IS THE GUARD. There is no separate measure rule anywhere in the template. Measured on tether, widest continuous-text paragraph on the whole page: 1280 622.0px @ 14.4px ~86 characters 1440 709.0px @ 16.0px ~89 characters 1680 709.0px @ 16.0px ~89 characters <- frozen 1920 709.0px @ 16.0px ~89 characters <- frozen Paragraphs wider than 900px, at ANY width including 1920: ZERO. So the correct guard is structural — cap the container, and every measure inside it freezes automatically. V1 already had that for the 20 sections whose copy lives in `.mk-container`. It did NOT have it for the five editorial-rail sections, and that is what §1 fixes. After §1, the widest running-text box on this page stops growing at its 1440 value at every width. NOT FIXED HERE, DELIBERATELY: the page's own authored measures are wider than Salient's. `.mk-hero__body` and `.mk-who-why__body` are 1040px @20px (~104 characters) at 1280 and 1200px @20px (~120) from 1440 up; the footer disclaimer is 914 -> 1074px @16px (~114 -> ~134). Those are AUTHORED — they are the full content width in both artboards — and they are already FROZEN above 1440 by the container cap. Narrowing them would regress both artboards, which this file is forbidden to do. Flagged for the founder in review/fluid/band-xl.md; it is a design decision, not a band defect. --------------------------------------------------------------------------- WHAT THIS FILE DELIBERATELY DOES NOT TOUCH --------------------------------------------------------------------------- * Full-bleed BACKGROUND bands — 00, 03, 04, 05, 06, 08, 14, 17, 18, 19. Their `.row-bg` / `.bg-layer` / `.image-bg` / `img.row-bg-img` keep tracking the viewport, which is exactly Salient's `.row-bg-wrap` behaviour above CW (measured, 0/1920 in the table above). This is also what makes the page read as designed at 1920 rather than as a fixed slab: a 1200px column punctuated by edge-to-edge media. * The 18/19 CTA band's HEIGHT. It is `aspect-ratio: 64/45` on a full-bleed row, so it grows 900 -> 1012.5 -> 1181 -> 1350 across 1280/1440/1680/1920. That is CORRECT-BY-DESIGN and capping it would contradict the artboards: the Figma exports are EN 19-cta-b 2560x1800 (= 1280 x 900) and ES 19-cta-b 2880x2025 (= 1440 x 1012.5), and 900/1280 = 1012.5/1440 = 0.703125 = 45/64 EXACTLY. This band is the one element in the entire design PROVEN by both artboards to scale with viewport width. Its inner stack is centred and its text measure is a fixed 546px, so nothing inside it stretches. * The 07 gallery's horizontal overflow. It is a drag carousel; the track is 2070 wide at every width and `body.mk-page{overflow:hidden}` clips it. The page's own scrollWidth is exactly clientWidth at 1920, 1680, 1440 and 1280. * The 17 map plate's anamorphic stretch. The section spec measures the same stretch between the two artboards (891px tall at BOTH, 1280 -> 1440 wide), so continuing it is the only evidenced behaviour. Flagged, not changed. ========================================================================== */ @media (min-width: 1441px) { /* ========================================================================== 0. THE BAND TOKEN The distance from the viewport edge to the capped container's edge: inset = (viewport - CW) / 2 Written as `calc(50% - var(--mk-frame) / 2)` rather than `calc((100vw - 1440px) / 2)` for two reasons that are both correctness, not style: 1. NO `vw`. `100vw` includes the classic scrollbar; `.mk-container` resolves its own centring from `width:100%` + `margin-inline:auto`, which does not. On a platform with non-overlay scrollbars a `vw` form would put the rail ~7-8px right of every other section's ink. A percentage resolves against the containing block's inline size — the same box `.mk-container` measures against — so the two agree exactly on every platform. 2. NO MAGIC NUMBER. `--mk-frame` is `min(100vw, CW)`, so above CW it IS CW. If the single-owner pass swaps grid.css for grid-fluid.css (`--mk-frame: min(100vw, var(--mk-container-width))`) or the founder widens CW, this tracks it with no edit here. It also degrades to exactly 0 rather than going negative if CW is ever raised above 1441, because at vw < CW the expression is 50% - 50% = 0. Consumed only by §1. Declared on .mk-page (= ) so it inherits. */ .mk-page { --mk-xl-inset: calc(50% - var(--mk-frame) / 2); } /* ========================================================================== 1. THE EDITORIAL RAIL — sections 09, 10, 11, 12, 13. ========================================================================== ⚠ SUPERSEDED — READ THIS BEFORE YOU TRUST ANYTHING BELOW IT. Correction by lane `r7:xl-fix` under OBS-XL-02 finding XL-03. This section used to be titled "THE ONE REAL DEFECT IN THIS BAND". It is not the live fix and has not been for some time: every one of the five selectors below is overridden at higher specificity by `sections/09-recovery-42.css:807-813` (`#s09… , #s10-recovery-41, … { padding-inline: 0 }` — id specificity (1,1,0)/(1,0,0) against these (0,2,0)/(0,1,0), so source order cannot save them), with `css/rhythm.css:495-505` restating it belt-and-braces. ALL FIVE MEASURE `padding-inline: 0/0` AT 1750. §1 IS DEAD CODE. THE SUPERSESSION IS DELIBERATE AND THE REPLACEMENT IS BETTER, so do not "restore" this. `rhythm.css:476-493` records the decision: `r3:recovery-plan` moved the page gutter onto the rail's OWN padding via `--mk-rplan-gutter: calc(var(--mk-page-x) + max(0px, (100vw - 1440px) / 2))`, which bleeds the row on BOTH edges instead of insetting it and undoing half. Measured live at 1280 / 1440 / 1750: rail ink 120 / 120 / 275 against page gutter 120 / 120 / 275 — in register at every width — and the media column's right edge 1280 / 1440 / 1750, flush to the viewport at every width. The rules are LEFT IN PLACE rather than deleted: they are provably inert, and deleting them is a behaviour change this lane did not measure. What is corrected here is the PROSE, because the next reader was being told a dead rule was load-bearing — and rebuilding on a stale premise is precisely the failure XL-01 turned out to be. The `.mk-xl-rail` "preferred hook" named at the end of this section matches ZERO nodes today; if it is ever added, the rail's own `--mk-rplan-gutter` is the mechanism to hang on it, not this one. THE CONSTRUCTION. These five are two-member rows: a 563px text rail measured FROM THE VIEWPORT EDGE (563 = 120 gutter + 323 copy + 120), and a media side that takes the remainder and bleeds to the right edge. Both artboards agree the text side is 563 and the media side is whatever is left: 1280 -> 563 + 717, 1440 -> 563 + 877. WHY EXTRAPOLATING THAT IS WRONG. The two artboards make two statements that are INDISTINGUISHABLE at 1280 and 1440 and DIVERGE above 1440: (a) "the text rail is 563px from the VIEWPORT edge" (b) "the rail's text ink starts at the PAGE GUTTER" At both artboards the page gutter is 120 and the rail's ink starts at 120, so (a) and (b) are the same sentence. Above 1440 the page gutter becomes (vw-1440)/2 + 120 while (a) keeps the ink at 120. Measured on V1 before this file: vw page gutter (every .mk-container) rail ink-left media width 1280 120 120 ok 717 1440 120 120 ok 877 1680 240 120 OFF BY 120 1117 1920 360 120 OFF BY 240 1357 Twenty sections align their first ink at the same x. Five of them stop doing so above 1440. That is a provable break in a relationship that holds at BOTH artboards, so (b) is the reading that survives and (a) is the one that was an artefact of measuring two frames whose gutter happened to equal their container inset. Reading (b) is ALSO Salient's own rule, verbatim: content caps at CW and centres, backgrounds bleed. So this is not a choice between two defensible options — one of them reproduces the template and one does not. WHY `padding-inline` AND NOT `max-width` + `margin-inline: auto`. Salient applies its cap to `.row_col_wrap_12`, an inner wrapper that never carries the section ground. Two of our five (10 and 12) have NO inner wrapper: the SECTION ELEMENT ITSELF is the flex row AND carries the `--mk-surface-mist` ground. A `max-width` there would cap the ground too and the band would stop bleeding — the exact thing Salient does not do. Inline padding shrinks the content box while the background still paints edge to edge, so one mechanism is correct for all five shapes. Measured zero pre-existing inline padding on all five targets, so this adds rather than overrides. WHAT IT FIXES DOWNSTREAM, all in one move: * rail ink-left returns to the page gutter (240 at 1680, 360 at 1920); * media side returns to 877, so the fancy-box / post-grid / column-image crops return to their 1440 aspect (1.949) instead of drifting to 3.016; * the card copy inside the media side — `.inner`, `h3`, `h4`, `p`, `.hover-content` — returns to 757px instead of growing to 1237px. Those are the only running-text boxes on the page that still grew above 1440, i.e. this is the measure guard the brief asked for; * 10-recovery-41's deliberate anamorphic CROP image (`width:164.373%; object-fit:fill`, derived from the Figma imageTransform) stops amplifying: it is 1441.5px at 1440 and was reaching 2230.5px at 1920. It is percentage-based, so restoring the card box restores the crop exactly — no override of the CROP is needed and none is made. PREFERRED HOOK. `.mk-xl-rail` is the intended selector. The five compound selectors below are the CURRENT markup, which has no shared class; a request to add `.mk-xl-rail` to those five nodes is filed in review/fluid/BAND-REQUESTS.md. When it lands, the five can be deleted and nothing else changes. */ .mk-xl-rail, /* 09 — inner flex row, transparent; section keeps the mist ground. */ [data-mk-slug="09-recovery-42"] .mk-recovery-42__row, /* 10 — NO inner row: the section element is the flex row and carries the ground. Padding leaves the ground bleeding. */ [data-mk-slug="10-recovery-41"], /* 11 — inner flex row `.mk-recovery-43__split`, transparent. */ [data-mk-slug="11-recovery-43"] .mk-recovery-43__split, /* 12 — NO inner row, same shape as 10. */ [data-mk-slug="12-recovery-44"], /* 13 — Salient's own markup. `.row_col_wrap_12` is LITERALLY the element Salient caps in the rule quoted in this file's header, so this is the most faithful of the five. Scoped to the direct child so the nested `.row_col_wrap_12_inner` is untouched, and the sibling `.row-bg-wrap` keeps bleeding. */ [data-mk-slug="13-recovery-45"] > .wpb_row > .row_col_wrap_12 { box-sizing: border-box; padding-inline: var(--mk-xl-inset); } /* ========================================================================== 1b. THE OTHER THREE SECTIONS THAT INSET THROUGH --mk-page-x DIRECTLY. Added by the single-owner pass (`fluid-apply`, 2026-08-17) when the xl-vs-lg collision was ruled in this file's favour. REQ-lg-01 point 1: "If xl's, _band-lg.css §1-§3 must go and 02 / 03 / 08 / 18 / 19 still need an owner above 1440." This is that owner for 02, 03 and 08. ========================================================================== THE SAME DEFECT AS §1, IN THREE MORE PLACES. These three do not use `.mk-container`; they write `padding: var(--mk-page-x)` on their own content layer (02-who-why-b.css:79, 03-unique.css:180, 08-recovery.css:170). `--mk-page-x` is flat 120 above 1440 under this file's mechanism, so their ink stays 120 from the viewport edge while the twenty `.mk-container` sections move out to (vw-1440)/2 + 120. Identical in kind to the five rails §1 fixes, and identically provable: the relationship holds at BOTH artboards and breaks only above them. WHY THE SECTION ELEMENT AND NOT THE INNER PADDING. Padding the section shrinks the content box for everything inside it in one move, which is what makes 03's `.mk-bleed-right` image column keep its authored one-gutter overshoot instead of needing its own override: it still pokes exactly 120 past its parent's content box, and that box now ends at (vw+1440)/2. Backgrounds are unaffected — padding never clips a background — so 02's photographic ground and 08's mist keep bleeding, the same property that made §1 use padding for 10 and 12. ^^^ THAT PARAGRAPH IS FALSE FOR THE PART OF 08 THAT SHOWS, AND IT IS THE REASON THIS RULE HAD TO BE SPLIT. Corrected by lane `r7:xl-fix` under OBS-XL-02 / SR-R7-XL-1 (audit: review/r7/xl-band-audit.md, finding XL-01). 08's mist IS a background on the section and does keep bleeding — but the mist is not what the eye sees on the left of 08. The 443px sunset PHOTOGRAPH is `div.column-image-bg`, `position:absolute; inset:0`, and its nearest positioned ancestor is Salient's `.wpb_row` (`position:relative`, MEASURED — its `.row-bg-wrap` is absolutely positioned inside it and would collapse without it). The row sits INSIDE the section's padding box, so an absolutely-positioned box resolving against the row's padding box inherits the section's inline padding in full. Measured before the split, same anchor, fresh headless Chrome, served sha == disk: [data-mk-slug="08-recovery"] div.column-image-bg — rect.x 1280 0.0 flush to the viewport edge (section padding 0/0) 1440 0.0 flush (section padding 0/0) 1750 155.0 155px of empty mist (section padding 155/155) This is the third time this exact ancestor mechanism has been recorded in this build: `02-who-why-b.css:751-756` (R7-06) and `03-unique.css:493-508` (D11, founder-locked, "Image must bleed past margin/padding on the right"). 03 and 08 ARE THE SAME COMPONENT MIRRORED — 03 puts its image column on the right, 08 on the left. 03 was exempted on its image side and 08 never was, so 08 was the only member of that family not bleeding at >=1441. WHY ONLY THE LEFT HALF IS CANCELLED, and why this needed no founder call even though SR-R7-XL-1 flagged one. The concern filed was that releasing the left would leave 08 asymmetric, because the section's content box ends at 1595 at 1750 while the page gutter is at 1475. MEASURED, that concern does not survive: the copy column's own `.vc_column-inner` carries `padding: var(--mk-space-96) var(--mk-page-x)` (08-recovery.css:168-170), and `--mk-page-x` is 120, so 08's copy INK already ends at 1595 - 120 = 1475 — the same pixel as every `.mk-container` section's ink (measured container ink 275 at 1750, and 1750 - 275 = 1475). The right half of the inset is therefore doing real, correct work and is KEPT. Cancelling the left half moves the photograph and NOTHING ELSE: the copy ink measured 878 / 1475 both before and after. THE COST, STATED, exactly as D11 states it for 03. The SPACE_BETWEEN gap is the remainder, so releasing 155 of inset gives 155 of it to the gap: 160 -> 315 at 1750. That is the same trade D11 already accepted on the mirrored section ("196 at 1512, 400 at 1920"), and it is the trade the page's editorial language asks for — copy inset to the gutter, image edge to edge. The paragraph below headed WHAT IT RESTORES was written before that trade was made and now describes 02 and 03's left halves and 08's right half only. WHAT IT RESTORES, and this is the part `FLUID-SYSTEM.md` asked for by name. 03 and 08 are the capped-flex SPACE_BETWEEN pairs. Their gap is `content - 1040`: 0 at 1280, 160 at 1440. Uncapped it keeps growing — 360 at 1680, 680 at 1920. §2.3 reason 1 of FLUID-SYSTEM.md chose CW = 1440 precisely so that "160 is the maximum ... any larger CW invents a gap size the design never displays", and GRID.md §5.2 asks for the unbounded remainder to be capped in exactly these words. Capping the three sections here is what makes that choice real above 1440; without it CW = 1440 was being enforced on twenty sections and ignored on three. NOT INCLUDED, DELIBERATELY: 18-cta-expand and 19-cta-contract. That band is the ONE element in the whole design PROVEN BY BOTH ARTBOARDS to scale with viewport width (REQ-XL-3: EN 1280x900, ES 1440x1012.5, 900/1280 = 1012.5/1440 = 45/64 exactly), and it is already built that way (`aspect-ratio: 64/45` on a full-bleed row). Capping its row would contradict the artboards. Its inner 120px inset is left at 120 for a second, independent reason: the resting card's clip is the literal string `inset(29.7778% 120px 25.5556% 120px round 4px)` inside a `data-nectar-animate-settings` attribute that `js/mk-expanding-card.js` writes to the element inline every frame, and CSS cannot reach it (REQ-lg-03). Moving the copy stack without moving the card would put the two out of register; leaving both at 120 keeps them agreeing, which is the better of the two available states. The card-vs-gutter divergence above 1440 remains REQ-lg-03's open item and is NOT closed here. */ [data-mk-slug="02-who-why-b"], [data-mk-slug="03-unique"] { box-sizing: border-box; padding-inline: var(--mk-xl-inset); } /* 08-recovery — the SAME rule with its LEFT half cancelled, because 08's image column is on the left. See the correction above. WHY A SEPARATE RULE AND NOT A LATER OVERRIDE. A second `[data-mk-slug="08-recovery"] { padding-left: 0 }` would be (0,1,0) against (0,1,0) and would win only on source order — the weakest possible hold, and the band sheets are emitted LAST by _tools/compose.py, so a section file could not counter it either. One declaration with a two-value shorthand has no override chain to decay. It is also why the fix lives HERE and not in `sections/08-recovery.css`: the false premise is this file's, the rule that produces the defect is this file's, and a reader of this file must not have to know that another file quietly undoes half of it — which is exactly the trap `_band-xl.css` §1 fell into (XL-03: five selectors superseded from another file, still presented here as the live fix). `padding-inline: 0 var(--mk-xl-inset)` = left 0, right the inset. Below 1441 this whole file is out of scope, so 08 computes 0/0 at 1280, 1440, 834 and 390 exactly as it did before — the fix cannot reach the artboards, and the tablet/phone 8% row inset (08-recovery.css:58-72, Salient's own `left_padding_tablet_8pct` pair) is untouched. */ [data-mk-slug="08-recovery"] { box-sizing: border-box; padding-inline: 0 var(--mk-xl-inset); } /* ========================================================================== 2. DEV ASSERTION — makes a regression of §1 visible instead of silent. Add `mk-debug-guards` to . Paints a magenta rule down the page gutter and a cyan rule down each rail's ink edge; if §1 is ever removed or out-scoped the two stop coinciding and the page shows it at a glance. Inert without the class, so it costs nothing in the shipped page. REBUILT by lane `r7:xl-fix` under OBS-XL-02 finding XL-02 (MAJOR). The previous form could not fail, which is worse than not existing. It painted both rules with `position:absolute; inset-inline-start: var(--mk-page-x)`. `.mk-container` is `position:static` (MEASURED, all widths), so its `::before` resolved against `section.mk-section` at x=0 and painted at 0 + 120 = 120 while the container's true ink was 275 at 1750. The rails ARE positioned (sticky), but an absolutely-positioned box resolves against the PADDING box, whose left edge is also 0 — and the rails' gutter now lives on their own `padding-left` (`--mk-rplan-gutter`, rhythm.css:476-493) — so the cyan rule painted at 120 too, while the rail ink was likewise 275. Both guards were wrong by the same 155px, so THEY COINCIDED, and coinciding is the signal this section defines as "all correct". The assertion has never been able to fail at any width at which it exists, and it would have passed XL-01 — the very defect class it is here to catch — in silence. THE REBUILT MECHANISM asserts the thing that actually matters and cannot drift from it: a 1px gradient painted with `background-origin/-clip: content-box`, which lands on the element's CONTENT-BOX edge — its real ink edge — no matter which box or which stylesheet put the inset there. There is no positioned-ancestor assumption left to decay. If the container ink and the rail ink ever stop agreeing, the magenta and cyan rules separate and the page shows it, which is what §2 always claimed to do. DEAD SELECTOR, kept deliberately: `.mk-measure-563` matches 0 nodes, and so does §1's "preferred hook" `.mk-xl-rail`. Both are retained so the guard keeps working if either hook is ever added; only `[class$="__rail"]` (3 nodes, measured) resolves today. ========================================================================== */ .mk-debug-guards .mk-container { background-image: linear-gradient(to right, magenta 0 1px, transparent 1px); background-origin: content-box; background-clip: content-box; background-repeat: no-repeat; } .mk-debug-guards .mk-measure-563, .mk-debug-guards .mk-xl-rail, .mk-debug-guards [class$="__rail"] { background-image: linear-gradient(to right, cyan 0 1px, transparent 1px); background-origin: content-box; background-clip: content-box; background-repeat: no-repeat; } }