/* oig-fonts-space-grotesk-css /wp-content/themes/operation-iron-gate/oig/fonts-space-grotesk.min.css */ @font-face{font-family:'Space Grotesk';font-style:normal;font-weight:400;font-display:swap;src:url(/wp-content/themes/operation-iron-gate/oig/assets/fonts/space-grotesk-v22-latin-regular.woff2) format('woff2')}@font-face{font-family:'Space Grotesk';font-style:normal;font-weight:500;font-display:swap;src:url(/wp-content/themes/operation-iron-gate/oig/assets/fonts/space-grotesk-v22-latin-500.woff2) format('woff2')}@font-face{font-family:'Space Grotesk';font-style:normal;font-weight:600;font-display:swap;src:url(/wp-content/themes/operation-iron-gate/oig/assets/fonts/space-grotesk-v22-latin-600.woff2) format('woff2')}@font-face{font-family:'Space Grotesk';font-style:normal;font-weight:700;font-display:swap;src:url(/wp-content/themes/operation-iron-gate/oig/assets/fonts/space-grotesk-v22-latin-700.woff2) format('woff2')} /* oig-elementor-bridge-css /wp-content/themes/operation-iron-gate/oig/elementor-bridge.css */ /* * elementor-bridge.css — operation-iron-gate (LIVE theme) * --------------------------------------------------------------------------- * Rules that exist ONLY to beat Elementor's own frontend resets, which target * elements inside .elementor and therefore outrank the design's plain classes. * * ⚠ THIS IS NOT A COPY OF THE LOCAL THEME'S elementor-bridge.css. * * The hello-elementor-oig bridge (8,824 B) also zeroes Elementor's default * container padding and gap: * .elementor .e-con { --padding-inline-start:0; --gap:0; ... } * That is ONLY safe there because json/convert.py emits layout-.css, * which re-supplies the design's own padding and gap afterwards. * THIS THEME HAS NO layout-.css. Copying those rules here would strip * padding and gap site-wide with nothing to restore them. Do not port them * without porting the generated layout files first. * * --------------------------------------------------------------------------- * RULE 1 — the brand mark rendering at natural size over the hero * * MEASURED LIVE 2026-08-17 at 1440px, on every page: * .nav__mark attr 38x34 natural 869x767 RENDERED 869x767 * top -425px, bottom 342px, hero top 184px -> 158px of hero overlap * * A ~869x767 navy family mark was hanging out of the header across the hero. * It is the SITE BRAND LOGO, not leftover content from an older build, and it * must not be deleted — .nav__brand would become an empty link on all six pages. * * CAUSE — a specificity loss, nothing more: * .elementor img { height:auto; max-width:100% } (0,1,1) custom-frontend.min.css * .nav__mark { height:46px; width:auto } (0,1,0) styles.css:4380 * Elementor's reset wins, height falls back to auto, and .nav__mark's own * width:auto then lets the image draw at its intrinsic 869x767. * * The header markup is an HTML widget inside a Theme Builder template, so the * mark is a descendant of .elementor on every page. There is no markup change * that avoids this — the fix belongs in CSS. * * Restores the design's declared sizes verbatim from styles.css:4380-4381 * (46px at rest, 35px condensed — both deliberately 25% up from 38/28, per the * source comment at styles.css:4371). width:auto preserves the aspect ratio. * * SPECIFICITY, not load order, is what makes these win: * .elementor .nav__mark (0,2,0) > .elementor img (0,1,1) * .elementor .nav.is-condensed .nav__mark (0,3,0) > the rule above * The condensed state therefore still overrides the resting state, exactly as * it does in styles.css. Do not "simplify" by dropping .elementor from the * first selector — at (0,1,0) it loses to Elementor's reset again. */ .elementor .nav__mark { height: 46px; width: auto; } .elementor .nav.is-condensed .nav__mark { height: 35px; } /* * --------------------------------------------------------------------------- * RULE 2 — heading widgets render at Elementor's sizes, not the design's * * In the source a heading carries its design class on the TAG: *

.display-hero{font-size:var(--fs-hero)} * Elementor's Heading widget cannot put a class on the tag. The class lands on * the widget WRAPPER and the tag renders with Elementor's classes only: *
<- 123.84px *

<- 40px * * MEASURED LIVE 2026-08-17, homepage at 1440px: 29 heading widgets, 0 correct. * Every tag rendered at a flat Elementor size regardless of intent: * H1 intended 123.84 -> 40 (--fs-hero clamp(46px,8.6vw,132px)) * H2 intended 120.96 / 77.76 / 68 / 67.68 / 54 / 31.68 / 12 -> all 32 * H3 intended 74 / 16 / 13 -> all 28 * and custom-frontend.min.css additionally forces line-height:1 on every one. * * SEVEN DISTINCT INTENDED SIZES FOR

ALONE. That is why this is fixed in * CSS and NOT by typing a px value into each widget: one number per tag is * wrong by construction. Setting "H2 = 68px" would be correct for one of the * fifteen H2s and would render .ledger__label and .cap__eyebrow — both * intended at 12px — at 68px. It would also freeze every clamp(), so the type * would stop scaling between 320px and widescreen, and would not touch * line-height at all. * * THE FIX — make the inner tag typographically transparent so the source class * on the wrapper governs, exactly as it does in the source markup. * * SCOPING IS THE LOAD-BEARING PART. Applies ONLY to widgets carrying .oig-ht, * which the generator adds only where the SOURCE class actually declares a * font-size. MEASURED on home: 21 widgets carry it (19 were wrong); the other * 8 do not, and 7 of those are ALREADY CORRECT — four

at 10.5px and three *

at 20px, styled by design descendant rules that target the bare tag * (ratios 0.656 and 1.25 against the 16px base, both matching source). A * blanket rule here would outrank those and break the seven while fixing the * nineteen. DO NOT WIDEN THIS SELECTOR. * * Specificity (0,3,0) beats hello-elementor's bare h1..h6 sizing and Elementor's * .elementor-heading-title, so this one does not depend on load order. */ .elementor-widget-heading.oig-ht > .elementor-heading-title { font: inherit; } /* * --------------------------------------------------------------------------- * RULE 3 — Elementor's forced line-height:1 on every heading title * * custom-frontend.min.css ships .elementor-heading-title{line-height:1}, which * discards the source line-heights. On this design they are mostly INHERITED * (body is 1.6) rather than set on the heading, so the forced 1 collapses them. * MEASURED live: every one of the 29 headings had line-height exactly equal to * its font-size, i.e. 1.0. * * ⚠ THE SELECTOR BELOW IS DELIBERATELY IDENTICAL TO ELEMENTOR'S, at the same * (0,1,0) specificity. It wins ONLY because this file is enqueued after * elementor-frontend. That is the whole point: * - it displaces Elementor's rule and nothing else * - it still LOSES to any design rule that is more specific, e.g. * `.foo h3{line-height:1.3}` at (0,1,1) — which is what keeps the unclassed * headings correct * * Do NOT "improve" this to .elementor-widget-heading .elementor-heading-title. * At (0,2,0) it outranks those design rules and breaks them — measured on the * local build: it fixed four headings and broke three. * * BECAUSE THIS RULE DEPENDS ON LOAD ORDER, verify it after any change to the * enqueue order in inc/asset-map.php. The theme's oig/*.css currently print * after uploads/elementor/css/custom-frontend.min.css, which is what makes it * work. */ .elementor-heading-title { line-height: inherit; } /* * --------------------------------------------------------------------------- * RULE 4 — nav overflows between 1081px and 1240px * * styles.css carries a FOUNDER RULING (see its own appended block, "NAV — LINKS * VISIBLE 1081-1240"): the eight nav items must stay on screen in that band * rather than collapse to the burger. Its companion rule tightens the links * "so they FIT between 1080 and 1240". MEASURED LIVE 2026-08-17 they do not: * * viewport 1100 -> .nav__in available 1019 * brand 241 (mark 52 + gap 11 + .nav__names 178 @16px) * + links 653 (ALREADY tightened: gap 10px, 12px type, 7 visible) * + cta 101 * + gaps 48 (24 x 2) * = 1043 needed -> 24px SHORT. The Donate button sat 23px off-screen and * body{overflow-x:clip} cut it. * * The links are already at their tightest, so the space has to come from the * brand. THE MARK IS NOT TOUCHED — styles.css:4371 records that 46/35px was a * deliberate 25% size-up, and this file's Rule 1 restores it. The wordmark text * beside it is the larger share (178px of the 241px) and carries the reduction. * * Scoped to the exact band that overflows. Below 1081 the burger takes over and * the nav is correct (measured at 1024: cta right 975 < 1024). Above 1240 the * design is untouched. * * Recovers ~38px against a 24px shortfall, leaving ~14px of headroom. */ @media (min-width: 1081px) and (max-width: 1240px) { .nav__in { gap: 12px; } .nav__names { font-size: 14px; } /* the design already tightens the CTA below 1080; do the same inside the band */ .nav__cta .btn { padding: 11px 16px; } } /* * --------------------------------------------------------------------------- * RULE 5 — the footer wordmark runs out of room below ~1085px * * .close__mark is `white-space:nowrap` with `font-size:clamp(34px,11.3vw,190px)` * (styles.css:1465 and :4341). Anton renders "Pathfinders for Hope" at almost * exactly 7.47x the font-size, so the line grows nearly as fast as the viewport * while the padding and the fixed 57.6px body inset do not. MEASURED headroom: * * 1440px text 1216 / avail 1259 +43 * 1280px text 1081 / avail 1106 +25 * 1100px text 929 / avail 931 +2 * 1024px text 865 / avail 861 -4 <- overflows its padding box * * At 1024 it spills 4px into its own padding rather than being cut by the * viewport, so the damage is small — but the margin is gone, and any fallback * font makes it severe: the same string in sans-serif measures 980 against * Anton's 865, a 115px penalty. During the font swap, or if Anton fails to * load, the line visibly overruns. (Verified Anton IS loading: document.fonts * reports "Anton 400 normal -> loaded" and the rendered width matches Anton.) * * Backing the coefficient off to 10.4vw ONLY where it is tight restores real * headroom (~66px at 1024) and absorbs the fallback penalty. Above 1240px the * design is untouched, so the desktop wordmark is unchanged. */ @media (max-width: 1240px) { .close__mark { font-size: clamp(34px, 10.4vw, 190px); } } /* * RULE 2 — Elementor's default container padding and gap, SITE-WIDE * * Elementor gives every .e-con a default 10px block padding and a 20px gap. * The design asks for neither: styles.css declares its own vertical rhythm * where it wants one (.sec is padding-block var(--section-y), .hero is 44/132, * .door is 16px). Nested up to five deep, Elementor's defaults compound on top * of the design's spacing on every container on every page. * * MEASURED LIVE 2026-08-17 at 1600x900, homepage, before this rule: * 157 containers * Elementor default padding 1,960px (98 containers x 20px) * Elementor default gap 2,380px (119 gaps x 20px) * ELEMENTOR DRIFT 4,340px * design padding 5,820px (.sec alone 2,544 - correct) * page height 21,644px * * After: page 18,866px. 2,778px reclaimed, 12.8% of the document. * * SCOPING, and both halves matter: * * 1. VERTICAL AXIS ONLY. The local hello-elementor-oig bridge also zeroes * --padding-inline-*, but it can only do that safely because * json/convert.py emits layout-.css to re-supply the design's inline * padding afterwards. THIS THEME HAS NO layout-.css, so zeroing the * inline axis would drop .shell's 24px gutter with nothing to restore it. * Verified after: .shell inline still 24px/24px, max-width still 1440px. * * 2. The Elementor VARIABLES are zeroed, not the padding property. Every rule * in styles.css that declares padding on a design class still wins, because * it sets the property directly rather than the variable. * * PROVEN, not assumed. The rule was injected into the live page and reverted to * measure the delta before anything was written. Seven containers were flagged * as losing 10px; all seven were then checked against styles.css and each landed * EXACTLY on its declared design value, because the design declares only one * side and Elementor's default was supplying the other: * * .crisis__top design padding-bottom:18px 28 -> 18 * .ctb__direct design padding-top:24px 34 -> 24 * .ev__grid design clamp(30px,3.6vw,46px) = 46 56 -> 46 * .fhud design padding-bottom:9px 19 -> 9 * .gpv__foot design padding-top:18px 28 -> 18 * .vch design padding-top:20px 30 -> 20 * * Preserved after the change: .sec 104/104 (and 160/160 where --section-y is at * its 160px cap), .shell gutter 24/24, .shell max-width 1440px, .hero 44/132, * .door 16/16, .door__head 28/30, container min-heights unchanged at 190px total. * * NO font size, colour or design token is touched by this rule. * * Supersedes the hero-only version of this rule (2026-08-17). The hero was the * proving ground; this is the same fix with the scope widened after every design * padding carrier was verified to survive it. */ .elementor .e-con, .elementor .e-con-full, .elementor .e-con-boxed { --padding-block-start: 0px; --padding-block-end: 0px; --gap: 0px; --row-gap: 0px; } /* * RULE 2B — Elementor's default container INLINE padding, SITE-WIDE * (companion to RULE 2 above, which only zeroed the BLOCK axis) * * FOUNDER DECISION 2026-08-18, reversing the "leave it" call from earlier the * same day: zero it site-wide after all, since the un-zeroed inline default * was confirmed identical (not vdt/footer-specific) on every full-bleed * section measured — .vdt, .ctb, .nav, .close all showed the same 10px each * side at 1200px viewport. * * MECHANISM — traced in uploads/elementor/css/custom-frontend.min.css: * .e-con{--padding-inline-start:var(--padding-left); * --padding-inline-end:var(--padding-right);...} * body.rtl .e-con{--padding-inline-start:var(--padding-right);...} (RTL swap, not used on this site) * .e-con{...;padding-inline-end:var(--padding-inline-end); * padding-inline-start:var(--padding-inline-start)} * The REAL applied properties are padding-inline-start/end, consuming the * --padding-inline-start/end variables, which default to --padding-left/right * (var(--container-default-padding-left/right,10px)). Same pattern RULE 2 * already used successfully for the block axis — override the CUSTOM PROPERTY * at higher specificity, let Elementor's own consuming rule apply the zero. * * .shell GUTTER IS SAFE — PROVEN, not assumed. styles.css:102: * .shell{width:100%;max-width:var(--shell);margin-inline:auto;padding-inline:var(--outer)} * .shell's gutter is a real longhand `padding-inline` declaration in the * design's OWN stylesheet, which loads AFTER Elementor's base CSS (RULE 1's * load-order note applies here too) and overrides just the inline component * of whatever Elementor's `padding-inline-start/end` properties set — * regardless of what --padding-inline-start/end resolve to. .shell was never * reading FROM the Elementor variable in the first place, so zeroing that * variable cannot touch it. This is exactly why RULE 2's own before/after * sweep already logged ".shell gutter 24/24" as preserved through the block- * axis version of this same fix. * * RESIDUAL RISK, not fully swept — unlike RULE 2's block-axis change, this * one has NOT been measured against every container on every page the way * RULE 2 was (that sweep found seven containers whose values changed and * verified each landed exactly on its own declared design value). A * container that has no padding-inline/margin-inline of its own AND was * relying on Elementor's un-zeroed 10px default for its only left/right * breathing room would lose it. Spot-checked home page vdt/ctb/nav/close * plus the live footer template (post 116) after this change — all correct. * If a specific container elsewhere on the site loses its inline spacing, * give IT its own padding-inline in styles.css or elementor-bridge.css, * the same way .shell already has one — do not revert this rule wholesale. */ .elementor .e-con, .elementor .e-con-full, .elementor .e-con-boxed { --padding-inline-start: 0px; --padding-inline-end: 0px; } /* * RULE 3 — Elementor wrappers break the design's grid and flex parents * * The design puts its layout on a parent and expects ITS OWN elements to be the * direct children. Elementor wraps every widget in a .elementor-element div, so * the div becomes the grid/flex item and the design element is one level down, * where flex/grid properties no longer reach it. * * `display:contents` removes the wrapper's box from the tree without removing * the element, so the design's children become the real grid/flex items and the * source markup is reproduced exactly. Safe here because these wrappers carry no * styling of their own - no background, no border, and RULE 2 already zeroes * their padding. * * --------------------------------------------------------------------------- * 3A — .vs__row (the "current system vs Operation Iron Gate" comparison) * * The design: * .vs__row { display:grid; grid-template-columns: 1fr auto 1fr } THREE columns * .vs__n { position:absolute; left:...; top:50% } NOT a grid item * so only three elements are grid items: .vs__then, .vs__arrow, .vs__now. * * In the build all FOUR children were bare Elementor wrappers. .vs__n's * position:absolute sat on an inner element and never reached the wrapper, so * the wrapper still consumed a column - four items in a three-column grid, and * the fourth (.vs__now) wrapped onto a second implicit row. * * MEASURED LIVE 2026-08-17 at 1600x900, all five rows: the .vs__now text sat * 47px BELOW its own .vs__then, so row 01's checkmark lined up beside row 02's * struck-through text. * * before row spread 47 47 47 47 47 * after row spread 0 0 0 0 0 * .vs__then left 342 - .vs__arrow left 802 - .vs__now left 872 * identical on all five rows; .vs__n position:absolute, out of flow * * --------------------------------------------------------------------------- * 3B — .sig__spine (the signature rail's vertical line) * * The design: * .sig { position:fixed; top:0; bottom:0; display:flex; flex-direction:column } * .sig__spine { flex:1 1 auto; width:1px; background:var(--hairline) } * .sig__spine::before { height: calc(var(--sig-p,0) * 100%) } progress fill * .sig__tok { top: calc(var(--sig-p,0) * 100%) } the orange diamond * * .sig__spine is a inside a text-editor widget, so it was never a flex * child of .sig. `flex:1 1 auto` did not apply and a bare is display:inline, * which ignores width and height. * * MEASURED before: .sig__spine display:inline, 0x0 - the vertical line was not * drawn at all, and because .sig__tok is positioned as a percentage OF THE SPINE, * a zero-height spine gave the diamond ZERO TRAVEL RANGE. That is why the rail * read as "too short" and why the marker did not track scroll. * * after .sig__spine display:block, 243x1 * 243px is exactly the design's clamp(170px,27vh,270px) at a 900px * viewport, so the spine is now at its declared height. * * NOT A BUG, do not "fix" it: .sig is position:fixed with top/bottom:0, so it * spans the VIEWPORT by design, not the document. Its height is 766px at a 900px * viewport (900 minus the 134px header offset from `body:has(.nav) .sig{top:var(--hdr-h)}`). * It is not meant to run the full page height and is unaffected by page height. * * signature.js computes --sig-p as scrollY / (scrollHeight - innerHeight), read * live on every scroll, so it self-corrects to the current page height. The * container-padding work in RULE 2 required no change here. */ .vs__row > .elementor-element, .sig > .elementor-element { display: contents; } /* * RULE 3C — three more wrapper-intercepts-item-property cases, found by sweep * * SWEEP METHOD (2026-08-17). A naive sweep for "design class with display:grid * or flex whose children are bare Elementor wrappers" returns 80 elements / 56 * signatures on the homepage. THAT LIST IS MOSTLY FALSE POSITIVES and applying * display:contents to it would wreck the page — measured: * .crisis__grid 621 -> 1383 (+762) the 2-column grid collapses * .dsrt__in 1031 -> 1579 (+548) * .gpv__in 592 -> 965 (+373) * .hero__doors 445 -> 691 (+246) * Those wrappers are correctly filling their columns already. * * The real signal is narrower: a bare wrapper is only a defect when the DESIGN * CHILD inside it carries a property that ONLY works on a real grid/flex item — * position:absolute, flex-grow, flex-basis, align-self, justify-self, * grid-column, grid-row, order. The wrapper intercepts it and the property never * applies. That criterion returns 18 on the homepage. * * SECOND GATE: display:contents promotes EVERY child of the wrapper, not just * the design element. It is only safe where each wrapper holds exactly ONE * child, otherwise the parent's item count changes and the layout breaks. Of the * 18, only these three pass both gates, and all three are genuinely defective: * * .fkey > .fkey__i--hollow grid-column:1/-1, must span the whole grid. * MEASURED 242px against a 503px grid — one column. * .vch__plot > .vch__stop position:absolute; offsetParent was the WRAPPER, * not .vch__plot, so it positioned against the * wrong box. * .pcm__panel > .pcm__num position:absolute; same — offsetParent was the * wrapper. It happens to land inside the panel * today, so this one is latent rather than visible. * * Height deltas 0 / 0 / -3, so none of these disturbs surrounding layout. * * THE OTHER SEVEN ARE LEFT ALONE ON PURPOSE — each has a wrapper holding 2-4 * children, so this pattern is the wrong tool and would change the item count: * .oig-header > .skip wrapper holds 2 * .hero__doors > .desc wrapper holds 2 (contents = +246px, worse) * .door > .door__d wrapper holds 2 * .rcpt__c > .stat__src wrapper holds 3 (contents = +43px, worse) * .vs__legend > .vs__key wrapper holds 3 (contents = +9px, worse) * .closer > .clbg / .clbk wrapper holds 4 * .vdt > .vdt__bk wrapper holds 2 * They need per-case fixes — put the property on the wrapper, or change the * markup — each measured on its own. Do NOT extend this selector to them. */ .fkey > .elementor-element, .vch__plot > .elementor-element, .pcm__panel > .elementor-element { display: contents; } /* * RULE 3E — .field Elementor wrapper must not consume flow in .hero__grid * * The source design: .field is position:absolute inside .hero__grid * (position:relative), overlaying the right side of the hero. The graphic * is NOT in document flow — it sits on top of the copy. * * In the Elementor build, .hero__grid has three children wrapped in * .elementor-element divs. Those wrappers ARE in flow (display:block). * The .field div inside its wrapper has position:absolute, but its wrapper * does not — so the wrapper consumes a full block row BELOW the copy and * doors, making the hero ~2x taller than the source. The graphic is there; * it just positions off the wrapper, not off .hero__grid. * * FIX: Apply position:absolute and the source geometry directly to the * Elementor wrapper for .field (element ID c029). This makes the wrapper * itself the absolute overlay, matching the source exactly. * * .field Elementor wrapper = .elementor-element-c029 * Source geometry from styles.css line 315: * position:absolute; right:-10%; top:-14%; * width:var(--field-w,68vw); min-width:620px; * z-index:1; pointer-events:none * * display:contents is NOT used here — it was tried and breaks the field * because the SVG canvas inside needs a sized positioned ancestor to * compute its own dimensions against. */ /* * RULE 3E FIX 2026-08-18 — Elementor element IDs are per-document, not * site-wide, and are not stable across pages. Elementor independently * assigned the same ID "c029" to a completely different element on Get * Help — .tnt, the entire "Tonight / 211" band wrapping * . The unscoped rule below (originally * unscoped; position:absolute + pointer-events:none) hijacked that band on * /get-help/: pointer-events:none is inheritable and nothing re-enabled it * on .enr211 or its children, so the crisis-line button was unclickable at * EVERY viewport (the @media max-width:1180px companion further down * resets position but never resets pointer-events). Confirmed via live * server-rendered HTML: .tnt on /get-help/ carries data-id="c029" and * class elementor-element-c029. * * FIX: scope both c029 rules to the homepage only, matching this file's * own established convention for other homepage-only overrides (see * body.home .display-hero / body.home .hero__sub / body.home .hero__now * elsewhere in this file). */ body.home .elementor-element-c029 { position: absolute !important; right: -10% !important; top: -14% !important; width: var(--field-w, 68vw) !important; min-width: 620px !important; z-index: 1 !important; pointer-events: none !important; /* Elementor sets max-width on containers — override it */ max-width: none !important; } /* Hero headline — pull back ~10% from source spec (132px -> 116px max) */ body.home .display-hero { font-size: clamp(42px, 7.6vw, 116px); } /* .cap__head eyebrow — must be centred; Elementor default alignment overrides justify-content:center */ .cap__head { justify-content: center !important; } .cap__head .cap__eyebrow { justify-content: center; } /* .crisis__top — source: justify-content:space-between (left/right ends) * Elementor container c079 — target by both class and ID to win the specificity war */ .crisis__top, body.home .elementor-element-c079 { justify-content: space-between !important; flex-direction: row !important; align-items: center !important; text-align: left !important; width: 100% !important; } /* .gband__title — source: max-width:min(23ch,88%), text-align:center, margin-inline:auto * Elementor stretches it full width. Enforce the source measure and centering. */ .gband__title { max-width: min(23ch, 88%) !important; text-align: center !important; margin-inline: auto !important; } /* .dsrt__cols — source uses CSS columns:2 for the two-column split with divider. * Elementor renders container c132 as a flex row, which destroys columns layout. * Force display:block on the wrapper so columns:2 on .dsrt__cols can work. */ /* SCOPED to body.home 2026-08-18 -- c132 also exists on For Organizations * as .ojs (the numbered step list in '04 Terms of Engagement'), where * source already wants display:block (the default for
    , unset in * org-chrome.css) so the unscoped version was a silent no-op collision * there, not a visible bug -- scoped anyway per the same per-document-ID * hazard documented above, before a future edit makes it a real one. */ body.home .elementor-element-c132 { display: block !important; } .dsrt__cols { columns: 2 !important; column-gap: clamp(26px, 2.6vw, 44px) !important; column-rule: 1px solid var(--hairline) !important; } .dsrt__cols > .elementor-element { display: block; break-inside: avoid; margin-top: 15px; } .dsrt__cols > .elementor-element:first-child { margin-top: 0; } /* .fstage__ks — labels above each panel must be space-between not centered */ .fstage__ks { justify-content: space-between !important; width: 100% !important; } /* .fstage layout — Elementor wrappers break position:absolute on fstage__back * and fstage__front. Target by element ID to restore source geometry. * * fstage__back (c142): position:absolute, top:0, left:40%, right:0 * fstage__front (c170): position:relative, z-index:2, width:min(320px,86%) * fstage__figs (c180): display:grid, 3-column, sits below the stage */ /* SCOPED to body.home 2026-08-18 -- Elementor element IDs are per-document, * not site-wide. c142/c170 collided with For Organizations (c142 = .otm__wall, * the "joining involves / who can see what" two-column grid; c170 = .ofq__l, * the Q05 FAQ row's label column), forcing position:absolute on .otm__wall * (which source declares position:relative) and collapsing its parent .shell * to near-zero height -- the grid rendered visually detached from its own * section, overlapping the FAQ section below it. MEASURED live before this * fix: .otm computed height 157.6px while its own .otm__wall child measured * 766.5px and rendered position:absolute, top:0, left:40% -- exactly this * rule's Home-only geometry, hijacking a completely unrelated section on a * different page. Same bug class as the c029 collision fixed earlier the same * day (RULE 3E FIX above) -- that fix scoped c029 to body.home; this pair was * missed in that same pass. Confirmed c142/c170 are Home-only (.fstage__back / * .fstage__front, styles.css) via grep across every page's source HTML. */ /* RULE 32 -- MOBILE FIX 2026-08-21: c142/c170 were unconditional (no media * scoping), so their !important always beat styles.css's own mobile fold * for .fstage__back/.fstage__front at max-width:640px (position:relative, * width:100%, no !important). Same class of collision as the c029 fix in * RULE 3E FIX above -- an element-ID override with no upper bound outranks * the design's own responsive rule at every viewport, including phones. * CONFIRMED live: .elementor-element-c142 carries BOTH the ID class and * .fstage__back; computed position stayed "absolute" regardless of * viewport because this rule has no min-width floor. Scoping to * min-width:641px (matching styles.css's own max-width:640px breakpoint * exactly, no gap or overlap) restores the intended mobile stack: the * terminal (fstage__back) and chart (fstage__front) drop into normal flow * full-width, one above the other, instead of the terminal staying pinned * absolute at left:40% over a relatively-positioned front panel. */ @media (min-width: 641px) { body.home .elementor-element-c142 { position: absolute !important; top: 0 !important; left: 40% !important; right: 0 !important; max-width: none !important; width: auto !important; } body.home .elementor-element-c170 { position: relative !important; z-index: 2 !important; width: min(320px, 86%) !important; max-width: none !important; } } /* fstage__figs — 3-column grid; Elementor wrappers inside it must be block */ /* Source targets .fstage__figs>div — bridge to .elementor-element wrappers */ .fstage__figs > .elementor-element { display: block !important; padding: clamp(15px,1.8vw,24px) clamp(10px,1.3vw,18px) !important; text-align: center !important; } .fstage__figs > .elementor-element + .elementor-element { border-left: 1px solid var(--hairline) !important; } /* b tags — navy extrusion text-shadow */ .fstage__figs b { text-shadow: -.5px -.5px 0 rgba(255,252,247,.55), 1px .6px 0 rgba(20,35,63,.26), 2px 1.2px 0 rgba(19,33,60,.2), 3px 1.8px 0 rgba(18,31,56,.15), 4px 2.4px 0 rgba(17,29,53,.1), 5px 3px 0 rgba(16,27,49,.07), 7px 4.5px 14px rgba(20,35,63,.14) !important; } /* Middle figure ($9.4B) — orange with orange extrusion */ .fstage__figs > .elementor-element:nth-child(2) b { color: #C25E14 !important; text-shadow: -.5px -.5px 0 rgba(255,250,243,.6), 1px .6px 0 rgba(120,52,12,.26), 2px 1.2px 0 rgba(116,50,11,.2), 3px 1.8px 0 rgba(110,47,10,.15), 4px 2.4px 0 rgba(104,44,10,.1), 5px 3px 0 rgba(97,41,9,.07), 7px 4.5px 14px rgba(120,52,12,.14) !important; } /* sec--center (system section c194) — Elementor overrides text-align:center */ body.home .elementor-element-c194, .sec--center { text-align: center !important; } .sec--center .shell { text-align: center !important; } .sec--center .lede { margin-inline: auto !important; } /* Target the system section children directly by element ID */ #system-h, body.home .elementor-element-w185, body.home .elementor-element-w186, body.home .elementor-element-w187 { text-align: center !important; margin-inline: auto !important; } /* The heading title inside the widget */ #system-h .elementor-heading-title, body.home .elementor-element-w186 .elementor-heading-title { text-align: center !important; } /* shell container c193 inside system section — * Elementor flex column defaults align-items:flex-start which left-aligns children. * Must be center so every child widget sits centered. */ body.home .elementor-element-c193 { align-items: center !important; text-align: center !important; } /* vch__plot — the bar chart columns need their Elementor wrappers transparent */ .vch__plot > .elementor-element, .vch__axis > .elementor-element { display: contents; } /* vch__col must be a real grid item — restore flex layout for the bar inside */ .vch__col { display: flex !important; align-items: flex-end !important; height: 100% !important; position: relative !important; } /* vch__col > .elementor-element — the bar itself is one level DEEPER than the * .vch__plot > .elementor-element rule above reaches. That rule only makes * .vch__plot's DIRECT children transparent (.vch__col itself, plus .vch__stop's * own wrapper, which sits as a direct sibling of the .vch__col columns). The * .vch__bar span is a GRANDCHILD of .vch__plot — nested one level deeper inside * each .vch__col — so its own Elementor widget wrapper was never neutralized. * * MEASURED: that wrapper computed display:block, height:0px. .vch__bar's own * height:var(--h,100%) and width:100% are percentages, and a percentage height * only resolves against an ancestor with a DEFINITE height — an auto-height * block wrapper has none, so both height and width resolved to 0px and the bar * was a literal 0x0 box. transform:scaleY(1) on a 0x0 element is still * invisible, which is why forcing that transform alone (below) never fixed it. */ .vch__col > .elementor-element { display: contents; } /* vch__bar — ensure scaleY(0) is set so animation works; reduced-motion skips */ .vch__bar { transform: scaleY(1) !important; } /* vch__bar--empty hatch pattern stripped by Elementor's own lazy-load-background * inline CSS: `.e-con.e-parent:nth-of-type(n+4):not(.e-lazyloaded):not(.e-no-lazyload) * * { background-image: none !important; }`. .vch__col (c151, c153 — the two * "n/a" columns) are .e-con.e-parent and past the 4th child, so every * descendant's background-image is force-cleared until Elementor's lazy-load JS * marks them .e-lazyloaded — which never happens, since .vch__bar--empty's * hatch is plain CSS, not an Elementor background-image setting. * * MEASURED: box-shadow (the orange inset border) survives — only * background-image is targeted — so the two hatched bars rendered as bare * outlined boxes with no fill. * * Their selector is 5 class-level simple selectors + !important. This one uses * 6 real ancestor classes (no artificial duplication) to safely outrank it * regardless of source order. */ .dsrt .vch .vch__plot .vch__col .vch__bar.vch__bar--empty { background-image: repeating-linear-gradient(135deg, rgba(224, 122, 47, .34) 0 2px, transparent 2px 7px) !important; } /* dsrt__h spacing — too much gap below THE DATA DESERT eyebrow in live site */ .dsrt__lead > .elementor-element:nth-child(2) { margin-top: clamp(8px, 1vw, 14px) !important; } /* fstage__ks — two labels, space-between */ body.home .elementor-element-c136, .fstage__ks { justify-content: space-between !important; flex-direction: row !important; width: 100% !important; align-items: baseline !important; } /* Hero lede + 211 line — slightly smaller than source */ body.home .hero__sub { font-size: clamp(16px, 1.3vw, 20px); } body.home .hero__now { font-size: clamp(15px, 1.2vw, 19px); } /* * RULE 7 — .lock dividers missing: adjacent-sibling selector broken by Elementor wrappers * * Source: .lock__c+.lock__c { border-left:1px solid var(--hairline) } * .lock__c is inside an .elementor-element wrapper, so the + selector * never fires — the wrappers are the actual siblings, not .lock__c. * * Fix: apply the left border and top hairline to the Elementor wrappers * inside .lock directly, matching the source exactly. */ .lock > .elementor-element + .elementor-element > .lock__c { padding-left: clamp(18px, 2vw, 30px); border-left: 1px solid var(--hairline); } .lock > .elementor-element + .elementor-element > .lock__c::before { left: calc(-1 * clamp(18px, 2vw, 30px) - 1px); } /* At ≤1180px the field stacks below (position:relative) — match source */ @media (max-width: 1180px) { body.home .elementor-element-c029 { position: relative !important; right: auto !important; top: auto !important; width: 100% !important; min-width: 0 !important; margin-top: 44px !important; } } /* * RULE 3D — the same defect on ABOUT, found by the same sweep * * About uses absolutely-positioned decorative and structural layers inside * design parents. Each was positioning against its Elementor wrapper instead of * the design parent, and several were rendering at ZERO SIZE as a result. * * MEASURED LIVE 2026-08-17, before -> after: * .vfield > .vfield__fill 0x0 -> 0x210 * .portrait > .portrait__hint 271x0 -> 271x303 x6 instances * .bio-modal__panel > .bmx__grid 296x0 -> 946x160 * .nhd > .nhd__grid 864x80 -> 884x287 * .phz__rail > .phz__fill 0x0 -> 0x3 * .band.g-navy > .abg 516x189 -> 516x189 (offsetParent corrected) * .stage > .stage__node 14x14 -> 14x14 (offsetParent corrected, x4) * * All seven pass both gates: the child carries position:absolute, and each * wrapper holds exactly one child so display:contents is a clean 1:1 swap. * * .vfield WAS in this list and was REMOVED after measuring: applying it made * things worse, 0x0 -> 0x814. The real defect there is that .vfield ITSELF * renders 0 WIDE despite computed height:210px and position:relative, so * `#vision .vfield__fill{width:100%}` resolves against a zero-width containing * block. display:contents only let the fill escape to a taller positioned * ancestor. .vfield needs its own fix - do not re-add it here. * * About's OTHER 22 hits are left alone — their wrappers hold 2 or more children * (.band.g-stone > .abg/.mgrid, .hof__rail > four segments, .bio-modal__photo > * three, .msc__ph > two, .shell.bhd > two, and so on). They need per-case fixes. */ .band.g-navy > .elementor-element:not(.vfield), .stage > .elementor-element:not(.figure-out), .portrait > .elementor-element, .bio-modal__panel > .elementor-element, .nhd > .elementor-element, .phz__rail > .elementor-element, .vfield > .elementor-element { display: contents; } /* .vfield's OWN direct child (w055's widget wrapper) added 2026-08-18 -- this is the safe, single-child-wrapper pattern this file already uses for .stage/.portrait/etc, just one level deeper: .vfield itself must stay a real box (excluded above, needs its own explicit height/width/ background), but .vfield__fill's position:absolute;top:0;bottom:0 needs its DIRECT parent (.elementor-widget-container) to not be an intervening positioned ancestor with 0 intrinsic height -- Elementor defaults that wrapper to position:relative, so .vfield__fill was resolving top/bottom against a 0-height box instead of .vfield's real 192px. display:contents on just this one wrapper removes it from the box tree so .vfield__fill's containing block becomes .vfield itself. */ /* .vfield excluded 2026-08-18 -- this file's own comment above already documented .vfield must NOT get display:contents (measured 0x0 -> 0x814, made it worse), but the broad .band.g-navy > .elementor-element selector re-caught it anyway since #vision carries both .band and .g-navy and .vfield is its direct child. Confirmed live via computed style: .vfield was display:contents, getBoundingClientRect() 0 height -- nothing could render regardless of the background-image fix below. */ /* * RULE 8 — 05 Contact CTA row (.ctb__cta): missing flex_direction + inherited * 58ch reading-width cap * * c336 (.ctb__cta) had no flex_direction set in Elementor, so it fell back to * Elementor's Container factory default of COLUMN (not the design's implied * ROW — .ctb__cta{display:flex;flex-wrap:wrap} in styles.css never states a * direction explicitly, relying on the CSS default of row, but Elementor's own * --flex-direction custom-property mechanism has its own separate default that * is NOT the CSS spec default). Fixed via the native flex_direction control * (elementor-edit-element), not CSS — this rule is the width-only follow-up. * * MEASURED 2026-08-18 after the flex_direction fix: 3 buttons + 2x14px gaps * need 670.03px. .ctb__cta lives inside .ctb__copy{max-width:58ch} = 594.85px * — present in the ORIGINAL source design too, not introduced by the port — * so button 3 still wrapped, 75.18px short. * * FOUNDER DECISION 2026-08-18: let the CTA row escape the 58ch reading-width * cap rather than shrink the buttons. Scoped to .ctb__cta only — the heading, * paragraph, urgency line and .ctb__direct 2-column grid all keep the 58ch cap * for readability. width:max-content plus max-width:none lets the row take its * natural content width past .ctb__copy's right edge; .ctb overflow:hidden * (styles.css:1291) clips only if it overflows further right than that — * MEASURED clear at 1600px, verify at any new breakpoint if this reflows. */ @media (min-width: 1081px) { .ctb__cta { max-width: none; width: max-content; } } /* MOBILE FIX 2026-08-18: the rule above must NOT apply below 1081px. Below * that breakpoint styles.css's own @media(max-width:1080px) already sets * .ctb__copy{max-width:none}, removing the 58ch cap entirely — the button * row gets real, viewport-scaled room without any forcing needed. Applying * width:max-content unconditionally (the original version of this rule) kept * the row locked to 690.03px on EVERY viewport, including phones — measured * at 413px: row right edge landed at x:700px, ~287px past the screen edge. * .ctb{overflow:hidden} (styles.css:1291) then clipped the overflow instead * of letting the design's own .ctb__cta{flex-wrap:wrap} do its job: "Partner * with us" was fully hidden, "Donate" partially cut off. Scoping to * min-width:1081px keeps the desktop one-row fix and restores mobile wrap. */ /* * RULE 9 — signature rail (.sig) too wide at large screens — founder decision * * signature.css declares `:root{--sig-w:clamp(46px,4vw,62px)}`, one lever used * in four places: .sig's own width, body's left padding (room for the fixed * rail), .ticker's negative-margin compensation, and the header-corner overlay * width. Overriding the SAME custom property (not .sig{width:...} alone) keeps * all four in sync, matching the source file's own "one lever" design intent * documented at signature.css:92-99. * * FOUNDER DECISION 2026-08-18: 62px at rest reads as a wide sidebar rather than * a thin rail on large screens. Target ~28-32px. The 1px .sig__spine line * itself is untouched — this only narrows the column that holds it plus the * vertical labels (.sig__file, .sig__now) and the 26px .sig__seal circle. * * LIVE SITE ONLY — this file is the live-only bridge (see file banner at top), * not a port of the local theme's copy. Does not touch signature.css itself. * * MUST be set on :root, not .sig alone — body{padding-left:var(--sig-w)} and * .ticker{margin-left:calc(-1 * var(--sig-w))} both read the SAME variable * from their own ancestor chain, which does not include .sig. Scoping the * override to .sig only would narrow the rail while leaving body's left * padding and the ticker's compensation on the old 46-62px value — a visible * mismatch. :root is the one place all four consumers actually inherit from. */ :root { --sig-w: clamp(28px, 2vw, 32px); } /* * RULE 10 — 02 The System / The data desert: tighter section-to-section gaps * (founder decision 2026-08-18) — per-section override, same precedent as * styles.css's own [aria-labelledby="who-h"]{padding-block:...} block. * * NOT an --section-y / global RULE 2 change — tried that path first via * elementor-edit-element's native Container "padding" control and PROVED it * inert: that control writes --padding-top/--padding-bottom custom properties, * but RULE 2 (above) already unconditionally zeroes the --padding-block-start/ * --padding-block-end variables those feed into, sitewide, on purpose, for a * different reason. The 120px actually rendering here comes entirely from * .sec{padding-block:var(--section-y)} (styles.css:390) — a class rule RULE 2 * was never meant to touch and Elementor's own padding system can't reach. * MEASURED: --padding-bottom custom property correctly generated at 66px in * post-10.css after the elementor-edit-element write; computed padding-bottom * on the live element still 120px regardless — confirms the override never * had a path to the screen. Reverted that data-layer attempt; this CSS rule * is the only mechanism that actually reaches the rendered padding. * * GAP 1 — "02 The System": empty navy space below the four law items, * before "03 The Glass" starts. MEASURED equal to .sec's own padding-bottom * (120px) exactly — confirmed by gap == system.getBoundingClientRect().bottom * - laws.getBoundingClientRect().bottom — so the section's own bottom padding * is the sole contributor. Halved to 66px (45% reduction). * * GAP 2 — "too much cream space above 02 The System": MEASURED zero gap * between the data-desert section's box and the system section's box * (system.top - desert.bottom == 0px) — they are flush, no double-margin. * The visible cream is therefore desert's OWN padding-bottom (120px, * cream-coloured because it's inside desert's box, band-canvas) — NOT * system's padding-top (which would render navy, not cream, since it's * inside system's own band-deep box). Reducing system's padding-top alone * would not have shrunk the cream area at all; fixed the actual source * instead. Halved desert's padding-bottom to 66px (45% reduction). * * Both scoped by aria-labelledby, reaching only these two sections — no * other band's padding, and --section-y itself, are untouched. */ [aria-labelledby="system-h"] { padding-bottom: 66px; } [aria-labelledby="desert-h"] { padding-bottom: 66px; } /* * RULE 11 — closing verdict ("Every case seen...") font-size, ~12.5% down * (founder decision 2026-08-18) * * .vdt__l is a text-editor widget's raw

    content — checked * elementor-get-schema first: text-editor has ZERO style-tab controls, no * typography setting exists to write to at all (not even the padding-style * workaround RULE 10 tried). CSS is the only mechanism; same precedent as * RULE 10 and styles.css's own [aria-labelledby="who-h"] override. * * SOURCE (styles.css, "second pass" declaration that wins by cascade order): * .vdt__l{max-width:26ch;font-size:clamp(46px,7.4vw,104px); * line-height:.88;letter-spacing:-.026em} * MEASURED live at 1200px before: 88.8px (7.4vw of 1200, confirms clamp was * mid-range, not capped at either end). * * All three clamp values scaled by the same 0.875 factor (12.5% reduction, * middle of the requested 10-15% range) so the responsive curve shape is * preserved, not just the desktop value: * 46px -> 40px 104px -> 91px 7.4vw -> 6.5vw * line-height/letter-spacing/max-width untouched — font-size only, as * instructed. No selector scoping needed beyond .vdt__l itself; it's a * unique class used only in this one closing section. */ .vdt__l { font-size: clamp(40px, 6.5vw, 91px); } /* * RULE 12 — closing verdict (.vdt) section padding-block, ~45% down * (founder request 2026-08-18, second session) * * Tried the native Container "padding" control FIRST, per instruction. * PROVED IT INERT, same mechanism as RULE 10: set padding-top/bottom:20px * via elementor-edit-element on c361, purged _elementor_css + post-10.css + * element-render cache + LiteSpeed, re-measured live at 1200px — computed * padding-top/bottom stayed 156px (unchanged from baseline). Confirmed the * write itself DID succeed (--padding-top / --padding-bottom custom props * read back as 20px on the live element) — it's just that .vdt's own * padding-block declaration below doesn't consume those variables at all, * so the native control has nothing to feed into. Reverted the per-element * setting on c361 cleanly (back to empty/unset) before writing this rule. * * SOURCE (styles.css, "second pass" declaration that wins by cascade order): * .vdt { padding-block:clamp(104px,13vw,210px) } * MEASURED live at 1200px before: 156px each side (13vw of 1200, confirms * clamp was mid-range, not capped at either end). * * All three clamp values scaled by the same 0.55 factor (45% reduction, * middle of the requested 40-50% range) so the responsive curve shape is * preserved, not just the desktop value: * 104px -> 57px 210px -> 116px 13vw -> 7.15vw * font-size / color / everything else on .vdt and .vdt__l is untouched, as * instructed. * * SELECTOR: .vdt.band-navy — two real ancestor classes already present on * the element (css_classes: "vdt band-navy rv"), specificity (0,2,0), * which outranks styles.css's own plain .vdt at (0,1,0) regardless of file * load order. No artificial class duplication needed. */ .vdt.band-navy { padding-block: clamp(57px, 7.15vw, 116px); } /* * RULE 13 — Contact section terminal card (.term) width + height compaction * (founder request 2026-08-18, third task — vs. Figma) * * PART A — WIDTH. Neither .term nor .term__frame carries a max-width * anywhere in styles.css — the card is a plain block child of .ctb__stage * (one column of .ctb__in's 2-col grid) and simply fills 100% of that * column's width. MEASURED live before: .term 528.66px == .ctb__stage * 528.66px, exactly full-column, confirming "stretching wide." The card's * own animation is literally named term-float (styles.css) — a floating * plate, not a full-width stretched panel — consistent with the Figma's * compact card. Scoped to desktop (min-width:1081px), matching .ctb__in's * own breakpoint where it collapses to a single mobile column * (@media max-width:1080px) — same mobile-safety scoping precedent as the * Contact CTA row fix earlier in this file; a 52%-width floating card would * be cramped on the single-column mobile layout. * * PART B — HEIGHT. .term__screen has NO height/min-height rule anywhere in * styles.css — it is purely intrinsic: padding (22px top / 20px bottom) + * .term__body's 7 .tml line-rows, each sized by .tml's own * line-height:2.02 / min-height:2.02em. MEASURED live before: term__screen * height ≈217px (padding 42px + body ≈174px for 7 lines). Checked for a * responsive .tml override first (per RULE 10/11 precedent) — only * font-size (@media max-width:560px) and opacity (@media * prefers-reduced-motion:reduce) are overridden elsewhere; line-height and * min-height are not touched by any other rule, so a global change here is * safe. Reduced padding-block (22\/20 -> 16\/14, longhand only — horizontal * padding untouched) and .tml's line-height\/min-height together (2.02 -> * 1.56, ~23% tighter) to land term__screen at the requested ~160-170px. * Font-size, the 7-line count, actual terminal text/content, and the * typing-animation JS/opacity logic are all untouched — vertical spacing * only, as instructed. */ @media (min-width: 1081px) { .term { max-width: 52%; margin-inline: auto; } } .term__screen { padding-top: 16px; padding-bottom: 14px; } .tml { line-height: 1.56; min-height: 1.56em; } /* * RULE 14 — Story page: six multi-item components broken by the same * wrapper-intercepts-sibling-relationship pattern as RULE 3/3A-3E, found on * page 15 (founder request 2026-08-18, "Story Page Fix") * * Two distinct sub-cases, both needing the same display:contents fix: * * A) .idc__row (identification strip) already had 3 SEPARATE widgets in * Elementor — one per .idc__c paragraph — but each sits inside its own * .elementor-widget-container wrapper, so .idc__c + .idc__c (adjacent- * sibling, draws the seam divider between cells) never matched: the * wrappers are the real siblings, not .idc__c itself. Same root cause as * RULE 7's .lock__c fix elsewhere in this file. * * B) .inv, .rte__l, .qpr, .ech, .swp were each ONE merged text-editor widget * holding 2-4 items as raw HTML, not separate widgets at all. * MEASURED live before fixing content: .rte__l's 4 stops (Colorado * Springs / Denver / Salt Lake City / Las Vegas) all rendered inside a * single grid cell of a 4-column grid — visually overlapping and * unreadable, the most severe instance. .qpr's two sentences ran * together with zero gap (flex-column gap had only one child to act on). * .inv/.ech/.swp's flex gaps collapsed to the browser's ~4-5px default * inline-whitespace distance instead of their designed clamp() gap. * Split into one native text-editor widget per item first (content fix, * matching source markup and Founder Ruling 6 — still native widgets, * just one per item instead of one merged) — THEN this same wrapper * problem from case A applies to the new structure too, since each new * widget is its own wrapped child. * * Both cases need exactly the same fix: each wrapper holds exactly ONE * child (the safety gate RULE 3C/3D established before using * display:contents), so promoting the wrapper out of the tree makes the * design elements true direct children again — restoring .idc__c's * adjacent-sibling divider, .rte__l's 4-column grid placement, .qpr's flex * column + nth-child(2) stagger delay, and .inv/.ech/.swp's flex gap and * nth-child stagger delays, all of which depend on true DOM sibling * adjacency, not just presence in the subtree. */ .idc__row > .elementor-element, .inv > .elementor-element, .rte__l > .elementor-element, .qpr > .elementor-element, .ech > .elementor-element, .swp > .elementor-element { display: contents; } /* * RULE 14 FOLLOW-UP — display:contents fixes GRID\/FLEX ITEM PARTICIPATION * (a render-tree concern) but does NOT change the DOM tree, which is what * adjacent-sibling (+) and :nth-child() selectors actually match against. * MEASURED after the display:contents rule above: .idc__c border-left * still "0px none" on every cell (divider never drew) and every stagger * transition-delay this page relies on (.rte__s, .qpr span, .inv__i, * .ech__i, .swp__i) still computed "0s" — confirmed live before writing * this, not assumed. DOM structure verified live: each item is exactly one * level under its wrapper (.rte__l > .elementor-element-XXX > .rte__s, * no extra nesting), so a single child-combinator step reaches it — same * depth RULE 7's .lock__c fix already established for this exact class of * problem. Re-targets every source rule that depended on true DOM sibling * adjacency, at the wrapper's position instead of the design element's. */ .idc__row > .elementor-element + .elementor-element > .idc__c { border-left: 1px solid var(--hairline); } .rte.is-in .rte__l > .elementor-element:nth-child(2) > .rte__s { transition-delay: 0.1s; } .rte.is-in .rte__l > .elementor-element:nth-child(3) > .rte__s { transition-delay: 0.2s; } .rte.is-in .rte__l > .elementor-element:nth-child(4) > .rte__s { transition-delay: 0.3s; } .qpr.is-in > .elementor-element:nth-child(2) > span { transition-delay: 0.14s; } .inv.is-in > .elementor-element:nth-child(2) > .inv__i > span { transition-delay: 0.18s; } .inv.is-in > .elementor-element:nth-child(3) > .inv__i > span { transition-delay: 0.36s; } .ech.is-in > .elementor-element:nth-child(2) > .ech__i { transition-delay: 0.14s; } .ech.is-in > .elementor-element:nth-child(3) > .ech__i { transition-delay: 0.28s; } .swp.is-in > .elementor-element:nth-child(2) > .swp__i { animation-delay: 0.55s; } .swp.is-in > .elementor-element:nth-child(3) > .swp__i { animation-delay: 0.8s; } .swp.is-in > .elementor-element:nth-child(2) > .swp__i > span { transition-delay: 1.2s; } .swp.is-in > .elementor-element:nth-child(3) > .swp__i > span { transition-delay: 1.45s; } /* * RULE 15 — Story page "02 how this started" section: ghost year + record * grid both broken by the SAME Elementor-container-default-position bug * (founder request 2026-08-18, "Story Page Section Fix") * * .sta__sheet (record grid texture) and .sta__yr ("2021" ghost number) are * two sibling s in source (story.html), both direct children of *

    , both position:absolute against .sta * (.sta{position:relative;overflow:hidden}). Live, Elementor merged both * into ONE text-editor widget (id w019) — same pattern already fixed for * .rte__l etc. above — but the defect here is different: MEASURED live, * w019's own wrapper div computes position:relative (an Elementor default, * not anything in our CSS) with height:0 (collapsed, since both its * children are position:absolute and removed from flow). That makes the * WRAPPER — not .sta — the containing block .sta__yr's top/left resolve * against, and the wrapper's own collapsed position (wherever it fell in * normal flow, which landed right at the heading) is what the ghost year * was really positioning from. Rendered top was 1369px against .sta's own * top of 1151px and an intended offset of ~77-110px — i.e. ~140-220px * lower than the source's "large, centered behind the headline" placement, * and .sta__sheet's background-image was computing correctly but on a * 0-height box, so the grid texture was invisible despite the CSS matching. * * NOT the same fix as RULE 14 above: .sta ALSO has .shell as a direct * sibling child (c039), and .shell carries the base elementor-element * class too — checked live before writing this, per RULE 3D/3E's own * false-positive caution — so a bare ".sta > .elementor-element" selector * would ALSO collapse .shell's own box (breaking its max-width\/padding). * Targets the specific widget id instead, exactly RULE 3E's precedent for * an unscoped selector risk, not the generic RULE 14 pattern. * * Scoped to this one section only, per instruction — the other three .sta * sections on this page ("the calls," "Vallejo," "the founding") likely * carry the same defect on their own sheet\/yr widgets, each with a * different widget id, but were not in scope for this fix and were not * touched. */ .sta > .elementor-element-w019 { display: contents; } /* * RULE 15 FOLLOW-UP — identical bug, sitewide on the Story page (founder * request 2026-08-18, "Story Page Section Fix" claim 4 + "Fix Remaining * Sections") * * Checked all 8 remaining .stg\/.sta__sheet\/.sta__yr widgets on page 15 * (full inventory pulled from _elementor_data) before touching anything. * MEASURED every one live: textureHeight 0px on all 8, exact same cause as * w019 — the wrapper computes position:relative with height:0. This is * genuinely sitewide on this page, not isolated to the one section fixed * above: * w006 #story-open (hero) .stg only * w046 "the calls" (.sta) .sta__sheet only (no year in source here) * w073 "Vallejo" (.sta) .sta__sheet + .sta__yr (2023) * w103 "the founding" (.sta) .sta__sheet + .sta__yr (2024) * w041 "account 01" (.ham) .stg only * w068 "account 02" (.ham--big) .stg only * w098 "account 03" (.ham) .stg only * w120 "account 04" (.ham--close) .stg only * * Same false-positive risk checked and confirmed present on every one of * these 8 sections too: each has exactly two direct children, the texture * widget and a sibling .shell container, and .shell also carries the base * elementor-element class — so every rule below targets its specific * widget id, never a bare "> .elementor-element". */ #story-open > .elementor-element-w006, .sta > .elementor-element-w046, .sta > .elementor-element-w073, .sta > .elementor-element-w103, .ham > .elementor-element-w041, .ham > .elementor-element-w068, .ham > .elementor-element-w098, .ham > .elementor-element-w120 { display: contents; } /* * RULE 16 — Story page route rail (.rte): dots floating off the line + * all four dots orange instead of first-three-navy/last-orange (founder * request 2026-08-18, "Story Page: Route Timeline Fix") * * PART A — GAP. .rte__rail (+ its child .rte__fill) and .rte__dash are * both merged into widget w033, a direct sibling of .rte__l (c035) inside * .rte (c036). Same bug as RULE 15\/15-followup: w033's own wrapper div * computes position:relative (Elementor default) and collapses to the * flow position right after .rte's 26px padding-top (measured live: * wrapper\/.rte__l both landed at the same top, 2075px, because the * zero-height collapsed w033 takes no flow space of its own). .rte__rail's * top:9px then resolves against THAT wrapper (2075+9=2084 measured) instead * of .rte itself (.rte top 2049+9=2058 intended) — a 26px gap, matching * .rte's own padding-top exactly. .rte__l's positioning was never wrong; * only the rail\/dash's containing block was. * * PART B — COLOR. Source: .rte.is-in .rte__s:last-child::before{background: * orange}. Splitting .rte__l into 4 separate widgets (done fixing the * overlap bug earlier) means each .rte__s is now the ONLY child of its own * wrapper — so :last-child is trivially true for all four, and the source * rule (still live, unmodified, in story-chrome.css) paints every dot * orange. Same root cause as the :nth-child() stagger-delay bug already * fixed above; this one was missed at the time because it's a color * override, not a timing one. Fixed here by re-deriving true "last of the * four" from the WRAPPER's position (which is a real, correct DOM sibling * set) instead of the design element's, at higher specificity so it * overrides the still-present original rule for the first three too — * without this, items 1-3 would keep getting orange from the unmodified * source rule even after the true-last item is corrected. */ .rte > .elementor-element-w033 { display: contents; } .rte.is-in .rte__l > .elementor-element:not(:last-child) > .rte__s::before { background: var(--navy); border-color: var(--navy); } .rte.is-in .rte__l > .elementor-element:last-child > .rte__s::before { background: var(--orange); border-color: var(--orange); } /* * RULE 17 — Story page: record-grid textures (.stg, .sta__sheet) stripped * by Elementor's own lazy-load-background-images inline CSS, same bug class * already found+fixed on the homepage (.vch__bar--empty) and For * Organizations (.ofw\/.oof). MEASURED live: Elementor's * ".e-con.e-parent:nth-of-type(n+4):not(.e-lazyloaded):not(.e-no-lazyload) * * {background-image:none!important}" strips 4 of 5 .stg instances (all four * .ham bands — only #story-open's, an earlier sibling, survives) and 3 of 4 * .sta__sheet instances (only "how this started", the first .sta section, * survives) — none of these are Elementor background-image widget settings, * so they never receive .e-lazyloaded and the strip is permanent, not a * timing issue. * * Selectors use 6 real ancestor\/self attributes each (matching the * .vch__bar--empty precedent's "outrank Elementor's 5-class selector" * approach) rather than inventing classes: .sec.ham[data-screen-label] (3) * + .stg[data-live][aria-hidden] (3) for the hammer bands; .sec.sta * [data-screen-label][data-prog] (4) + .sta__sheet[aria-hidden] (2) for the * account sections. #story-open's own .stg is already correct (an earlier * sibling, past Elementor's rule doesn't reach it) and unaffected by this * rule since #story-open carries no .ham\/.sta class. * * mask-image values use each element's OWN final (cascade-winning) source * declaration — .sta__sheet has two mask-image declarations in * story-chrome.css (one in its original block, one in the later "CENTRED" * section that supersedes it by load order); this rule reproduces the * winning one (64% 58% at 50% 42%), not the superseded one. */ .sec.ham[data-screen-label] .stg[data-live][aria-hidden] { background-image: linear-gradient(to right, rgba(221, 231, 228, .09) 1px, transparent 1px), linear-gradient(to bottom, rgba(221, 231, 228, .09) 1px, transparent 1px) !important; } .sec.sta[data-screen-label][data-prog] .sta__sheet[aria-hidden] { background-image: linear-gradient(to right, rgba(20, 35, 63, .06) 1px, transparent 1px), linear-gradient(to bottom, rgba(20, 35, 63, .06) 1px, transparent 1px) !important; } /* * RULE 18 — Story page: the SAME Elementor lazy-load-background-images bug * as RULE 17, found on seven more decorative elements while verifying a * founder-reported "animated lines" claim in the "the calls" section * (2026-08-18). MEASURED live: the real animated feature there is * .dead__spine — ONE vertical dashed line down the centre that marches * downward (background-position keyframe), not "horizontal lines with * inward-pointing arrows" — the screenshot's red arrows read as Figma * comment\/review annotations pointing at the gap sizing, not real page * elements; nothing resembling them exists in story.html or story-chrome.css. * The real defect: .dead__spine's transform (scaleY reveal) was fine — * confirmed by disabling its transition and reading the resolved value * (matrix(1,0,0,1,0,0), i.e. scaleY(1)) — but its dashed background-image * computed "none" live. Same root cause as RULE 17: none of these are * Elementor background-image widget settings, so none ever receive * .e-lazyloaded and Elementor's own * ".e-con.e-parent:nth-of-type(n+4):not(.e-lazyloaded):not(.e-no-lazyload) * * {background-image:none!important}" strips them permanently. A full sweep * of every background-image-bearing decorative element on the page (not * solid background-color ones — confirmed those are unaffected, e.g. * .qpr span::after, .dead__stop, .rec__b all use a plain color and were * never touched) found six more casualties beyond .dead__spine: .bld__spine, * .rte__dash, .rte__fill, .nbc .cw>span, .thes .cw>span, and * .ham--close .ham__lit specifically (NOT the bare .ham__lit used in the * first three hammer bands, which correctly has no background-image at all * — those three use a text-shadow glow instead, per story-chrome.css; only * the closing band's marker-highlight variant uses background-image and was * actually affected). * * Selectors use 6-9 real ancestor\/self attributes each, same technique as * RULE 17, reproducing each element's exact source value. */ .sec.sta[data-prog] .dead[data-rv] .dead__spine[data-live][aria-hidden] { background-image: repeating-linear-gradient(to bottom, rgba(224, 122, 47, .75) 0 6px, rgba(224, 122, 47, 0) 6px 14px) !important; } .sec.sta[data-prog] .bld[data-rv] .bld__spine[aria-hidden] { background-image: linear-gradient(to bottom, rgba(46, 125, 91, .28), var(--green)) !important; } .sec.sta[data-prog] .rte[data-rv] .rte__dash[data-live][aria-hidden] { background-image: repeating-linear-gradient(90deg, rgba(20, 35, 63, .34) 0 5px, rgba(20, 35, 63, 0) 5px 12px) !important; } .sec.sta[data-prog] .rte[data-rv] .rte__rail[aria-hidden] .rte__fill { background-image: linear-gradient(90deg, #14233F, #14233F 72%, #E07A2F) !important; } .sec.sta[data-prog] .nbc[data-live] .cw[data-rv] > span { background-image: linear-gradient(rgba(224, 122, 47, .26), rgba(224, 122, 47, .26)) !important; } .sec.sta[data-prog] .thes .cw[data-rv] > span { background-image: linear-gradient(rgba(224, 122, 47, .24), rgba(224, 122, 47, .24)) !important; } .sec.ham.ham--close[data-screen-label] .ham__l[data-live] .cw[data-rv] .ham__lit { background-image: linear-gradient(rgba(224, 122, 47, .26), rgba(224, 122, 47, .26)) !important; } /* =========================================================================== RULE 19 — FOR ORGANIZATIONS: Elementor lazy-load-background-images bug, same recurring pattern already fixed on Home/For-Orgs(bar chart)/Story. Elementor's own inline CSS: '.e-con.e-parent:nth-of-type(n+4):not (.e-lazyloaded):not(.e-no-lazyload) * { background-image:none!important }' strips every descendant background-image inside any e-parent container past the 4th sibling, whether or not it was ever meant to lazy-load. On this page it hit THREE decorative background-image layers that are plain CSS gradients, not Elementor background-image widget settings, so they never earn the .e-lazyloaded class that would exempt them: .ogt__bg — the hairline grid behind '03 What your organization gets' .oof — the whole green-glow navy offer plate's own gradient+shadow background ('Free for the entire pilot') .oof__grid — the hairline grid inside that same offer plate MEASURED 2026-08-18 live: all three computed backgroundImage:'none', confirmed via getComputedStyle. Each override below chains enough real ancestor classes (5-7, matching this file's own established pattern) to outrank Elementor's 5-class selector regardless of cascade order. */ .ogt.e-con.e-parent.e-flex.e-con-full .ogt__bg{background-image:linear-gradient(to right,rgba(20,35,63,.05) 1px,transparent 1px),linear-gradient(to bottom,rgba(20,35,63,.05) 1px,transparent 1px)!important} .ogt .oof.e-con.e-parent.e-flex.e-con-full{background:radial-gradient(120% 130% at 8% 0%,rgba(63,191,132,.2),transparent 56%),linear-gradient(168deg,#132744 0%,var(--navy-deep) 62%)!important} .ogt .oof.e-con.e-parent.e-flex.e-con-full .oof__grid{background-image:linear-gradient(to right,rgba(221,231,228,.07) 1px,transparent 1px),linear-gradient(to bottom,rgba(221,231,228,.07) 1px,transparent 1px)!important} /* =========================================================================== RULE 20 — GET HELP: Elementor lazy-load-background-images bug, same recurring pattern now confirmed on 5 of 6 pages (Home, For-Orgs x2, Story, now Get Help). Hit two decorative hairline-grid layers: .gate__grid — the grid behind "02 The Gate" (what you do not need / your file) .intk__grid — the diagonal-hatch grid behind "03 The Intake" MEASURED 2026-08-18 live: both computed backgroundImage:'none'. .tnt__grid (the Tonight/211 band) was NOT affected — it sits within the first 3 e-parent siblings, below Elementor's nth-of-type(n+4) threshold. */ .gate.e-con.e-parent.e-flex.e-con-full .gate__grid{background-image:linear-gradient(to right,rgba(20,35,63,.055) 1px,transparent 1px),linear-gradient(to bottom,rgba(20,35,63,.055) 1px,transparent 1px)!important} .intk.e-con.e-parent.e-flex.e-con-full .intk__grid{background-image:repeating-linear-gradient(-45deg,rgba(20,35,63,.045) 0 2px,transparent 2px 16px)!important} /* =========================================================================== RULE 21 — HOME: Elementor lazy-load-background-images bug, whole-page sweep. Checked every element on Home whose class name suggests a decorative background (__grid/__bg/__plot/__sheen — 9 candidates); 7 were false positives (pure layout grids with no background-image declared in source: .hero__grid, .doors__grid, .crisis__grid, .gpv__grid, .ev__grid, plus .cap__grid which is display:none by design, plus .vch__plot which is the grid container — .vch__bar is the element with a background and it was already fixed earlier this session). Two were real: .pull__grid — drifting hairline grid behind "The auditor's finding" pull-quote .clbg__grid — the closer band's scan-line grid, "04 The Pilot" section MEASURED 2026-08-18 live: both computed backgroundImage:'none'. */ .elementor-element.pull__grid.e-con.e-parent.e-flex.e-con-full{background:linear-gradient(rgba(221,231,228,.2) 1px,transparent 1px) 0 0/100% 34px,linear-gradient(90deg,rgba(221,231,228,.2) 1px,transparent 1px) 0 0/34px 100%!important} .closer.e-con.e-parent.e-flex.e-con-full .clbg__grid{background-image:repeating-linear-gradient(90deg,rgba(20,35,63,.13) 0 1px,transparent 1px 34px),repeating-linear-gradient(0deg,rgba(20,35,63,.13) 0 1px,transparent 1px 34px)!important} /* =========================================================================== RULE 22 — FOR ORGANIZATIONS: "What you are probably worried about" (.ofr fear rows) — broken two-column layout on all four rows, founder report 2026-08-18. .ofr{display:grid;grid-template-columns:minmax(220px,32%) 1fr} expects exactly TWO grid items per row: a narrow left column (the docket number + NO/stamp + "Our answer" label) and a wide right column (the question + answer). Source markup (for-organizations.html) puts a decorative — source CSS: position:absolute, the scroll- progress top rule — as the FIRST child of each .ofr, ahead of the two real content divs. MEASURED LIVE (post 13, .ofr c034 and its three siblings c043/c052/c061): Elementor wraps that decorative span in its own widget wrapper div (w026 and counterparts), and that WRAPPER — not the absolutely-positioned span inside it — is what actually sits in the grid. The wrapper itself stays position:relative, so it consumes a real grid cell instead of the span's own position:absolute removing it from flow. Result: 3 grid items in a 2-column grid — fill-wrapper (col 1), stamp column (col 2, wrong slot), question/answer column (wraps to a NEW row, col 1 again) — exactly the "NO floating independently, question column disconnected" symptom reported. Same root cause as RULE 3/3B/3C above (Elementor wrapper intercepting a child's own position:absolute), same fix: display:contents on the wrapper, scoped to :first-child only — the OTHER two children each hold 3 and 2 real content widgets (RULE 3C's own documented reason not to blanket display:contents every .ofr child). BEFORE (measured, 1350px-wide .shell): grid-template-columns computed 445.4px / 904.97px (correct, matches minmax(220px,32%) 1fr at this width) but 3 children — col1=fill-wrapper(w026) 445px @ left 112.5, col2=stamp(c030) 904.97px @ left 599.5 (WRONG slot, wide column), col3=question(c033) wraps to row 2, 445px @ left 112.5 (WRONG slot, narrow column). Confirmed identical structure on all 4 rows (w026/w035/w044/w053 each hold only .ofr__fill, each is childCount-3 .ofr's first child). */ .ofr > .elementor-element:first-child{display:contents} /* =========================================================================== RULE 23 — ABOUT: hero section-nav tab bar (.hro__idx) rendering as unstyled stacked plain text, founder report 2026-08-18. Source markup is and about-chrome.css targets the row layout with ".hro__idx ul{display: flex;list-style:none;margin:0 auto;padding:0;max-width:var(--shell)}" — a TAG selector requiring a literal