/* --------------------------------------------------------------------------- R3.7B.5 / R3.7B.5C: Homepage static visual system (Page 2740, the WordPress front page). Enqueued conditionally on `/` only (see Home_Assets::enqueue()) -- never loads on any other route. R3.7B.5C root-cause fix: real-browser QA proved every rule below was losing the cascade to Elementor's own atomic-container/heading defaults, which share this file's own specificity (0,1,0)/(0,2,0) but load AFTER it (`frontend.min.css`/`post-2740.css`), so ties resolved in Elementor's favor regardless of source order. Every layout selector below is strengthened using the exact precedent already established in fgma-archive.css: `.elementor .fgma-…-x.e-con` for containers (reaches (0,3,0), confirmed live every Homepage container/section carries `.e-con`), and `.elementor .fgma-…-x.elementor-widget-heading .elementor-heading-title` for the three Atomic Heading widgets (reaches (0,4,0) and drills past the "explicit beats inherited" trap the same precedent diagnosed for Kit-level heading color/font defaults). No selector references a generated `elementor-element-*` ID, no `!important`, no Elementor Global Settings/ breakpoint changed, no enqueue-order/priority change -- the fix is specificity only, per established convention. Values are cross-verified against Production's own real, fetched CSS (www.fgmarchitects.com's `_nuxt/home.*.css` / `_nuxt/entry.*.css` / `_nuxt/BaseMarkdown.*.css` bundles and its main inline Tailwind stylesheet), never guessed and never copied from Diane. Explicitly DEFERRED (see R3.7B.5C report for the full list): Project data/ images/randomization, hover overlays, reveal animations, hero parallax, heading highlight-fill animation, Practice Areas image swapping + preview media, Insights/video tiles, Vimeo, arrow-icon motion on CTA links, the global scrolled-Header background issue (pre-existing, reproduced on /portfolio/ too -- not a Homepage regression). --------------------------------------------------------------------------- */ :root{ /* Two Production-verified hex values with NO existing --e-global-color-v4-fgma-* equivalent (confirmed: brand-red #F21400, gray #949494 and off-black #282828 all already exist and are reused directly below via their own variables; these two do not). Scoped Homepage-local per the established token discipline -- not promoted to the global Elementor Kit / design system. */ --fgma-home-blue:#586685; --fgma-home-dark:#555555; } /* R3.7B.5G Finding 3: `--fgma-space-10p` was referenced throughout R3.7B.5C/ 5E but was NEVER actually defined anywhere in the shared Additional CSS corpus -- confirmed this round via a direct grep of the full corpus (only 2xs/3xs/xs/sm/md/lg/xl/2xl/component exist). It was mistakenly assumed to exist by analogy with Production's OWN internal Tailwind token of the same name (`--space-10p`, confirmed in Production's real compiled CSS: `clamp(2.375rem,-.4261rem + 10.4225vw,16.25rem)`, which independently resolves to exactly 143.26px @1440 and 99.91px @1024 -- matching this round's own verified Community-grid targets). Since no fgmadev-native equivalent exists, this is defined as a genuine Homepage-local property, scoped to `.fgma-home` (never promoted to the global design system), reproducing Production's own formula byte-for-byte rather than approximating it. R3.7B.5G Finding 6: Practice Areas module inset. No existing --fgma-space-* token reproduces both verified data points (module width 1040 @1440, 765 @1024 -- a DIFFERENT ratio of their own content band at each breakpoint: 80.87% vs 84.07%, ruling out a flat percentage; and a different fixed-px inset at each breakpoint too: 123px vs 72.5px each side, ruling out a flat px value). Solved as the two-point linear ramp the whole rest of this design system already uses for every fluid token (clamp(floor, A + B*vw, ceiling)), fitted exactly to both verified per-side inset values (123px @1440, 72.5px @1024) rather than guessed: B = (123-72.5)/(1440-1024) = 0.121394 px/px = 12.1394vw; A = 123 - B*1440 = -51.8077px. Applied as ADDITIONAL padding-inline on `.fgma-home-expertise` itself (on top of the existing --fgma-gutter already there), rather than a `max-width` percentage -- the prior R3.7B.5E `max-width:min(1040px, 80.87%)` was wrong because that percentage resolves against the section's own PARENT (effectively the viewport), never against the already-gutter- reduced content band, which is exactly why it diverged at 1024 (80.87% of 1024 = 828px, not the verified 765px). Padding added on top of the existing gutter avoids that ambiguity entirely: the element's own content-box width becomes band-minus-double-inset automatically, verified to reproduce 1040px @1440 and 765px @1024 exactly. */ .fgma-home{ --fgma-home-space-10p:clamp(2.375rem,-.4261rem + 10.4225vw,16.25rem); --fgma-home-expertise-inset:clamp(72.5px,-51.8077px + 12.1394vw,123px); /* R3.7B.8B: Production's Practice Areas list row-gap is `--space-2xs` (8.931px @1324). Checked the full existing `--fgma-space-*` corpus before assuming a new token was needed: 3xs/xs/sm/md/ lg/xl/2xl/component all exist, but NONE resolves to 8.931px at any viewport (3xs's own full range is only 4-7px, never reaching 8.931; xs is already ~14.8px at 1324) -- confirmed by direct computation, not assumed. R3.7B.8D: root-caused, not assumed -- R3.7B.8C's real-browser QA resolved Production's own `--space-2xs` fluid formula precisely (`clamp(.25rem,.1518rem + .4911vw,.9375rem)`), superseding R3.7B.8B's own flat `8.931px` (a deliberate, honestly-labelled placeholder used only because a single data point was available at that time). Verified: resolves to 8.931px @1324 (unchanged from B.8B) and ~10.827px @1710 (the new fidelity this round adds) -- never a second, independent guess at the slope. */ --fgma-home-expertise-list-gap:clamp(.25rem,.1518rem + .4911vw,.9375rem); /* R3.7B.8D: Production's Practice Areas list font-size shares B.8B's own confirmed min/slope (`clamp(1.0625rem,.8214rem + 1.2054vw,...)`) but its real ceiling is `2.75rem`, not the `1.9063rem` B.8B carried over unexamined from an unrelated component -- R3.7B.8C's real-browser QA proved the prior ceiling caps too early on wide desktop (correct through the linear range, e.g. still 29.102px @1324, but wrong above it: ~33.755px @1710 is Production's real value, not the capped ~30.5px the old ceiling would have produced). Homepage-Practice-Areas-local -- never a change to the shared/global typography ladder. */ --fgma-home-expertise-list-font-size:clamp(1.0625rem,.8214rem + 1.2054vw,2.75rem); /* R3.7B.5M: the Hero brand SVG's real Production markup carries two asymmetric utility classes directly (`mt-3xl mb-4xl`, confirmed live in Production's own rendered HTML this round) -- reproducing the ACTUAL mechanism, not an invented approximation. `mb-4xl` -> `--space-4xl:clamp(6.375rem,5.2143rem + 5.8036vw,14.5rem)` -- byte-for-byte IDENTICAL to the already-existing `--fgma-space- component` (confirmed by direct formula comparison), so the bottom spacing reuses that existing token directly -- no new property needed for it. `mt-3xl` -> `--space-3xl:clamp(4.25rem,3.3036rem + 4.7321vw,10.875rem)` -- confirmed via a direct grep of the full Additional CSS corpus that no `--fgma-space-3xl` (or any equivalent) exists anywhere, so this is defined here as a genuine Homepage-local property, reproducing Production's own formula byte-for-byte. Verified: resolves to 121px @1440 and 101px @1024, matching this round's own verified top- spacing targets exactly. */ --fgma-home-brand-space-before:clamp(4.25rem,3.3036rem + 4.7321vw,10.875rem); /* R3.7B.5M: Production's real H1+CTA content column carries `mb-3xl md:mb-5xl` (confirmed live) -- a trailing bottom margin on the column as a whole, which is what lets Band 3's own height grow to fit its right-side content rather than being capped at Slot 3's own height. The approved DOM has no such wrapping column (H1/CTA are flat grid-area siblings of Slot 3, not nested in a shared div) -- reproducing the identical VISUAL effect without adding one means applying this same trailing margin to the CTA itself (the last element in the H1->CTA reading order), so its own margin-block-end grows the grid row's natural height exactly as the real wrapping div would. `md:mb-5xl` -> `--space-5xl:clamp(8.5rem,7.125rem + 6.875vw,18.125rem)` -- confirmed via the same corpus grep that no `--fgma-space-5xl` (or equivalent) exists, so defined here as a genuine Homepage-local property, reproducing Production's own formula byte-for-byte. Desktop only (see the CTA rule itself for the explicit mobile reset) -- mobile's own passing flow already has its own spacing and must not gain this additional trailing margin. */ --fgma-home-band3-trailing-space:clamp(8.5rem,7.125rem + 6.875vw,18.125rem); /* R3.7B.6F: Production's Header is fixed + transparent and overlays the Hero at >=600px (Slot 1 top = 0px, confirmed live), but at <=599px the Hero must clear the Header's own real rendered height instead (Slot 1 top = 70px, confirmed live by the same real-browser audit -- the behavioral switch itself was bisected to exactly 600px). No existing token expresses this: `fgma-header.css` has no fixed-height rule of its own (the real Header's height is Elementor- template-level content, not a CSS custom property anywhere in this codebase) -- confirmed by a direct grep before assuming one existed. Homepage-local, same "define locally when no existing token reproduces a verified real value" convention already used for --fgma-home-brand-space- before/--fgma-home-band3-trailing-space above -- never a guess, never reused from an unrelated token, and never `--fgma-space-xl` (which stays exactly as it was, still used elsewhere on the Homepage; this Hero rule simply stops referencing it, see below). */ --fgma-home-hero-header-clearance:70px; /* R3.7B.7C-B: the shared Hero parallax value -- one single property every moving element (Slot 2, Slot 4, the H1, the CTA) AND the Hero's own compensating margin-bottom all consume identically (R3.7B.7C-A's own source-confirmed finding: Production uses exactly one `--scroll` value for every mover, never per-element multipliers). Defaults to `0px` UNCONDITIONALLY, never inline, never JS-required to exist -- the exact same failure-safe convention already established for R3.7B.7B's own motion system: absent JS (disabled/blocked/erroring before it can run), every consumer below simply computes `translateY(0px)`/`margin-bottom:0px`, both inert no-ops, so the Hero renders in its normal static geometry with no possibility of a permanently-translated element or a stray negative margin. fgma-home.js only ever WRITES a non-zero value inline once it has confirmed >=600px and the user has not requested reduced motion -- it never removes or fights this default, only overrides it while active. */ --fgma-home-scroll:0px; } /* --- Section rhythm ------------------------------------------------------- */ /* Production's own `.my-4xl` (used on the Markets/Community headline bands) resolves to the exact same clamp() already established here as --fgma-space-component -- reused directly, not duplicated. Confirmed live every one of these six sections is itself an Elementor container (`.e-con`), so each needs the strengthened selector to reliably win against Elementor's own default container padding (the "gutters collapsing to 10px" finding). */ .elementor .fgma-home-hero.e-con, .elementor .fgma-home-markets.e-con, .elementor .fgma-home-expertise.e-con, .elementor .fgma-home-culture.e-con, .elementor .fgma-home-community.e-con, .elementor .fgma-home-grid.e-con{ max-width:var(--fgma-content-max); margin-inline:auto; padding-inline:var(--fgma-gutter); } .elementor .fgma-home-markets.e-con, .elementor .fgma-home-community.e-con{ margin-block:var(--fgma-space-component); } /* R3.7B.6F Defect 2: root-caused, not assumed -- confirmed live this was the sole genuine Homepage content offset (`--fgma-space-xl`, ~60.5px @1440/~50.66px @1024/~36.06px @407) causing the Hero to sit BELOW the fixed+transparent Header everywhere, when Production only ever does that below 600px (Header clears the Hero there); at >=600px Production's Header overlays the Hero with the Hero itself starting at the true viewport top. `--fgma-space-xl` is untouched (still a real, shared token) -- this rule simply stops referencing it, replaced by the new Homepage-local --fgma-home-hero-header-clearance (see its own derivation above), scoped to <600px only via the override immediately below. Never touches Header template 2746/fgma-header.js/Header CSS itself -- the Header's own fixed/transparent/responsive behavior is correct and untouched; only the Homepage's OWN Hero top offset changes. */ .elementor .fgma-home-hero.e-con{ padding-block-start:var(--fgma-home-hero-header-clearance); } @media (min-width:600px){ .elementor .fgma-home-hero.e-con{ padding-block-start:0; } } /* R3.7B.7C-B: Hero scroll parallax -- Production contract source-confirmed in R3.7B.7C-A. Only Slot 2, Slot 4, the H1 (`.fgma-home-intro`), and the CTA (`.fgma-home-cta`) translate -- Slot 1, Slot 3, and Brand are confirmed STATIC in Production and are never touched here. All four movers consume the SAME `--fgma-home-scroll` value (see its own derivation above) -- never independent per-element calculations. `transform` was confirmed absent from every one of these four selectors before this change (no existing declaration anywhere in this file), so there is no collision to resolve. These are the OUTER Elementor structural elements -- never the INNER `.fgma-home-project- reveal`/`.fgma-home-project-card` elements R3.7B.7B/R3.7B.7B1's own entrance/hover system already owns, so the two transform systems compose as ordinary nested CSS transforms (each element's own `transform` applies within its own local space) rather than either one overwriting the other. Gated to the same >=600px threshold already established for the Hero's own top-clearance contract (R3.7B.6F) and confirmed as Production's own real compiled breakpoint (R3.7B.7C-A) -- below 600px these declarations are structurally absent from the CSS, so no stale transform/margin can ever leak across the breakpoint regardless of what fgma-home.js computes. */ @media (min-width:600px){ /* R3.7B.7C-D: root-caused, not assumed -- confirmed live against the deployed Elementor CSS itself that TWO separate Elementor defaults apply an inherited `transform` transition to these four movers: `.e-con:where(:not(.e-div-block-base)){transition:...,transform var(--e-con-transform- transition-duration,.4s)}` (specificity (0,1,0), affects Slot 2/Slot 4/CTA, all real `.e-con` elements) and `.elementor-element:where(:not(.e-con)):where(:not(.e-div-block-base)):not(:has( .elementor-widget-container)){transition:...,transform var(--e-transform-transition-duration, .4s)}` (specificity (0,2,0), affects the Atomic Heading widget `.fgma-home-intro`). Neither `--e-con-transform-transition-duration` nor `--e-transform-transition-duration` is defined anywhere on fgmadev, so both fall back to their literal `.4s ease` default. Confirmed live by real-browser QA (R3.7B.7C-C) this produced a genuine double-damping defect: the JS rAF loop (R3.7B.7C-B) already smooths `--fgma-home-scroll` on its own, so a SECOND, independent 400ms CSS transition on top of it made these four movers visibly lag behind the Hero's own un-transitioned `margin-bottom` (below), opening a transient gap during scroll, and prevented reduced-motion from settling instantly. `transition:none` added here -- this selector's specificity ((0,3,0), already established by the existing `.elementor` + class + class/type pattern this whole file uses) safely exceeds both inherited rules ((0,1,0) and (0,2,0)), so it wins regardless of load order, no `!important` needed. Confirmed safe to cancel the FULL inherited `transition` shorthand (not just `transform`) rather than a narrower `transition-property` carve-out: none of these four elements have any background-color/border/box-shadow transition-worthy state change anywhere in this file, so the background/border/box-shadow legs of that same inherited shorthand are already inert on them -- cancelling all four is the smaller, simpler, equally-safe override. The JS rAF damping (byte-identical, untouched) is now the ONLY smoothing layer for these movers, exactly matching Production's own real computed transition (none/0s) for its equivalent elements. */ .elementor .fgma-home-slot--2.e-con, .elementor .fgma-home-slot--4.e-con, .elementor .fgma-home-intro.elementor-widget-heading, .elementor .fgma-home-cta.e-con{ transform:translateY(var(--fgma-home-scroll)); transition:none; } /* R3.7B.7C-A's own required finding: Production applies the IDENTICAL (never a separately calculated) negative `--scroll` value as the Hero's own `margin-bottom`, because CSS transforms never affect document flow -- without this compensating negative margin, a growing visible gap would open below the Hero as its content visually rises. This is required, not optional. */ .elementor .fgma-home-hero.e-con{ margin-bottom:var(--fgma-home-scroll); } } /* Reduced motion: defense-in-depth, not strictly load-bearing on its own -- fgma-home.js's own parallax controller already checks `prefers-reduced-motion` and simply never writes a non-zero `--fgma-home-scroll` value when the user has requested it (JS respects the preference at the control layer, since this value's own inline-style nature means a CSS override here could never beat a non-zero inline value the same way `!important`-free CSS overrides win against R3.7B.7B's own attribute-driven states). Included anyway for the same defense-in-depth reason the rest of this file applies it: even if JS somehow still wrote a value, this guarantees the safe end state. APPROVED DEV ACCESSIBILITY IMPROVEMENT -- Production has no reduced-motion handling at all. */ @media (prefers-reduced-motion:reduce){ .elementor .fgma-home-slot--2.e-con, .elementor .fgma-home-slot--4.e-con, .elementor .fgma-home-intro.elementor-widget-heading, .elementor .fgma-home-cta.e-con{ transform:none; } .elementor .fgma-home-hero.e-con{ margin-bottom:0; } } /* R3.7B.5M: root-caused, not assumed -- confirmed live Elementor's own `.e-con` base rule (frontend.min.css) sets a default `row-gap`/`column-gap` of `var(--widgets-spacing-row,20px)`/`var(--widgets-spacing-column,20px)` on every container with no per-instance gap configured in the editor, which is every Hero element -- inserting an unwanted ~20px between each of the four bands on top of the (now-removed, see below) band margin. Production's four bands butt directly against one another with NO generic gap at all on DESKTOP; the entire visible stagger comes from each band's own natural content height. Scoped to the same min-width:900px desktop threshold as the rest of this Hero (complementing the mobile flex-wrap query below -- R3.7Q-039B narrowed that query's own gate to max-width:599px, but its flex-wrap gap behaviour is unaffected either way) so the already-passing mobile flex-wrap gap behaviour is never touched -- mobile's own wrapped-item spacing relies on explicit flex-basis/margin-inline-start values, not on this gap, but neutralising it unconditionally was an avoidable risk to a confirmed-passing area, so it is deliberately NOT applied there. */ @media (min-width:900px){ .elementor .fgma-home-hero.e-con{ row-gap:0; column-gap:0; } } .elementor .fgma-home-expertise.e-con{ margin-block-end:var(--fgma-space-component); } .elementor .fgma-home-grid.e-con{ margin-block-end:var(--fgma-space-component); } /* R3.7B.5E Finding 2: real-browser QA found accumulated Elementor default 10px paddings on nodes never given their own per-instance padding in the editor -- confirmed live root cause: `.e-con{padding-*:var(--padding-*, 10px)}` (frontend.min.css) resolves through unset custom properties to a literal 10px on any such `.e-con`. `main.fgma-home` itself needs this (never targeted before R3.7B.5E). R3.7B.5G's own `.fgma-home-hero-row`/ `.fgma-home-hero-col` entries are REMOVED this round -- those classes no longer exist anywhere in the DOM after the R3.7B.5I Hero restructure (dead selectors were never harmless clutter worth keeping). The NEW `.fgma-home-hero-band` containers introduced this round are ALSO plain `.e-con` elements with no per-instance padding of their own, so they inherit the exact same defect and are added here in the old rows/columns' place -- never a blanket `.e-con{padding:0}`. */ .elementor .fgma-home.e-con, .elementor .fgma-home-hero-band.e-con{ padding:0; } /* --- 1. Hero (R3.7B.5I four-band architecture) ----------------------------- R3.7B.5G's own two-row/two-column model (`.fgma-home-hero-row`/`.fgma-home- hero-col`) is RETIRED this round -- real-browser QA established Production is not a 2x2 grid at all, but four independently-stacked horizontal bands, which the old row/column DOM could not reproduce without fragile negative margins or absolute positioning. Page 2740's Hero subtree was surgically restructured (see R3.7B.5I report) into four sibling band containers, each an `.e-con`, moving the SAME seven existing elements (never recreated, never re-copied) into their new parents: Band 1: Slot 1 Band 2: Slot 2, Brand (DOM order -- desktop CSS visually swaps them) Band 3: H1, CTA, Slot 3 (DOM order -- desktop CSS grid-places Slot 3 left / H1+CTA right) Band 4: Slot 4 This DOM order is deliberately also the correct MOBILE reading/focus order (Slot1, Slot2, Brand, H1, CTA, Slot3, Slot4), so mobile needs no column- level `display:contents` trick anymore -- only the bands themselves collapse to `display:contents` at mobile, promoting their children into ONE shared flex-wrap context on `.fgma-home-hero` itself. Verified slot proportions (aspect-3/2, 56%/37% desktop, 75%/50% mobile) are unchanged from R3.7B.5E/5G -- only the containing structure changed. */ /* R3.7B.5K Defect 1: root-caused, not assumed -- confirmed live the same `.e-flex{flex-direction:column}` Elementor default (frontend.min.css) that forced R3.7B.5E/5G's Hero row/column model into the wrong axis was STILL winning here, since this rule never asserted `flex-direction` explicitly. Asserting `row` here is scoped to the four bands only -- the Hero ROOT itself (`.fgma-home-hero`) is deliberately left as a plain vertical block stack of its four band children on desktop/tablet; only the bands' OWN internal axis changes here. */ .elementor .fgma-home-hero-band.e-con{ display:flex; flex-direction:row; } /* R3.7B.5M: this generic `margin-block-start` (R3.7B.5G/5I) is REMOVED -- confirmed live Production's four bands butt directly against one another with no gap at all; the whole visible stagger is each band's own natural content height (see the Hero root row-gap:0 fix above and Band 2/3's own fixes below for the rest of the mechanism). No replacement generic gap is added, per instruction. */ .elementor .fgma-home-slot.e-con{ aspect-ratio:3/2; } .elementor .fgma-home-hero-band--1 .fgma-home-slot--1.e-con, .elementor .fgma-home-hero-band--4 .fgma-home-slot--4.e-con{ flex:0 1 56%; } .elementor .fgma-home-hero-band--4.e-con{ justify-content:flex-end; } /* R3.7B.7B: each slot's own position-bound colour is exposed as `--fgma-home-slot-color` so the flash/overlay layers below -- both descendants of this same slot -- can inherit the identical value via plain CSS custom-property inheritance, never a hardcoded RGB duplicate and never a colour tied to the Project itself (colour stays with the POSITION, exactly as before). R3.7B.7B1: root-caused, not assumed -- real-browser/source-backed QA proved Production's static tile/anchor base is white; the visible entrance colour comes ONLY from the dedicated moving flash layer (now correctly INSIDE the reveal wrapper, see below), never from the slot itself. The prior `background-color:var(--fgma-home-slot-color)` painting on these four rules is REMOVED -- with it still present, the slot would keep showing a permanently-visible, stationary coloured rectangle behind the moving flash/reveal, only partially fixing the wrong-perceived-entrance defect this round exists to close. The custom property itself is UNCHANGED and still the one source both the flash and the hover overlay read from. */ .fgma-home-slot--1{--fgma-home-slot-color:var(--fgma-home-blue);} .fgma-home-slot--2{--fgma-home-slot-color:var(--e-global-color-v4-fgma-brand-red,#F21400);} .fgma-home-slot--3{--fgma-home-slot-color:var(--e-global-color-v4-fgma-gray,#949494);} .fgma-home-slot--4{--fgma-home-slot-color:var(--fgma-home-dark);} /* R3.7B.6 Step 6/8: minimal static card rules for the Project card fgma-home.js appends into whichever slot it lands on. `position:relative` on the slot (its own `.e-con` base already has no conflicting position) gives the absolutely-positioned overlay/flash layers below a real containing block wherever they end up nesting. R3.7B.6C Defect 2: root-caused, not assumed -- confirmed live Elementor's own `.e-con{--padding- top:var(--container-default-padding-top,10px)...}` default (the exact same residual-padding defect already root-caused and fixed for the Hero bands in R3.7B.5E/R3.7B.5O) was never neutralized on the Project SLOT containers themselves, leaving a visible 10px coloured frame around every Project card at every breakpoint. `padding:0` added here -- this selector's specificity (0,3,0) already exceeds Elementor's literal-application selector `.e-con-full,.e-con>.e-con-inner` (0,1,0), so it wins regardless of load order, no `!important`. Flex-basis/aspect-ratio/outer width-height/margins/ background-color are all untouched -- confirmed by static recomputation (see report) that zeroing padding alone cannot change the outer slot box (aspect-ratio:3/2 is set on the border-box via Elementor's own default box-sizing:border-box, so removing inner padding only gives the content box more of the SAME already-fixed outer box, never growing or shrinking it). */ .elementor .fgma-home-slot.e-con{ padding:0; position:relative; } /* --- R3.7B.7B/R3.7B.7B1: Project-card entrance + interaction layer --------------------------- DOM (built entirely by fgma-home.js, per slot): .fgma-home-slot (existing, R3.7B.5/6) -- overflow:visible, never clips the entrance .fgma-home-project-reveal -- entrance-transform wrapper (translateY(50%)->0); OUTSIDE the card's own overflow:hidden box (Production's entrance must never be clipped by the 3:2 crop box) a.fgma-home-project-card -- unchanged clipping/crop responsibility (R3.7B.6C) img.fgma-home-project-card__image (unchanged crop/srcset/sizes contract, untouched) .fgma-home-project-card__overlay -- solid slot-colour hover/focus reveal layer .fgma-home-project-card__meta h2.fgma-home-project-card__title span.fgma-home-project-card__cta (text + decorative arrow) .fgma-home-project-flash -- colour-flash layer, moved in R3.7B.7B1 (see below) R3.7B.7B1: root-caused, not assumed -- real-browser/source-backed QA proved Production moves ONE wrapper containing BOTH the colour flash AND the Project content together (flash top tracks the reveal wrapper's own translation in exact lockstep, confirmed live); R3.7B.7B had instead left the flash as a SIBLING of the reveal wrapper (a direct child of the slot), so the flash stayed stationary while only the card/image rose underneath it -- the wrong perceived entrance. The flash is now the reveal wrapper's own LAST child (a sibling of the card, appended after it in fgma-home.js) -- it inherits the reveal wrapper's translateY/opacity exactly like the card does, while its own unchanged z-index:2 still keeps it stacked above the card/image within that same moving wrapper. Only ONE thing moved; flash colour/z-index/opacity states/fade timing/delay/ easing are all byte-for-byte unchanged from R3.7B.7B. Failure-safe by construction, mirroring fgma-reveal.css's own established convention exactly: every hidden/locked state below is scoped under `html.fgma-home-motion-ready`, a class ONLY fgma-home.js ever adds, and only synchronously alongside the matching per-card attributes (see that file's own header comment) -- never as a separate, later, fallible step. The flash layer's OWN base rule (below) additionally defaults to `opacity:0` UNCONDITIONALLY (never gated), so even in the narrow window where a card has been built but the ready class/attributes have not yet been set, the flash layer can never appear as a permanently opaque, un-fading colour block over the image -- the one respect in which this system's failure mode differs from fgma-reveal.css's own (there, a registered element's OWN pre-existing opacity is the safe default; here, the flash layer is new markup with no other reason to be visible, so its safe default must be written explicitly). */ .fgma-home-project-flash{ background-color:var(--fgma-home-slot-color); inset:0; opacity:0; pointer-events:none; position:absolute; z-index:2; } html.fgma-home-motion-ready [data-fgma-home-project-flash="visible"]{ opacity:1; transition:none; } /* R3.7Q-006J's own "transition belongs on the DESTINATION state" fix, reapplied here: the fade must be declared on "hidden" (the state being transitioned INTO), never on "visible" (a flip away from "visible" would never animate if the transition lived there instead, for the exact reason recorded in fgma-reveal.css). Production's own confirmed values: 2s duration, .4,0,.2,1 easing, .3s delay -- triggered when fgma-home.js flips this attribute at t=1000ms, so the visible fade spans ~1300ms-3300ms after mount, matching Production exactly. */ html.fgma-home-motion-ready [data-fgma-home-project-flash="hidden"]{ opacity:0; transition:opacity 2s cubic-bezier(.4,0,.2,1) .3s; } /* R3.7B.7B1: `position:relative` added -- the flash layer now reparented inside this wrapper (see the DOM comment above) is `position:absolute;inset:0`, so this wrapper must be a real positioned containing block for that to resolve correctly in every state. No width/height value is added here (would risk the closed slot geometry) -- `display:block` + `height:100%`/`width:100%` already make this wrapper naturally fill the same slot/card dimensions as before. */ .fgma-home-project-reveal{ display:block; height:100%; position:relative; width:100%; } /* Deliberately no unconditional opacity/transform rule for the reveal wrapper itself -- absent the ready class (JS failed after building the card but before starting the timeline), it keeps the browser's own default (opacity:1, no transform), exactly the same "the safe default IS the browser's own default" principle fgma-reveal.css already relies on. */ html.fgma-home-motion-ready [data-fgma-home-project-reveal="pending"]{ opacity:0; transform:translateY(50%); transition:none; } html.fgma-home-motion-ready [data-fgma-home-project-reveal="visible"]{ opacity:1; transform:translateY(0); transition:opacity 1s cubic-bezier(.4,0,.2,1), transform 1s cubic-bezier(.4,0,.2,1); } .fgma-home-project-card{ display:block; height:100%; overflow:hidden; position:relative; text-decoration:none; width:100%; } /* Interaction lock: Production disables Project-card pointer interaction for the first 2500ms. `pointer-events:none` blocks pointer/touch clicks only -- it does NOT remove keyboard focusability or block a keyboard Enter activation on an already-focused link (neither is a "pointer event"), so no `tabindex="-1"` mutation is used or needed; a keyboard user tabbing in during the lock window can still focus and activate the card, which this round accepts rather than fighting (documented, not silently expanded in scope). Absent the ready class, this attribute is never even set (see fgma-home.js), so the anchor keeps its normal, fully-clickable default. */ html.fgma-home-motion-ready .fgma-home-project-card[data-fgma-home-project-lock="locked"]{ pointer-events:none; } html.fgma-home-motion-ready .fgma-home-project-card[data-fgma-home-project-lock="unlocked"]{ pointer-events:auto; } /* R3.7B.6C Defect 1: root-caused, not assumed -- confirmed live Elementor's own global `.elementor img{border:none;border-radius:0;box-shadow:none;height:auto;max-width:100%}` (frontend.min.css) carries specificity (0,1,1) (one class + one type selector), which beat this rule's prior bare `.fgma-home-project-card__image` (0,1,0) regardless of load order -- `height:auto` overrode this rule's own `height:100%`, so the image rendered at its scaled intrinsic aspect ratio instead of filling the locked 3:2 card, leaving the measured ~35-57px of uncovered card at 1440. Strengthened to `.elementor .fgma-home-project-card__image` (0,2,0), which beats Elementor's (0,1,1) by class-count alone regardless of the trailing type-selector -- the same "add `.elementor` to raise specificity past Elementor's own default" precedent already established throughout this file, never `!important`. Image source/srcset generation is untouched -- this is purely a rendered- box fix. R3.7B.7B: the image itself is NEVER part of any entrance/hover/focus transition (Production confirmed: no transform, no scale, no opacity change on the image at any interaction state). */ .elementor .fgma-home-project-card__image{ display:block; height:100%; object-fit:cover; width:100%; } /* R3.7B.7B: solid slot-colour overlay, hidden at rest (opacity:0), revealed only via hover (pointer-capable devices, see the guarded media query below) or keyboard focus. Reuses `--fgma-home-slot-color` (see its own derivation above) -- never a second, independent colour value, and never tied to the Project itself. The transition is declared on this BASE rule (unlike the JS-driven entrance states above) because `:hover`/`:focus-visible` are pure CSS pseudo-class toggles the browser already animates correctly in both directions from one shared declaration -- no "destination-state-only" workaround is needed here. */ .fgma-home-project-card__overlay{ background-color:var(--fgma-home-slot-color); inset:0; opacity:0; position:absolute; transition:opacity .3s cubic-bezier(.4,0,.2,1); z-index:1; } .fgma-home-project-card__meta{ color:var(--e-global-color-v4-fgma-white,#fff); display:flex; flex-direction:column; height:100%; padding:var(--fgma-space-md); } /* R3.7B.7B7: root-caused, not assumed -- real-browser QA proved Production's Project title uses its own `--step-3` scale (30.08px @1324, 32.88px @1710, line-height 1.35), byte-for-byte matching this codebase's own EXISTING `--fgma-step-3` (already used identically for the Community grid tout headings below) -- never a new token, never invented. The prior `--fgma-step-1`/`line-height:1.2` was simply the wrong existing token, ~30-32% too small. Only font-size/line-height change here -- family/weight/colour/transform/transition/position are all byte-for-byte unchanged. */ .fgma-home-project-card__title{ color:inherit; font-family:var(--fgma-font-family); font-size:var(--fgma-step-3); font-weight:var(--fgma-weight-medium); line-height:1.35; margin:0; transform:translateY(100%); transition:transform .5s cubic-bezier(.4,0,.2,1); } /* R3.7B.7B7: root-caused, not assumed -- real-browser QA proved Production's "View Project" CTA text uses `--step-1` (21.14px @1324, 22.34px @1710), matching this codebase's own EXISTING `--fgma-step-1` -- never a new token. The prior `--fgma-step-0` was the wrong existing token (~18-20% too small). No `line-height` was ever set on this rule (relies on the browser default, unchanged) -- no browser/source evidence was found that Production's CTA line-height differs from that default, so it is deliberately left untouched, per instruction. Layout/spacing/underline/ arrow/colour are all byte-for-byte unchanged. */ .fgma-home-project-card__cta{ align-items:center; color:inherit; display:flex; font-family:var(--fgma-font-family); font-size:var(--fgma-step-1); font-weight:var(--fgma-weight-medium); justify-content:space-between; margin-top:auto; } .fgma-home-project-card__cta-arrow{ display:block; flex-shrink:0; } /* Hover: pointer-capable devices only (>=600px AND real hover support) -- a deliberate, approved improvement over Production, which has no such guard and so exhibits the classic "sticky hover" bug on touch devices below 600px (a tap latches the overlay open until a second, unrelated tap). Image/CTA carry no transform/opacity of their own (Production confirmed: no independent motion). */ @media (min-width:600px) and (hover:hover){ .fgma-home-project-card:hover .fgma-home-project-card__overlay{ opacity:1; } .fgma-home-project-card:hover .fgma-home-project-card__title{ transform:translateY(0); } } /* Keyboard focus: an INTENTIONAL accessibility correction, not a reproduction of Production (whose own verified behaviour reveals the overlay on focus but leaves the title permanently translated off-screen -- a real accessibility defect this round deliberately does not carry over). Scoped to >=600px only, matching the same viewport range the overlay/metadata exist in visually; below that, metadata stays in the semantic DOM but is never visually revealed by any interaction, matching Production's own mobile treatment. Never removes the native focus ring. */ @media (min-width:600px){ .fgma-home-project-card:focus-visible .fgma-home-project-card__overlay{ opacity:1; } .fgma-home-project-card:focus-visible .fgma-home-project-card__title{ transform:translateY(0); } } /* Reduced motion: forces the safe, fully-settled end state instantly, regardless of which JS-driven attribute value is currently present and regardless of hover/focus -- the exact same "match the gated rules' own specificity so this wins on source order alone" technique fgma-reveal.css already uses, reapplied Homepage-locally rather than editing that shared file (never touched this round). */ @media (prefers-reduced-motion:reduce){ html.fgma-home-motion-ready [data-fgma-home-project-reveal]{ opacity:1; transform:none; transition:none; } html.fgma-home-motion-ready [data-fgma-home-project-flash]{ opacity:0; transition:none; } html.fgma-home-motion-ready .fgma-home-project-card[data-fgma-home-project-lock]{ pointer-events:auto; } .fgma-home-project-card__overlay, .fgma-home-project-card__title{ transition:none; } } /* Band 2: Slot 2 + Brand -- DOM order is [Slot2, Brand] (matching the correct mobile/focus reading order); desktop visually swaps them via `order` only, never a DOM change. R3.7B.5M: `align-items` changed from `center` to `flex-start` -- confirmed live Production aligns Slot 2 to the TOP of Band 2 (Slot 2's own top exactly equals Band 2's own top), not vertically centred. This selector only ever applies at desktop/ tablet -- the band itself becomes `display:contents` at mobile (see below), so this has no effect there and needs no mobile reset. */ .elementor .fgma-home-hero-band--2.e-con{ align-items:flex-start; justify-content:space-between; } .elementor .fgma-home-hero-band--2 .fgma-home-slot--2.e-con{ flex:0 1 37%; min-width:0; order:2; } /* R3.7B.5K Defect 2: with the row axis now actually applying (Defect 1), Brand's own flex-basis was previously content-derived (`auto`, i.e. shrink/grow-to-fit its content), oversubscribing the row alongside Slot 2 instead of occupying its own dedicated 37% small-column region -- the exact same verified small-column contract Slot 2 already uses. Explicit `flex:0 1 37%` fixes that. */ .elementor .fgma-home-brand.e-con{ flex:0 1 37%; min-width:0; order:1; } /* Band 3: H1 + CTA + Slot 3 -- DOM order is [H1, CTA, Slot3] (matching mobile/focus order); desktop uses CSS Grid (per the task's own instruction to use grid-area/order placement) to place Slot 3 in a left column spanning the full band height, with H1 stacked above CTA in the remaining right column -- grid-area placement is independent of DOM source order, so no reordering hack is needed here at all. R3.7B.5K Defect 3: `37% 1fr` (R3.7B.5I) made the H1/CTA region consume all remaining space (~768px @1440) -- confirmed live Production uses the SAME 37% small-column contract as Slot 3 for the H1/CTA region too, not a flexible remainder. Changed to two fixed `37%` tracks; since their sum (74%) is less than the grid container's own 100%, `justify-content: space-between` distributes the leftover space entirely into the one gap between them (pushing them to opposite edges) -- the same mechanism Band 2 above already uses (flex `justify-content:space-between` with no separate explicit gap value), kept consistent here by not ALSO declaring a fixed `column-gap` on top of the distributed free space. */ /* R3.7B.5O Defect 1: root-caused, not assumed -- confirmed live Elementor's own `.elementor-element:where(.e-con-full,.elementor-widget)` base rule (frontend.min.css) still applies `gap:var(--row-gap) var(--column-gap)` (default `var(--widgets-spacing-row,20px)`) to this grid, since nothing in this file had yet asserted `row-gap` here explicitly -- exactly the same class of residual default already fixed for the Hero root in R3.7B.5M, just never carried down to this specific grid container. This selector's own specificity (0,3,0) already exceeds Elementor's `:where()`-neutralised (0,1,0), so a plain `row-gap:0` wins regardless of load order -- no `!important` needed, consistent with every other fix in this file. Column gap is untouched (grid-template-columns/areas/rows and the H1/Slot3 placement contract are all unchanged, per instruction). */ .elementor .fgma-home-hero-band--3.e-con{ display:grid; grid-template-areas:"slot3 h1" "slot3 cta"; grid-template-columns:37% 37%; grid-template-rows:auto 1fr; justify-content:space-between; row-gap:0; } .elementor .fgma-home-hero-band--3 .fgma-home-slot--3.e-con{ grid-area:slot3; } .elementor .fgma-home-hero-band--3 .fgma-home-intro.elementor-widget-heading{ grid-area:h1; } /* R3.7B.5M: Production's real H1+CTA content column has its own trailing `mb-3xl md:mb-5xl` bottom margin (confirmed live) -- reproduced here as `margin-block-end` on the CTA itself (the last element in the H1->CTA reading order), since the approved DOM has no wrapping column div to put it on. This is what lets Band 3's grid ROW grow to fit its own right-side content naturally, rather than the band being capped at Slot 3's own height -- never a fixed/explicit band `height`, never a viewport-specific offset. Desktop only -- explicitly reset to 0 in the mobile override below, since this selector still matches the CTA at mobile too (`display: contents` on the band removes its own box but not the DOM ancestor- descendant relationship CSS selectors match against), and mobile's already-passing flow must not gain this additional trailing space. */ /* R3.7B.5O Defect 2: root-caused, not assumed -- confirmed live this container carries no per-instance padding setting of its own (WP-CLI settings dump: only `_title`/`css_classes`/`content_width`) and no inline style attribute, so its residual `padding-top`/`padding-bottom:10px` comes purely from Elementor's own unset-custom-property default (`.e-con{ --padding-top:var(--container-default-padding-top,10px)...}`, applied literally via `.e-con-full,.e-con>.e-con-inner{padding-block-start:var( --padding-block-start)...}` in frontend.min.css) -- confirmed NOT an intentional inline value, so safe to remove per this round's own instruction. This selector's specificity (0,4,0) already exceeds Elementor's `.e-con-full` (0,1,0), so a plain `padding-block:0` wins regardless of load order -- no `!important` needed. Block-axis only; the CTA's own trailing `margin-block-end` (R3.7B.5M) and inline sizing are unchanged. */ /* R3.7B.5Q Defect: root-caused, not assumed -- confirmed live this container carries no per-instance padding setting of its own and no inline style attribute (same evidence already established for the block axis in R3.7B.5O), so its residual `padding-left`/`padding-right:10px` is also purely Elementor's own unset-custom-property default, applied literally via the bare `.e-con{padding-inline-end:var(--padding-inline-end); padding-inline-start:var(--padding-inline-start)}` (frontend.min.css, specificity (0,1,0)). Confirmed live: this 10px inline offset was the entire remaining +10px delta between the H1's and CTA's own text-start edge at 1440/1024/407 -- H1 and CTA are grid-area siblings occupying the SAME 37% column, so they must share the same inline edge, and neither Band 3's row-gap (R3.7B.5O) nor any vertical token is implicated. This selector's specificity (0,4,0) already exceeds Elementor's (0,1,0), so a plain `padding-inline:0` wins regardless of load order -- no `!important`. Block-axis padding (R3.7B.5O), trailing `margin-block-end`, and CTA link/typography are all unchanged. */ .elementor .fgma-home-hero-band--3 .fgma-home-cta.e-con{ grid-area:cta; align-self:start; margin-block-end:var(--fgma-home-band3-trailing-space); padding-block:0; padding-inline:0; } /* Mobile: bands collapse entirely (never generate their own box), promoting Slot1/Slot2/Brand/H1/CTA/Slot3/Slot4 into `.fgma-home-hero` itself, which becomes the one shared flex-wrap context -- simpler than R3.7B.5G's own two-level row+column `display:contents` pairing, since the new DOM order already matches the desired mobile sequence with no `order` overrides needed for Bands 2/3 (only Band 3's OWN desktop-only grid placement is what needed undoing, achieved simply by this block not applying at mobile). Verified real bare `w-[75%]`/`w-[50%]` Production mobile values (no `md:` prefix) reproduced below, unchanged from R3.7B.5E/5G. */ /* R3.7Q-039B: root-caused, not assumed -- confirmed live this block's own `max-width:899px` gate was wrong: Production's real contract (R3.7Q-039A) is single-column ONLY at <=599px, two-column from 600px up, and the Hero's own parallax (below, already gated `min-width:600px`) is likewise Production's real >=600px behavior -- so 600-899px was the ONE invalid combination DEV could ever render (this single-column stack + the parallax translateY active on Slot 2/Slot 4/intro/CTA), which is exactly what produced the logo/copy overlap while scrolling in that range. Every one of these 9 selectors already has its own correct, unconditional (two-column) declaration earlier in this file -- this block was always pure MOBILE override on top of that, never the source of the desktop composition -- so narrowing its own gate to <=599px is sufficient by itself: 600-899px now simply falls through to the already-correct, already-existing two-column rules, with no redesign/reinterpretation of any of the 9 declarations below, which remain byte-for-byte unchanged. The parallax rule itself (below) is untouched -- it was never the defect. */ @media (max-width:599px){ /* R3.7B.5K Defect 1 (mobile): the same Elementor `.e-flex{flex-direction: column}` default this round fixed for the bands themselves ALSO applies to the Hero root (it carries `.e-flex` too) -- this rule previously never asserted `flex-direction` explicitly, so it fell through to that column default despite `flex-wrap:wrap` being set. With the bands now `display:contents` below, the Hero root IS the shared wrap context for all seven leaf elements, so it needs the horizontal axis explicitly. */ .elementor .fgma-home-hero.e-con{ display:flex; flex-direction:row; flex-wrap:wrap; } .elementor .fgma-home-hero-band.e-con{ display:contents; } .elementor .fgma-home-hero-band--1 .fgma-home-slot--1.e-con{flex:0 1 75%;} /* `order:0` here is NOT redundant -- it's the required RESET of the desktop-only `order:1`/`order:2` declared on these same two selectors above (a media query only overrides properties it explicitly sets; without this, the desktop order values would persist into this shared mobile flex-wrap context and push Slot2/Brand to the END, after Slot3/Slot4, breaking the required 1-7 sequence). Their natural DOM order (Slot2 then Brand) already matches the desired sequence once this reset removes the leftover desktop values. */ .elementor .fgma-home-hero-band--2 .fgma-home-slot--2.e-con{flex:0 1 50%;margin-inline-start:auto;order:0;} .elementor .fgma-home-brand.e-con{flex:1 0 100%;order:0;} .elementor .fgma-home-hero-band--3 .fgma-home-intro.elementor-widget-heading{flex:1 0 100%;} .elementor .fgma-home-hero-band--3 .fgma-home-cta.e-con{flex:1 0 100%;margin-block-end:0;} .elementor .fgma-home-hero-band--3 .fgma-home-slot--3.e-con{flex:0 1 50%;} .elementor .fgma-home-hero-band--4 .fgma-home-slot--4.e-con{flex:0 1 75%;margin-inline-start:auto;} } /* --- Brand wordmark -------------------------------------------------------- Reuses the exact same canonical inline SVG markup already established in the Header (Template 2746, `.fgma-header-logo`) -- one source, copied verbatim into this one placeholder, never re-invented or duplicated per device. */ .elementor .fgma-home-brand.e-con{ display:flex; align-items:center; justify-content:flex-start; padding-inline:0; /* R3.7B.5M (corrected from R3.7B.5I's symmetric `--fgma-space-2xl` approximation): reproduces Production's own real, asymmetric mechanism directly -- confirmed live the brand SVG carries `mt-3xl mb-4xl`. `mb-4xl` reuses the already-existing `--fgma-space-component` (byte- identical formula to Production's own `--space-4xl`); `mt-3xl` uses the new `--fgma-home-brand-space-before` token (Production's own `--space- 3xl` formula, no existing fgmadev equivalent -- see its own derivation above). Verified: 121px top / 167px bottom @1440, 101px top / 143px bottom @1024 -- matching this round's own verified targets exactly. */ padding-block-start:var(--fgma-home-brand-space-before); padding-block-end:var(--fgma-space-component); } /* R3.7B.5G Finding 1: root-caused, not assumed -- confirmed live the HTML widget wrapper (`.fgma-home-brand-mark-widget`) had no explicit width of its own, so its flex-item sizing fell back to shrink-to-fit; with a percentage-width child (`.fgma-home-brand-mark`, below) and no definite width anywhere in the chain to resolve that percentage against, the SVG fell through to the browser's own 300x150 replaced-element default -- exactly the observed "~300px" symptom. Giving the widget wrapper an explicit `width:100%` (stretching to fill `.fgma-home-brand`'s own available width) gives the percentage below a definite base to resolve against, and `padding:0` removes Elementor's own residual default widget padding. */ .elementor .fgma-home-brand-mark-widget.elementor-widget-html{ padding:0; width:100%; } /* R3.7B.5K Defect 2 (corrected from R3.7B.5I): verified live at both 1440 (476px = 37% of the 1286 content band) and 1024 (337px = 37% of the 910 band) -- the SVG width tracks 37% of the content band. R3.7B.5I applied that 37% HERE, on the mark itself, under the assumption that Band 2 spans the full content band -- but Defect 2 above now gives `.fgma-home-brand` ITSELF `flex:0 1 37%`, so the mark's own immediate containing block is already the correctly-sized 37% Brand region. Applying another 37% here on top would incorrectly compound to ~13.7% of the band -- fixed to `width:100%` (fill the already-37%-wide Brand region entirely), per this round's own explicit instruction not to retain any nested-percentage conversion. */ .fgma-home-brand-mark{ color:var(--e-global-color-v4-fgma-brand-red,#F21400); display:block; max-width:none; width:100%; } .fgma-home-brand-mark svg{ display:block; height:auto; width:100%; } /* Mobile: the 349x291 Production measurement is the WRAPPER's bounding box (349 = the ~407px content band width, already established above; 291 is the wrapper's total height INCLUDING vertical padding), never the SVG's own aspect ratio -- confirmed by inspecting the SVG's real, unchanged viewBox (0 0 100 43, ~2.33:1) against that box (349x291 is nowhere close to 2.33:1). The SVG itself fills the full available content band width (matching "fill the available content band appropriately"), keeping its own intrinsic aspect ratio via `height:auto`; the wrapper gets the same `--fgma-space-lg` block padding already used elsewhere in this file for Production-like vertical spacing, not an invented pixel value -- never stretched to fill the full band height. */ @media (max-width:899px){ .elementor .fgma-home-brand.e-con{ padding-block:var(--fgma-space-lg); } .fgma-home-brand-mark{ width:100%; } } /* --- Hero typography / copy ------------------------------------------------- Production: H1 uses its own `.header-5` scale (AvenirMedium, line-height 1.35) -- confirmed live in Production's own compiled CSS to resolve to `--step-2`, the exact same ramp already established here as --fgma-step-2. Selector strengthened per the archive precedent: an Elementor Kit Global Class default (light-blue Roboto, confirmed live) was reaching the real `

` explicitly, which always beats an inherited ancestor rule regardless of specificity -- drilling to `.elementor-heading-title` itself, with `.elementor`/`.elementor-widget- heading` added for specificity, is what actually wins now. Font sizes themselves are unchanged from R3.7B.5 -- already correct once this cascade fix lands, per instruction not to alter verified sizes without new evidence they moved. */ .elementor .fgma-home-intro.elementor-widget-heading .elementor-heading-title{ color:var(--e-global-color-v4-fgma-off-black,#282828); font-family:var(--fgma-font-family); font-size:var(--fgma-step-2); font-weight:var(--fgma-weight-medium); line-height:1.35; margin:0; } .elementor .fgma-home-cta.e-con{ margin-block-start:var(--fgma-space-md); } /* R3.7B.11A: the previously-deferred motion pass. Production's real markup (confirmed live) is `Let's Collaborate` -- the exact same canonical 26x21 arrow already reused everywhere else in this codebase (`Project_Component_Renderer::CTA_ARROW_SVG`), and the exact same underline contract already implemented for the News/Static tout CTAs (`.underline-styles:after`: 1px, bottom:-.35em, left-origin, scaleX(.01)->1/500ms, opacity/300ms, red). Page 2740's own single Hero CTA widget (`eeeb962`) now wraps its text in a label span and appends this arrow -- own id/href/`_css_classes` untouched, see that page's own before/ after audit. Typography/colour (AvenirMedium/--step-0/line-height 1/off- black) is UNCHANGED from R3.7B.5 -- out of this round's scope, which owns only the arrow and its interaction. */ .fgma-home-cta-link a{ align-items:center; color:var(--e-global-color-v4-fgma-off-black,#282828); display:inline-flex; font-family:var(--fgma-font-family); font-size:var(--fgma-step-0); font-weight:var(--fgma-weight-medium); gap:var(--fgma-space-xs); line-height:1; text-decoration:none; } .fgma-home-cta-link__label{ position:relative; } .fgma-home-cta-link__label::after{ background-color:var(--e-global-color-v4-fgma-brand-red,#F21400); bottom:-.35em; content:""; height:1px; left:0; opacity:0; position:absolute; transform:scaleX(.01); transform-origin:left; transition:transform .5s,opacity .3s; width:100%; } .fgma-home-cta-link a:hover .fgma-home-cta-link__label::after, .fgma-home-cta-link a:focus-visible .fgma-home-cta-link__label::after{ opacity:1; transform:scaleX(1); } .fgma-home-cta-link a svg{ color:var(--e-global-color-v4-fgma-brand-red,#F21400); flex-shrink:0; height:21px; transition:transform .5s; width:26px; } .fgma-home-cta-link a:hover svg, .fgma-home-cta-link a:focus-visible svg{ transform:translateX(8px); } /* --- 2. Markets headline ---------------------------------------------------- Production's Markets/Community H2s are rendered through its shared "base-markdown" component, not `.header-N` -- confirmed live to resolve to `--step-7` (AvenirMedium, line-height 1.1), matching --fgma-step-7 exactly. Same Kit-Global-Class-vs-explicit-element cascade defect as the H1 above, same fix. */ .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title{ color:var(--e-global-color-v4-fgma-off-black,#282828); font-family:var(--fgma-font-family); font-size:var(--fgma-step-7); font-weight:var(--fgma-weight-medium); line-height:1.1; margin:0; } /* Resting-state-only reproduction of Production's `.highlight a` treatment: a thin red underline slice is present at rest (transform:scaleY(.06) in Production, never animated open here) -- shared by both Markets and Community. The hover fill-to-full-height animation itself is NOT declared here (deliberately kept out of this shared base rule); it now has a real destination-state-only rule for BOTH headings -- Community since R3.7B.10B (section 6d below), Markets since R3.7D.1 (section 6d-bis below). */ .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a, .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a{ color:inherit; position:relative; text-decoration:none; } .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a::after, .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a::after{ background-color:var(--e-global-color-v4-fgma-brand-red,#F21400); bottom:-.1em; content:""; display:block; height:100%; left:0; position:absolute; transform:scaleY(.06); transform-origin:bottom; width:100%; z-index:-1; } /* --- 3. Practice Areas ------------------------------------------------------- R3.7B.5C: the one approved new Page 2740 structural container has been added -- `.fgma-home-expertise-preview`, an empty sibling BEFORE `.fgma-home-expertise-list` inside `.fgma-home-expertise`, reserving Production's real left preview-pane position (~448x598, 3:4) without any media/interactivity inside it yet (never populated with the nine preview images, never wired to hover-swap). At mobile, the preview pane collapses out of flow entirely (not toward "fake full-width cards") until the later Practice Areas media/component phase. The list itself keeps R3.7B.5's own plain, responsive text treatment -- Production's real nine-link mobile image-card conversion still needs its own nine media items, still not this block's to build. */ /* R3.7B.5G Finding 2: root-caused, not assumed -- the base rule below never asserted `flex-direction` for the desktop/tablet case (only the mobile override did), the exact same class of omission diagnosed and fixed for the Hero row in R3.7B.5E -- Elementor's own `.e-flex{flex-direction: column}` was the only declaration ever setting it. Explicit `row` closes the gap. R3.7B.5G Finding 6: the R3.7B.5E `max-width:min(1040px,80.87%)` is REMOVED -- that percentage resolved against the section's own parent (effectively the viewport), not the already-gutter-reduced content band, diverging at 1024 (80.87% of 1024 = 828px vs the verified 765px). Fixed by ADDING `--fgma-home-expertise-inset` (see its own derivation above) as extra padding-inline on top of the section's existing --fgma-gutter -- the content-box width this produces is band-minus-double-inset automatically, verified to reproduce 1040px @1440 and 765px @1024 exactly, still centred (the section itself already has margin-inline:auto via the shared six-selector rule at the top of this file, and its own max-width there is unchanged). The desktop preview/list gap reuses the same `--fgma-home-space-10p` token as the Community grid row-gap (Finding 3/4) -- the two numbers coincide (~143px) but this reuse is a deliberate assumption, not an independently-confirmed shared Production source for THIS specific gap (Production's own desktop split-pane markup for Practice Areas was never located in prior research); flagged for confirmation in the next real-browser pass. */ /* R3.7B.5I: switched from the R3.7B.5G flex(`flex:1 1 0` on both children) approach to explicit CSS Grid, per this round's own instruction to match the real model directly -- `minmax(0,1fr) minmax(0,1fr)` is an unambiguous, browser-independent expression of "two equal columns", removing any reliance on flex-basis/grow resolution around the preview's own aspect-ratio box. Verified: at 1024, module width 765px (this round's own verified figure, already reproduced by --fgma-home-expertise-inset below) minus the 99.91px gap, split across 2 equal columns = 332.5px =~ 332 -- matching this round's own preview/list target exactly. */ .elementor .fgma-home-expertise.e-con{ display:grid; grid-template-columns:minmax(0,1fr) minmax(0,1fr); align-items:flex-start; gap:var(--fgma-home-space-10p); } /* R3.7B.8F: root-caused, not assumed -- confirmed live against the actual deployed cascade (not assumed from the prior report) that the `--fgma-home-expertise-inset` addition above was applied completely UNCONDITIONALLY, with no media-query gate at all -- it was only ever fitted/verified against DESKTOP split-pane measurements (1040px @1440, 765px @1024, see this rule's own R3.7B.5G derivation above), never validated against or intended for <600px. Below 600px this left the section's own real available content width far narrower than Production's (Production's own real contract there is just its small base-container gutter -- confirmed live to be BYTE-FOR-BYTE `--fgma-gutter`'s own existing formula, `clamp(1.8125rem,.5381rem + 4.7418vw,8.125rem)` -- no new token was needed or created), which is exactly why the equal `minmax(0,1fr)` grid tracks (R3.7B.8D) were still too narrow for "Multifamily/Mixed-Use" to wrap without colliding across the column gap. The extra inset now applies ONLY at >=600px -- below that, the section falls through to the shared six-selector rule's own `padding-inline:var(--fgma-gutter)` (top of this file), which IS Production's real small-container contract, unchanged, never a guessed new value. 600-899/>=900 geometry (the "currently verified existing layout/inset behavior") is completely unchanged -- this rule's own value/formula is identical to before, merely gated. The wide-desktop (>1440) inset discrepancy remains its own separate, explicitly deferred finding (R3.7B FINAL RESPONSIVE QA), untouched here. R3.7Q-038B: root-caused, not assumed -- confirmed live the 600px gate above was itself still too early: at real tablet card-grid widths (768/834px) the inset activates well before Production's own contract does, over-narrowing the grid (+31.24px/+23.19px gutter per side, -31.25px/-23.18px card width vs Production at those two widths respectively). 1024px geometry (this rule's own original derivation) is already correct and untouched. Moved to 900px -- the same boundary the mobile card-grid override below already uses -- so the inset now only ever applies once the desktop two-column split-pane layout itself is active; the declaration/formula is completely unchanged, only its gate moved. */ @media (min-width:900px){ .elementor .fgma-home-expertise.e-con{ padding-inline:calc(var(--fgma-gutter) + var(--fgma-home-expertise-inset)); } } /* R3.7Q-038C was applied then reverted at the user's explicit request -- it made the 768/834px tablet gutter/card geometry an exact pixel match to Production (via `--fgma-gutter-inset`), but the user preferred R3.7Q-038B's own bare-`--fgma-gutter` tablet result: less exact to Production, but using margins the user felt read better and stayed more consistent with the rest of the site. 600-899px therefore falls through to the base six-selector `padding-inline:var(--fgma-gutter)` rule again, unchanged from R3.7Q-038B. */ /* R3.7B.8B: `position:relative` + `overflow:hidden` added -- the crossfade current/incoming pair fgma-home.js appends here are `position:absolute;inset:0`, so this needs to be a real containing block; overflow:hidden guarantees neither image can ever visually escape the locked 3:4 box during a crossfade. Everything else (aspect-ratio, background-color fallback -- still the visible placeholder until the default Civic image loads) is unchanged. */ .elementor .fgma-home-expertise-preview.e-con{ aspect-ratio:3/4; background-color:var(--e-global-color-v4-fgma-light-gray,#f0f0f0); overflow:hidden; position:relative; } /* R3.7B.8B: the crossfade image pair. The FIRST (default/current) image fgma-home.js appends carries only this base class -- no explicit opacity rule needed, since the browser's own default (1) is already correct and requires no transition. A newly-appended INCOMING image additionally carries `--incoming` (opacity 0, with the transition declared here on the class doing the animating, exactly like every other "transition lives on the destination-state class" pattern already established in this file) and then `--visible` once the browser has registered that initial state (forced via one reflow read in JS) -- Production's own confirmed values: 500ms, cubic-bezier(.4, 0,.2,1). fgma-home.js removes the outgoing image and both modifier classes once the transition completes, so the DOM never accumulates more than the current + at most one in-flight image. */ .fgma-home-expertise-preview__image{ display:block; height:100%; inset:0; object-fit:cover; object-position:50% 50%; position:absolute; width:100%; } .fgma-home-expertise-preview__image--incoming{ opacity:0; transition:opacity .5s cubic-bezier(.4,0,.2,1); } .fgma-home-expertise-preview__image--incoming.fgma-home-expertise-preview__image--visible{ opacity:1; } @media (prefers-reduced-motion:reduce){ .fgma-home-expertise-preview__image--incoming{ transition:none; } } .fgma-home-expertise-list{ min-width:0; } /* R3.7B.5E Finding 12: current rhythm measured ~67px, Production ~49-50px -- both the reduced `gap` (`--fgma-space-xs` instead of `--fgma-space-sm`) and the tighter `line-height:1.1` (the SAME value already used for the Markets/Community H2s above, not a new token) combine to ~49px at 1440; font-size (30.5002px, already correct) is unchanged. R3.7B.8B: root-caused, not assumed -- real-browser QA (R3.7B.8A) proved the row rhythm should actually use Production's own `--space-2xs` (8.931px @1324), not `--fgma-space-xs` (~14.8px @1324) -- see `--fgma-home-expertise-list-gap`'s own derivation above for why no existing token matched. */ .fgma-home-expertise-list ul{ display:flex; flex-direction:column; gap:var(--fgma-home-expertise-list-gap); list-style:none; margin:0; padding:0; } /* R3.7B.8B: `display:flex` (was `block`) so the label and the new decorative arrow span sit on one baseline-aligned row with a real gap between them, matching Production's own row layout -- a plain text link visually renders identically to before since it's still one line of text on the left. `line-height:1.3` corrects the prior `1.1` (R3.7B.8A real-browser finding); font-family/weight are already correct and untouched (fgmadev's existing `--fgma-font-family`/`--fgma-weight-medium` remain the canonical medium Avenir mapping used identically everywhere else on this Homepage -- no more-correct alternative token exists in fgmadev's own architecture, so neither is changed here, per this round's own instruction not to alter family/weight without a superior existing DEV token to move to). Underline fully removed (rest AND hover) -- Production has none at either state. R3.7B.8D: two corrections. (1) `font-size` now reads the new `--fgma-home-expertise-list-font-size` token (its own ceiling-fidelity derivation is above) instead of an inline, unlabelled clamp copied from an unrelated component. (2) `color` now uses the canonical `--e-global-color-v4-fgma-black` token (confirmed already established and reused identically in `fgma-archive.css`/`fgma-expertise- archive.css`/`fgma-insights-archive.css`, real value `#000000`) instead of `--e-global-color-v4- fgma-off-black` (`#282828`) -- R3.7B.8C's real-browser QA proved Production's own rest colour for THIS module is genuine `rgb(0,0,0)`, not the off-black used everywhere else on the Homepage; scoped to this one selector only, never a change to the shared off-black token or any other heading's colour. `transition` added for the colour change itself -- Production's own confirmed 500ms `cubic-bezier(.4,0,.2,1)`, no delay, declared on this base/rest rule (a plain `:hover`/`:focus- visible` pseudo-class toggle animates correctly in both directions from one shared declaration, the same reasoning already established for the Project card overlay/title transitions). */ .fgma-home-expertise-list a{ align-items:center; color:var(--e-global-color-v4-fgma-black,#000); display:flex; font-family:var(--fgma-font-family); font-size:var(--fgma-home-expertise-list-font-size); font-weight:var(--fgma-weight-medium); gap:var(--fgma-space-xs); line-height:1.3; text-decoration:none; transition:color .5s cubic-bezier(.4,0,.2,1); } .fgma-home-expertise-list__label{ color:inherit; } /* R3.7B.8D BLOCKER 1: root-caused, not assumed -- real-browser QA proved the per-item mobile card `` `fgma-home.js` hydrates (only once <900px is actually reached, see that file's own header comment) had NO base/desktop rule of its own at all -- it fell through to the browser's native default image display, remaining fully visible after a mobile-to-desktop resize even though the desktop preview was also showing, inflating list-item height and total section height. Explicit `display:none` here (unconditional, every viewport) is the safe default; the existing mobile override below is the ONLY place that restores `display:block` -- CSS visibility switching alone, never JS de-hydration/node removal, so a desktop -> mobile -> desktop -> mobile cycle always shows exactly the right image set with zero duplicate nodes and zero geometry impact at desktop. */ .fgma-home-expertise-list__image{ display:none; } /* R3.7B.8B: the decorative arrow `fgma-home.js` appends to every list anchor -- the exact same canonical FGMA arrow already established/validated elsewhere in this codebase (`Project_Component_ Renderer::CTA_ARROW_SVG`, also already reused verbatim by this same file's own Project card CTA, R3.7B.7B), never a second, slightly-different SVG. Hidden at rest (`opacity:0`); Production's own confirmed hover/focus treatment: opacity 1, `translateX(8px)`, red, over `all 500ms cubic-bezier( .4,0,.2,1)`. `margin-top:-4px` reproduces Production's own confirmed baseline alignment nudge. Desktop only -- hidden entirely on mobile below (Practice Areas mobile cards have no arrow at all, per Production's own confirmed mobile contract). */ .fgma-home-expertise-list__arrow{ color:var(--e-global-color-v4-fgma-brand-red,#F21400); display:inline-flex; flex-shrink:0; margin-top:-4px; opacity:0; transition:all .5s cubic-bezier(.4,0,.2,1); } @media (min-width:900px){ /* R3.7B.8B: red colour + visible arrow -- desktop only (Production's own confirmed mobile contract has no red hover state and no arrow at all, reproduced in the mobile override below). `:focus-visible` alongside `:hover` is an APPROVED DEV accessibility improvement -- keyboard focus gets the identical affordance a mouse hover already gets, never removing the native focus ring (not suppressed anywhere in this file). */ .fgma-home-expertise-list a:hover, .fgma-home-expertise-list a:focus-visible{ color:var(--e-global-color-v4-fgma-brand-red,#F21400); } .fgma-home-expertise-list a:hover .fgma-home-expertise-list__arrow, .fgma-home-expertise-list a:focus-visible .fgma-home-expertise-list__arrow{ opacity:1; transform:translateX(8px); } } @media (prefers-reduced-motion:reduce){ .fgma-home-expertise-list a{ transition:none; } .fgma-home-expertise-list__arrow{ transition:none; } } @media (max-width:899px){ .elementor .fgma-home-expertise.e-con{ grid-template-columns:1fr; max-width:none; } .elementor .fgma-home-expertise-preview.e-con{ display:none; } } /* R3.7B.8B: Production's confirmed mobile contract -- no shared preview (already hidden above), the same 9 real anchors become a 2-column image-card grid instead, each with its own real 3:4 image (fgma-home.js hydrates these lazily, only once <900px is actually reached -- never eagerly on a desktop load) and a caption below. No overlay, no arrow, no red hover state, no crossfade, direct tap navigation -- the anchor itself remains the one single tab/click target throughout, never duplicated. Column/row gaps and caption spacing all reuse existing fgmadev tokens (never Production's own raw pixel values) -- `--space-lg`/`--space-xl`/`--space-sm` respectively, per this round's own explicit instruction. */ @media (max-width:899px){ /* R3.7B.8D BLOCKER 2: root-caused, not assumed -- real-browser QA proved `repeat(2,1fr)` resolves its implicit track minimum as `auto` (per the CSS Grid spec, a bare `1fr` track's minimum is `auto`, never `0`), so a long intrinsic content width (an unbroken Practice Area name) can force that column wider than its fair 50% share, producing the observed ~87px/~154px split rather than two genuinely equal columns -- confirmed Production's own real formula is `repeat(2,minmax(0, 1fr))`, which floors each track's minimum at 0 so the `1fr` distribution alone governs width. Never solved with overflow/word-break hacks or a fixed pixel width, per this round's own explicit instruction -- the column-sizing model itself was the defect. */ .fgma-home-expertise-list ul{ column-gap:var(--fgma-space-lg); display:grid; grid-template-columns:repeat(2,minmax(0,1fr)); row-gap:var(--fgma-space-xl); } .fgma-home-expertise-list a{ align-items:flex-start; display:flex; flex-direction:column; } .fgma-home-expertise-list__image{ aspect-ratio:3/4; display:block; object-fit:cover; object-position:50% 50%; width:100%; } .fgma-home-expertise-list__label{ margin-top:var(--fgma-space-sm); } .fgma-home-expertise-list__arrow{ display:none; } } /* R3.7B.8B: Homepage-local reveal (see fgma-home.js's own header comment on why `fgma-reveal.js` itself is never touched: it has no extension/config mechanism and no generic `[data-reveal]` opt-in, only a hardcoded internal REGISTRY array -- confirmed by direct inspection before choosing this fallback). Mirrors R3.7B.7B's own established failure-safe convention exactly: gated under a root-ready class ONLY this file's own Practice Areas controller ever adds, with no unconditional opacity/transform rule on the targets themselves (their safe default IS the browser's own visible default). Production's own confirmed values: 20px offset, 1.5s duration, plain `ease` (matching `fgma-reveal.css`'s own reveal contract exactly, not a different easing curve invented here). */ html.fgma-home-pa-ready [data-fgma-home-pa-reveal="pending"]{ opacity:0; transform:translateY(20px); transition:none; } html.fgma-home-pa-ready [data-fgma-home-pa-reveal="visible"]{ opacity:1; transform:translateY(0); transition:opacity 1.5s ease, transform 1.5s ease; } @media (prefers-reduced-motion:reduce){ html.fgma-home-pa-ready [data-fgma-home-pa-reveal]{ opacity:1; transform:none; transition:none; } } /* --- 4. Culture image band --------------------------------------------------- Production 16:9 full-band geometry via aspect-ratio + object-fit. The responsive `sizes` attribute is now corrected via a narrowly-scoped `wp_calculate_image_sizes` filter (Home_Culture_Image_Sizes, gated to `is_front_page()` AND attachment 3409 only) rather than a hardcoded URL -- see that class's own docblock for the exact mechanism. `.fgma-home-culture` itself already carries the shared max-width/gutter rule above (now actually winning the cascade); the image band spans its full corrected content width. */ .fgma-home-culture-image img{ aspect-ratio:16/9; display:block; height:auto; object-fit:cover; width:100%; } /* --- 5. Community headline --------------------------------------------------- Same base-markdown H2 contract and same cascade fix as Markets above (--step-7 / --fgma-step-7); the `.highlight a` resting-underline rule above already covers both headings via its shared selector. */ .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title{ color:var(--e-global-color-v4-fgma-off-black,#282828); font-family:var(--fgma-font-family); font-size:var(--fgma-step-7); font-weight:var(--fgma-weight-medium); line-height:1.1; margin:0; } /* --- 6. Community grid --------------------------------------------------- Production's real grid is `grid md:grid-cols-2 xl:grid-cols-3` with plain DOM-order auto-flow -- Insight/video tiles interleave with the tout tiles as later DOM siblings, never via manual grid-column/row placement. Reproducing that same auto-flow contract here (rather than hand-placing the 4 existing touts into fixed cells) means the later Insight/video components can be added as new grid children and will simply flow into the remaining cells with zero CSS restructuring. `display:grid` itself and the column-count contract are confirmed already correct and untouched this round. R3.7B.5G Finding 4: column-gap and row-gap are DISTINCT contracts, not one shared value -- verified live: column-gap ~83.50px @1440 / ~71.43px @1024 (exactly `--fgma-space-2xl`, an existing token, reused directly) while row-gap needs ~143.27px @1440 / ~99.91px @1024 (the NEW `--fgma-home-space-10p` Homepage-local token, see its own derivation above -- R3.7B.5E's prior single-value `gap:var(--fgma-space- 10p)` was wrong on two counts: that token was never defined at all, and even once defined it should never have applied to both axes). */ .elementor .fgma-home-grid.e-con{ display:grid; gap:var(--fgma-home-space-10p) var(--fgma-space-2xl); grid-template-columns:1fr; } @media (min-width:600px){ .elementor .fgma-home-grid.e-con{ grid-template-columns:repeat(2,1fr); } } @media (min-width:1440px){ .elementor .fgma-home-grid.e-con{ grid-template-columns:repeat(3,1fr); } } /* R3.7B.10B: the SAME `fgma-home-tout`/`--variant` classes now also appear directly on the real `` anchor inside each widget's own raw HTML (see Page 2740's own before/after audit for this round) -- not just on the outer Elementor widget wrapper as before. This bare rule below therefore now matches BOTH elements; it is deliberately kept to only the properties that are harmless (idempotent) to apply twice: the card's own visual box (aspect-ratio) and its positioning context for the `::before` background layer below. Layout properties that would double up destructively (flex/padding) are scoped to `a.fgma-home-tout` specifically (a MORE specific, element+class selector) further down. R3.7D.1: `overflow:hidden` (originally added here to clip the hover background-scale effect to the card's own bounds) is REMOVED -- it was the actual root cause of the reported bug, not a real requirement: it clipped the `::before` layer's `scale(1.1)` hover growth to the card's ORIGINAL, unscaled bounds, making the growth Production shows (the colour visibly expanding ~10% past the card edge, into the grid gap, never reflowing neighbouring layout since it is a `transform`, not a size/layout change) invisible. No child of this card relies on clipping at rest: there is no image here to crop (unlike `.fgma-home-news`'s own cards), the `

`/CTA text stays in normal flow, and the CTA-label underline's `bottom:-.35em` offset stays well inside the anchor's own `--fgma-space-md` padding. */ .fgma-home-tout{ aspect-ratio:3/4; position:relative; } /* R3.7B.10B CRITICAL correction: Production's real per-variant aspect ratios are NOT uniformly 3:4 -- confirmed live this round. Approach/Work Here stay 3:4 (the block rule above already covers them); Culture/Team are 5:4. */ .fgma-home-tout--culture, .fgma-home-tout--team{ aspect-ratio:5/4; } /* R3.7B.10B CRITICAL architecture fix: `display:flex;flex-direction:column; justify-content:space-between` moves from the OUTER wrapper (confirmed live this round to be the anchor's own DIRECT parent -- this Elementor version's real HTML-widget markup has no intermediate `.elementor-widget-container` div at all, so the anchor's own `height:100%` below already resolves correctly against the outer wrapper's aspect-ratio-derived height with no bridging rule needed) onto the anchor itself, which is the element that actually has two real children needing space distributed between them (the `

` and the CTA row) -- the outer wrapper has exactly one child (the anchor), so "space between" one item there was always a no-op. This is what lets the CTA pin naturally to the card's own bottom edge instead of trailing directly under the heading. */ a.fgma-home-tout{ color:var(--e-global-color-v4-fgma-white,#fff); display:flex; flex-direction:column; height:100%; justify-content:space-between; text-decoration:none; width:100%; padding:var(--fgma-space-md); } /* R3.7B.10F fix 2: root cause confirmed live -- Hello Elementor's own `reset.css` (loaded AFTER fgma-home.css in the page) ships `a:active, a:hover{color:#336}` at specificity (0,1,1), exactly TIED with the base rule above (`a.fgma-home-tout{color:#fff}`, also element+class = (0,1,1)). At tied specificity the LATER stylesheet in the document wins regardless of which rule "looks" more state-specific, so the theme's hover/active colour silently overrode white on every interactive state (H2/CTA-label/ underline all cascade from this same anchor via `color:inherit`/ `currentColor`, so fixing the anchor alone fixes every child -- no need to independently patch each one). `.elementor .fgma-home-grid a.fgma-home- tout` reaches (0,4,1), safely beating the theme's (0,1,1) regardless of load order, no `!important` needed. `:visited` is included defensively even though the theme's own `a:visited` rule only touches text-decoration, never colour today. */ .elementor .fgma-home-grid a.fgma-home-tout, .elementor .fgma-home-grid a.fgma-home-tout:hover, .elementor .fgma-home-grid a.fgma-home-tout:focus-visible, .elementor .fgma-home-grid a.fgma-home-tout:active, .elementor .fgma-home-grid a.fgma-home-tout:visited{ color:var(--e-global-color-v4-fgma-white,#fff); } .fgma-home-tout h2{ color:inherit; font-family:var(--fgma-font-family); font-size:var(--fgma-step-3); font-weight:var(--fgma-weight-medium); line-height:1.35; margin:0; } /* --- Static tout CTA row: label left, arrow right, arrow reused verbatim from the same canonical 26x21 SVG constant every other CTA in this codebase already reuses (`Project_Component_Renderer::CTA_ARROW_SVG`, now also `Home_Community_Renderer`'s own copy of it). R3.7B.10B correction: Production's real CTA label is ~20.29px/30.44px at 1053px viewport -- confirmed live this round to match `--fgma-step-1` exactly (`--fgma-step-0` only reaches ~17.3px there, materially undersized), and its real weight is the Book/regular face (`--fgma-weight-book`, 400), not Medium (500). */ .fgma-home-tout__cta{ align-items:center; display:flex; justify-content:space-between; width:100%; } .fgma-home-tout__cta-label{ color:inherit; font-family:var(--fgma-font-family); font-size:var(--fgma-step-1); font-weight:var(--fgma-weight-book,400); line-height:1.5; position:relative; } /* R3.7B.10D fix 4: this underline was entirely missing (B.10C QA finding). Mirrors the News CTA underline contract exactly -- same 1px/-.35em/left transform-origin/scaleX(.01->1)/500ms transform + 300ms opacity -- scoped to the label only, never the arrow or the full-width CTA row. Static cards have white text (`color:inherit` from the white anchor), so `background-color:currentColor` already renders it white with no separate token needed. */ .fgma-home-tout__cta-label::after{ background-color:currentColor; bottom:-.35em; content:""; height:1px; left:0; opacity:0; position:absolute; transform:scaleX(.01); transform-origin:left; transition:transform .5s,opacity .3s; width:100%; } a.fgma-home-tout:hover .fgma-home-tout__cta-label::after, a.fgma-home-tout:focus-visible .fgma-home-tout__cta-label::after{ opacity:1; transform:scaleX(1); } .fgma-home-tout__cta svg{ color:var(--e-global-color-v4-fgma-white,#fff); flex-shrink:0; height:21px; transition:transform .5s cubic-bezier(.4,0,.2,1); width:26px; } a.fgma-home-tout:hover .fgma-home-tout__cta svg, a.fgma-home-tout:focus-visible .fgma-home-tout__cta svg{ transform:translateX(8px); } /* Background hover-scale layer: a dedicated `::before` (never the anchor's own padding box, which must stay visually static per this round's own "text/card dimensions do not move" requirement) scales 1 -> 1.1 on hover/focus -- R3.7D.1: no longer clipped by the outer wrapper (its `overflow:hidden` is removed above), so the growth is now actually visible, matching Production. Background colour moves here (off the flat `.fgma-home-tout--variant` rules) since it is this scaling layer, not the static outer box, that needs to visually represent Production's real background-scale motion. */ a.fgma-home-tout::before{ content:""; inset:0; position:absolute; transition:transform .5s cubic-bezier(.4,0,.2,1); z-index:-1; } a.fgma-home-tout:hover::before, a.fgma-home-tout:focus-visible::before{ transform:scale(1.1); } /* Verified live Production colour per tout (not a repeat of the hero slot sequence -- confirmed independently for each of the four /approach/, /culture/, /team/, /careers/ links). off-black/brand-red/gray already have canonical tokens; blue reuses the same Homepage-local token as hero slot 1. Applied to the anchor's own `::before` scaling layer (see above), not the flat outer box. */ .fgma-home-tout--approach::before{background-color:var(--e-global-color-v4-fgma-off-black,#282828);} .fgma-home-tout--culture::before{background-color:var(--e-global-color-v4-fgma-brand-red,#F21400);} .fgma-home-tout--team::before{background-color:var(--e-global-color-v4-fgma-gray,#949494);} .fgma-home-tout--careers::before{background-color:var(--fgma-home-blue);} /* --- 6b. Curated News cards --------------------------------------------- R3.7B.10B: the 4 server-rendered `Home_Community_Renderer::render_news()` cards -- ANCHOR > image-wrapper(3:2) > IMG, eyebrow, H2, CTA. Spacing uses existing fluid tokens (image->eyebrow: md, eyebrow->title: 3xs -- the closest real existing token to "2xs", since no literal `--fgma-space-2xs` is defined anywhere on fgmadev; title->CTA: md), never new global tokens. */ .fgma-home-news{ color:var(--e-global-color-v4-fgma-off-black,#282828); display:flex; flex-direction:column; text-decoration:none; } .fgma-home-news__image-wrap{ aspect-ratio:3/2; display:block; overflow:hidden; width:100%; } .fgma-home-news__image{ aspect-ratio:3/2; display:block; height:auto; object-fit:cover; transition:transform .7s ease-in-out; width:100%; } .fgma-home-news:hover .fgma-home-news__image, .fgma-home-news:focus-visible .fgma-home-news__image{ transform:scale(1.04); } .fgma-home-news__eyebrow{ color:rgb(148,148,148); display:block; font-family:var(--fgma-font-family); font-size:var(--fgma-step-0); font-weight:var(--fgma-weight-book,400); margin-top:var(--fgma-space-md); } .fgma-home-news__title{ color:var(--e-global-color-v4-fgma-off-black,#282828); font-family:var(--fgma-font-family); font-size:var(--fgma-step-2); font-weight:var(--fgma-weight-medium); line-height:1.35; margin:var(--fgma-space-3xs) 0 0; } /* R3.7B.10D fix 6: was `display:inline-flex;width:fit-content` (label/arrow hugging each other on the left, arrow nowhere near the card's own right edge) -- Production's real CTA row spans the full card content width with the label pinned left and the arrow flush to the right edge. */ .fgma-home-news__cta{ align-items:center; display:flex; justify-content:space-between; margin-top:var(--fgma-space-md); position:relative; width:100%; } /* R3.7B.10D fix 6: label colour corrected from red (inherited from the old `.fgma-home-news__cta{color:red}`) to Production's real black -- the arrow and underline stay red (set explicitly below, no longer via inheritance from this row). */ .fgma-home-news__cta-label{ color:var(--e-global-color-v4-fgma-black,#000); font-family:var(--fgma-font-family); font-size:var(--fgma-step-0); font-weight:var(--fgma-weight-medium); position:relative; } /* Animated underline: transform-origin left, scaleX(.01) -> 1, 500ms; opacity fades in over 300ms alongside it -- reproduced on the label only, matching Production's own real underline scope. Explicit red (not `currentColor`, since the label's own colour is now black per the fix above -- the underline must stay red regardless). */ .fgma-home-news__cta-label::after{ background-color:var(--e-global-color-v4-fgma-brand-red,#F21400); bottom:-.35em; content:""; height:1px; left:0; opacity:0; position:absolute; transform:scaleX(.01); transform-origin:left; transition:transform .5s,opacity .3s; width:100%; } .fgma-home-news:hover .fgma-home-news__cta-label::after, .fgma-home-news:focus-visible .fgma-home-news__cta-label::after{ opacity:1; transform:scaleX(1); } /* R3.7B.10D fix 5: arrow never moved on hover/focus (no transform/transition existed at all) -- reuses the exact same 8px/500ms/canonical-easing contract already established for the static tout's own arrow. Explicit red `color` (not inherited from the row, which no longer carries red) keeps the arrow red independent of the now-black label. */ .fgma-home-news__cta svg{ color:var(--e-global-color-v4-fgma-brand-red,#F21400); flex-shrink:0; height:21px; transition:transform .5s cubic-bezier(.4,0,.2,1); width:26px; } .fgma-home-news:hover .fgma-home-news__cta svg, .fgma-home-news:focus-visible .fgma-home-news__cta svg{ transform:translateX(8px); } /* R3.7B.10B DEV accessibility improvement (approved, deliberate departure from Production): Production hides this CTA at rest on desktop and only reveals it on real mouse hover, with no focus-visible/touch equivalent -- a genuine accessibility deficiency this round explicitly authorizes NOT reproducing. The CTA stays visible at all times below 1024px and on any device without real hover capability; only >=1024px AND hover-capable devices get the Production hide-until-hover behaviour, with focus-visible/ focus-within added as this round's own required keyboard equivalent. */ @media (min-width:1024px) and (hover:hover){ .fgma-home-news__cta{ opacity:0; transition:opacity .3s .05s; } .fgma-home-news:hover .fgma-home-news__cta, .fgma-home-news:focus-visible .fgma-home-news__cta, .fgma-home-news:focus-within .fgma-home-news__cta{ opacity:1; } } /* --- 6c. Vimeo item ------------------------------------------------------- R3.7B.10B: server-rendered fallback `` only -- `fgma-home.js`'s own Community controller creates the live iframe, gated to >=1440 AND reduced-motion-false (see that controller's own comments for the full eligibility/lifecycle contract). No anchor, no text, no overlay, no tab stop -- a plain non-interactive container, exactly as required. R3.7B.10D fix 2: this element's own `display:none/block` toggle is no longer what hides it below 1440 -- that job now belongs to the REAL grid item (`.fgma-home-community-slot--video`, section 6e below), since B.10C proved this inner div was never the actual CSS Grid item at all (its Elementor wrapper was, and stayed a visible/participating grid item regardless of this rule). This div is now simply always `display:block`; whenever its wrapper is hidden, it is removed from rendering along with it automatically, so no redundant/competing hide mechanism is needed here. */ .fgma-home-video{ aspect-ratio:3/4; overflow:hidden; position:relative; } .fgma-home-video__fallback{ height:100%; left:0; object-fit:cover; position:absolute; top:0; width:100%; } /* R3.7B.10D fix 3: `object-fit:cover` has no effect on an iframe's browsing context (confirmed live -- B.10C measured the iframe rendering at the card's own raw 373.08x497.44 box, not a covering 373.08x~662). Vimeo's real source ratio (240/426) is narrower than every card size this item ever renders at (only >=1440, where the card's own 3:4 ratio is always wider than 240:426) -- so a width-driven `aspect-ratio` cover is a fixed, viewport-size-independent relationship, not something that could break at a different >=1440 width: setting width:100% of the card and deriving height from the real source ratio always overflows the card's own height (never its width), which centred+clipped-by-the-wrapper's-own- `overflow:hidden` is exactly Production's own real cover technique. Pure CSS is sufficient; no JS sizing math is needed. */ .fgma-home-video__iframe{ aspect-ratio:240/426; border:0; height:auto; left:50%; min-height:100%; min-width:100%; opacity:0; pointer-events:none; position:absolute; top:50%; transform:translate(-50%,-50%); transition:opacity .5s; width:100%; } .fgma-home-video__iframe.fgma-home-video__iframe--ready{ opacity:1; } .fgma-home-video.fgma-home-video--iframe-ready .fgma-home-video__fallback{ opacity:0; transition:opacity .5s; } /* --- 6d. Community heading hover/focus ------------------------------------- R3.7B.10B: adds the previously-deferred hover/focus-visible animation for the Community heading's own "Community" link ONLY -- deliberately new, Community-scoped selectors that never touch the existing frozen combined Markets/Community resting-state rule above (R3.7B.5x), so Markets' own heading is left completely untouched (out of this round's scope). Timing/ easing per this round's own confirmed spec, applied per the destination- state-only transition pattern established throughout this codebase (R3.7Q-006J): declared on the resting rule so leaving hover animates back, and (implicitly, since the same declaration is on the shared base selector, not a `:hover`-only one) also active entering hover. */ .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a{ transition:color 1s cubic-bezier(.5,-.3,.2,1.2); } .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a::after{ transition:transform 1s cubic-bezier(.5,-.3,.2,1.2); } .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a:hover, .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a:focus-visible{ color:var(--e-global-color-v4-fgma-white,#fff); } .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a:hover::after, .elementor .fgma-home-community-heading.elementor-widget-heading .elementor-heading-title a:focus-visible::after{ transform:scaleY(1); } /* --- 6d-bis. Practice Areas ("Markets") heading hover/focus ----------------- R3.7D.1: completes the OTHER deferred half of the R3.7B.10B note above -- "Markets' own heading is left completely untouched (out of this round's scope)". "Experts in Our Practice Areas" (`.fgma-home-markets-heading`, its own link wrapping just the words "Practice Areas", `href="/expertise/"` -- confirmed live) shares the identical base resting-state rule with Community (section 2 above, both listed together in that one shared selector), so it needs the exact SAME hover/focus-visible fill animation, never a new one: the four rules below are byte-identical in every value/timing/easing to the Community block immediately above, only re-targeted to `.fgma-home-markets-heading`. Deliberately separate, Markets-scoped selectors -- the existing Community rules above are not touched, edited, or reused via a combined selector. */ .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a{ transition:color 1s cubic-bezier(.5,-.3,.2,1.2); } .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a::after{ transition:transform 1s cubic-bezier(.5,-.3,.2,1.2); } .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a:hover, .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a:focus-visible{ color:var(--e-global-color-v4-fgma-white,#fff); } .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a:hover::after, .elementor .fgma-home-markets-heading.elementor-widget-heading .elementor-heading-title a:focus-visible::after{ transform:scaleY(1); } /* --- 6e. Responsive grid placement (REAL grid-item wrapper ownership) ------ R3.7B.10D root-cause correction: B.10C proved the actual CSS Grid items are Elementor's own DIRECT widget/container wrappers -- confirmed live via Elementor's own frontend.min.css: `.elementor-element{order:var(--order)}` with `--order:initial` by default -- never the inner Community anchors/ divs this file previously targeted (`.fgma-home-tout--*`/`.fgma-home- news--*`), which are nested one level DEEPER than the true grid item and so never participated in grid placement at all; every wrapper computed `order:0` regardless of what was set on its own inner content. Page 2740's own 9 direct `.fgma-home-grid` children now each carry a stable `fgma-home-community-slot`/`--variant` class (a small, additive Page 2740 mutation from R3.7B.10D -- existing widget IDs/content/ shortcodes/static-tout HTML are all untouched). This cooperates with Elementor's own `--order` custom-property architecture (setting `--order` directly) rather than fighting it with an `order:` specificity war. R3.7B.10F Finding: bare `.fgma-home-community-slot--*{--order:N}` (0,1,0) TIES with Elementor's own `.elementor-element{--order:initial; ...}` (also 0,1,0) -- Elementor's own stylesheet loads after `fgma-home.css` in the page, so its tied-specificity `--order:initial` won the cascade, silently discarding every value this file set. Fixed the exact same way the video-wrapper hide rule below already does: `.elementor .fgma-home- grid>` reaches (0,3,0), safely beating Elementor's (0,1,0) regardless of load order, no `!important` needed. DOM order (News1, Approach, News2, Culture, Video, Team, News3, Careers, News4) already reproduces the exact required >=1440 3-column row layout via plain auto-flow with ZERO placement needed at that tier -- the final rule below simply resets every lower tier's own `--order` back to 0. Below 1440 the video slot leaves grid flow entirely (fix below), and each of the three remaining tiers needs its own distinct, fully explicit sequence (confirmed live via real-browser QA, NOT identical to each other and NOT a simple "swap two items" diff between tiers) -- `--order`/`order` changes visual position only; keyboard/tab order always follows DOM source order regardless, satisfying the standing "no JS reordering, keyboard order = DOM order" requirement without any JS involvement. */ .elementor .fgma-home-grid>.fgma-home-community-slot--news-1{--order:1;} .elementor .fgma-home-grid>.fgma-home-community-slot--approach{--order:2;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-2{--order:3;} .elementor .fgma-home-grid>.fgma-home-community-slot--culture{--order:4;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-3{--order:5;} .elementor .fgma-home-grid>.fgma-home-community-slot--team{--order:6;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-4{--order:7;} .elementor .fgma-home-grid>.fgma-home-community-slot--careers{--order:8;} @media (min-width:600px) and (max-width:1023px){ .elementor .fgma-home-grid>.fgma-home-community-slot--news-1{--order:1;} .elementor .fgma-home-grid>.fgma-home-community-slot--approach{--order:2;} .elementor .fgma-home-grid>.fgma-home-community-slot--culture{--order:3;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-2{--order:4;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-3{--order:5;} .elementor .fgma-home-grid>.fgma-home-community-slot--team{--order:6;} .elementor .fgma-home-grid>.fgma-home-community-slot--careers{--order:7;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-4{--order:8;} } @media (min-width:1024px) and (max-width:1439px){ .elementor .fgma-home-grid>.fgma-home-community-slot--news-1{--order:1;} .elementor .fgma-home-grid>.fgma-home-community-slot--approach{--order:2;} .elementor .fgma-home-grid>.fgma-home-community-slot--culture{--order:3;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-2{--order:4;} .elementor .fgma-home-grid>.fgma-home-community-slot--team{--order:5;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-3{--order:6;} .elementor .fgma-home-grid>.fgma-home-community-slot--careers{--order:7;} .elementor .fgma-home-grid>.fgma-home-community-slot--news-4{--order:8;} } @media (min-width:1440px){ .elementor .fgma-home-grid>.fgma-home-community-slot{--order:0;} } /* R3.7B.10D fix 2: the REAL grid-item wrapper is what must compute `display:none` below 1440 -- the inner `.fgma-home-video`'s own former `display:none/block` toggle (removed in section 6c above) never actually removed a row/cell/row-gap contribution, since its Elementor wrapper (this selector) stayed a visible, participating grid item regardless. `.elementor .fgma-home-grid>` reaches (0,3,0) specificity, safely beating Elementor's own unscoped widget-visibility defaults with no `!important` needed (consistent with every other Elementor cascade fix in this file). */ .elementor .fgma-home-grid>.fgma-home-community-slot--video{ display:none; } @media (min-width:1440px){ .elementor .fgma-home-grid>.fgma-home-community-slot--video{ display:block; } } /* --- 6f. Community-local reveal state -------------------------------------- R3.7B.10B: deliberately NOT the frozen shared `fgma-reveal.js`/`fgma- reveal.css` system (never modified -- see that system's own docblock) -- a Community-local controller inside `fgma-home.js`'s own independent IIFE drives this instead, gated behind its own root class exactly like Hero parallax's `fgma-home-motion-ready` / Practice Areas' `fgma-home-pa-ready`. Fail-safe: absent that class (JS never ran/failed), every item stays at its own natural, fully visible, static layout position -- opacity/ transform below apply ONLY once the controller's root class is present. */ html.fgma-home-community-ready [data-fgma-community-reveal="pending"]{ opacity:0; transform:translateY(20px); transition:none; } html.fgma-home-community-ready [data-fgma-community-reveal="visible"]{ opacity:1; transform:translateY(0); transition:opacity 1.5s ease,transform 1.5s ease; } @media (prefers-reduced-motion:reduce){ html.fgma-home-community-ready [data-fgma-community-reveal]{ opacity:1; transform:none; transition:none; } } /* --- Header Homepage top state --------------------------------------------- R3.7B.5C Finding 9, corrected in R3.7B.5E: Production's verified desktop- nav breakpoint is 960px (not the 899px shorthand used elsewhere in this file for the Hero's OWN layout collapse -- a separate, unrelated threshold). The compact Header wordmark (`.fgma-header-logo`, Template 2746, untouched) is hidden ONLY at >=960px AND only at the very top of the page, and reappears automatically once fgma-header.js's own real, unmodified scroll-state class (`fgma-header-is-scrolled`, toggled on `.fgma-header-v1`, confirmed live in fgma-header.js's updateScrollState()) is applied -- pure CSS, no JS touched. Below 960px the compact wordmark remains visible at all times (mobile Header is unaffected). Scoped to `body.home` so every other route is completely unaffected; navigation/ search/focus behaviour on `.fgma-header-v1` itself is untouched, only the logo anchor's visibility is toggled. The separate global scrolled-Header BACKGROUND issue (reproduced on /portfolio/ too) is explicitly out of scope for this block -- see report §17. */ @media (min-width:960px){ body.home .fgma-header-v1:not(.fgma-header-is-scrolled) .fgma-header-logo{ visibility:hidden; } }