/** * R3.7A.2A: the shared FGMA Archive/Listing layer -- generic, reusable rules for behavior/layout that * genuinely applies to MULTIPLE archives (Portfolio, Insights, and eventually Team/Expertise), scoped * entirely under the new `.fgma-archive-*`/`data-fgma-archive-*` semantic contract established this * pass. Every rule here is a direct, deliberate parallel of an already-proven, already-tested rule in * `fgma-portfolio-archive.css` -- ported, never invented -- but Portfolio's own file/classes are left * completely UNTOUCHED: Portfolio is frozen, and this file's whole purpose is to let a NEW archive * (Insights first) consume the identical proven contract without either forking a second stylesheet * under a new name per archive or risking a rename of Portfolio's own live classes for zero functional * benefit (block brief R3.7A.2A section 3: "If genericization creates meaningful regression risk for * no immediate benefit: DO NOT do it"). * * Reuses the same --fgma-* design-system custom properties and gutter/spacing conventions as * `fgma-portfolio-archive.css` -- no new arbitrary value is introduced here. No Elementor-generated * selector, no element-ID selector, no `!important`, no new global z-index anywhere in this file. */ /* --- Archive hero shell (parallels .fgma-portfolio-archive-hero/-eyebrow/-title) --------------- */ .elementor .fgma-archive-hero.e-con { display: flex; flex-direction: column; gap: var(--fgma-space-md); padding-block: var(--fgma-space-lg); padding-inline: var(--fgma-gutter); max-width: var(--fgma-content-max); margin-inline: auto; } .fgma-archive-eyebrow { margin: 0; font-size: var(--fgma-step-1); } /** * R3.7A.2I correction: the R3.7A.2H literal `padding-inline-end: 20%` is REMOVED -- confirmed by direct * user visual QA on large monitors, a flat 20%-of-containing-block value diverges from Production's * real value as viewport grows, because Production's real token is NOT a plain percentage despite its * name: re-fetched fresh directly from Production's own live generated CSS this pass (never inferred * from the variable name), `--space-20p:clamp(4.75rem,-.8521rem + 20.8451vw,32.5rem)` -- a `vw`-based * linear ramp between a 76px floor and a 520px ceiling, resolved against the VIEWPORT, not the * containing block a CSS percentage padding would resolve against -- the two references diverge more * as viewport grows past the point the hero's own gutters stop being a fixed fraction of it, which is * exactly the large-monitor symptom reported. BOTH Production Portfolio's and Production Insights' real * `

` still share the byte-identical class combo `"header-2-alt md:pr-20p"` (`.md\:pr-20p{padding- * right:var(--space-20p)}`, scoped to Production's own real `min-width:600px` `md:` breakpoint, * re-confirmed live), so this remains a genuinely shared archive-title contract. `--fgma-space-20p` is * a NEW Code-owned custom property -- scoped locally to this selector, not the Customizer's Additional * CSS field (Code cannot edit that; this is a plain declaration inside Code's own stylesheet, an * entirely different thing) -- reproducing Production's real clamp formula byte-for-byte, not a fresh * approximation. `padding-inline-end` (this file's own established logical-property convention; * equivalent to Production's physical `padding-right` for this LTR site) now consumes it directly. * Portfolio's own `

` achieves its equivalent width restriction entirely natively (Template 3160's * own per-instance `padding:0% 20% 0% 0%`, targeting a generated Elementor class Code cannot and should * not reference) and never carries this generic class at all, so this rule remains fully inert there, * zero risk to the frozen archive; compounding a Portfolio selector here would have no effect on * Portfolio (its real restriction is native, not class-driven) and is deliberately omitted. Insights' * own `

` DOES carry this class directly, so it is the one real consumer today, exactly as before. */ .fgma-archive-title { margin: 0; font-size: var(--fgma-step-2); --fgma-space-20p: clamp(4.75rem, -.8521rem + 20.8451vw, 32.5rem); padding-inline-end: 0; } /** * R3.7Q-030 (Archive Title Responsive Parity, Phase 2): Production's own real measure restriction * (`.md\:pr-20p`) is scoped to its own confirmed `min-width:600px` breakpoint, not the `767px` * Elementor-native mobile breakpoint this file uses elsewhere for OTHER, genuinely-different mobile * concerns (filter chips/buttons) -- restructured mobile-first (base rule above now defaults to `0`, * matching every viewport below this) using the exact `min-width:600px` convention already * established elsewhere in this codebase (fgma-home.css, fgma-expertise-submarkets.css) rather than * inventing a new breakpoint abstraction or an off-by-one `max-width:599px` pairing. */ @media (min-width: 600px) { .fgma-archive-title { padding-inline-end: var(--fgma-space-20p); } } /** * R3.7A.3F: mobile font-size promoted from Portfolio's OWN proven, already-approved native mobile * value -- confirmed live this pass, Portfolio's real per-instance mobile rule (Template 3160, * `elementor-element-ca3d4d1`, `@media(max-width:767px)`) is `font-size:34px;line-height:1.1em` (a * literal, fixed pixel value, never the fluid `--fgma-step-2` token Insights/Team's H1 was resolving * to at mobile, R3.7A.2G). Both are genuinely different values (confirmed by direct computation: `-- * fgma-step-2` resolves to only ~20-21px at a 390-414px viewport, well under Portfolio's fixed 34px) -- * this pass's own explicit instruction is to treat Portfolio's real, already-visually-approved value as * the one shared design-system mobile scale every archive must resolve to, not to keep deriving a * separate fluid value that merely happens to also be "modest" in isolation. `34px` is a literal, * confirmed-real, already-approved value ported directly from Portfolio's own frozen implementation -- * not an invented magic number a `--fgma-*` token could represent, mirroring this file's own * established "port the proven baseline literally" precedent (R3.7A.2H's percentage-padding port, the * card `aspect-ratio:1` port). Portfolio's own H1 never carries this generic class, so this rule * remains fully inert there, zero risk to the frozen archive; desktop is completely untouched (this * rule only exists inside the `max-width:767px` block, `--fgma-step-2` still owns every width ≥768px). * `line-height:1.1` (R3.7A.2G, unchanged) matches Portfolio's own `1.1em` exactly (`1.1` unitless and * `1.1em` compute identically here since line-height's own font-size basis is this same element). * * R3.7A.3F-R2: selector strengthened -- confirmed live via rendered DevTools inspection (not static * analysis alone) that a real Elementor Kit/Global Class rule, `.elementor .fgma-archive-title{font- * size:60px;line-height:60px;}`, is NOT scoped to any media query and reaches (0,2,0) -- strictly * greater than this rule's own plain `.fgma-archive-title` at (0,1,0), so it was winning on Insights/ * Team regardless of this rule's own correct `max-width:767px` condition (a specificity loss, not a * media-query problem). `.elementor .fgma-archive-hero .fgma-archive-title` reaches (0,3,0) using only * real, confirmed-present stable classes (`.elementor`, the shared hero shell, the shared title class * itself -- the H1 is a real descendant of `.fgma-archive-hero` on every archive that uses this generic * contract) -- strictly greater than the competing (0,2,0) Kit rule, wins outright regardless of load * order, no `!important`. Portfolio's own H1 never carries `.fgma-archive-title` at all, so this * remains fully inert there regardless of selector shape -- no Portfolio-specific compatibility * selector needed. * * R3.7A.4M: Classic-Heading-widget variant added -- confirmed live, Expertise's own H1 uses a CLASSIC * Heading widget, where `.fgma-archive-title` sits on the WRAPPER `
`, not the real `

` itself (Team's/Insights' own Atomic Heading carries the class * directly ON the H1, which is why the rule above already worked for them). `font-size`/`line-height` * are inherited properties, so the rule above alone should in principle still reach the nested H1 via * inheritance -- but confirmed live (`post-3301.css`, Template 3301's own real generated CSS) Chrome's * own per-instance rule sets `.elementor-heading-title{font-size:60px;line-height:60px;...}` * UNCONDITIONALLY (no media query at all, always active) DIRECTLY on that real `

` element -- an * explicit declaration on the element itself always beats an inherited value from an ancestor, * regardless of specificity or media-query scope, so the rule above could never have reached it (the * exact same "explicit beats inherited" root cause already diagnosed twice this session for classic- * widget color and card-title font-size). The new selector below drills through to * `.elementor-heading-title` explicitly. * * R3.7A.4N correction -- confirmed live the mobile H1 STILL rendered at 60px after the R3.7A.4M fix. * Root-caused, not assumed (an earlier, incomplete `grep` capture had under-counted the competing * rule's real selector, hiding this): the REAL, full competing rule is `.elementor-3301 .elementor- * element.elementor-element-0e55361 .elementor-heading-title{font-size:60px;line-height:60px;...}` -- * FOUR classes, (0,4,0), not the (0,2,0) previously assumed. That EXACTLY TIES the R3.7A.4M selector's * own (0,4,0), and on the tie, Elementor's own later-loaded per-template file won -- a genuine, now- * confirmed miss, not a theoretical risk. Compounding the real, confirmed-present, genuinely GENERIC * `.elementor-widget-heading` class (marking "this is a Heading widget", not a template ID -- already * used for exactly this purpose by this file's own card-title selector) reaches (0,5,0), strictly * greater, winning regardless of load order, no `!important`. `.elementor-widget-heading` is a Classic- * widget-only class Team's/Insights' own Atomic Heading never carries, so the Atomic-H1 rule above is * left completely untouched and this remains a real, generic extension of the shared contract, not an * Expertise-only rule -- fully inert for Portfolio (never carries `.fgma-archive-title` on any * ancestor, re-confirmed live this pass, string-absent from the whole page) and for Team/Insights * (their Atomic H1 has no nested `.elementor-heading-title` for this descendant selector to match). * * R3.7Q-030 (Phase 2): the Atomic-H1 rule that used to sit here (`.elementor .fgma-archive-hero * .fgma-archive-title{font-size:34px;line-height:1.1;}`) is REMOVED, not replaced with another * hard-coded mobile value -- Phase 1 already corrected the Elementor Global Class itself * (`g-a436827`/`.fgma-archive-title`) to `font-size:var(--fgma-step-6);line-height:1.1;`, so that * shared, fluid, Production-matching typography contract now continues through mobile UNAIDED for * Insights/Team (their real H1 carries `.fgma-archive-title` directly, no competing per-template * override exists for either) -- Production itself uses `var(--step-6)`/`1.1` continuously across * every viewport, never a separate fixed mobile step. The Classic-Heading-widget selector immediately * below is UNCHANGED and untouched by this pass: it is the one and only mitigation for Expertise * Archive 3301's own separate, still-latent, still-unowned `60px`/`line-height:60px` per-template * override (R3.7A.4M/4N above) -- removing its `34px` here would not fix that issue, it would only * make Expertise's mobile H1 revert to the SAME wrong 60px/1.0 its desktop already has today, a real * regression for an archive this task's own brief explicitly places out of scope (backlog only, a * different owner). Portfolio's own H1 never carries `.fgma-archive-title` at all, so neither * selector's presence or absence has ever mattered there. */ @media (max-width: 767px) { .elementor .fgma-archive-hero .fgma-archive-title.elementor-widget-heading .elementor-heading-title { font-size: 34px; line-height: 1.1; } } /* --- Archive results shell (parallels .fgma-portfolio-archive-results) -------------------------- */ .elementor .fgma-archive-results.e-con { padding-inline: var(--fgma-gutter); max-width: var(--fgma-content-max); margin-inline: auto; } /* --- Archive card geometry (parallels the R3.7A.2J native-padding diagnosis) --------------------- */ /** * R3.7A.2K: generic zero-padding contract for archive card primitives, so future archive cards * (Team/Expertise) never have to rediscover this bug. Confirmed live root cause (diagnosed and fixed * NATIVELY in R3.7A.2J, per-template): Elementor's own atomic base rules inject a default `10px` * padding onto any element carrying the corresponding atomic class -- `.elementor .e-flexbox-base * {padding:10px;...}` and `.elementor .e-div-block-base{padding:10px;...}` (both `base-desktop.css`, * both (0,2,0)) -- which silently affected Portfolio's card root (Loop Item 3157, `e-flexbox-base`) * and Insights' card root + media wrapper (Loop Item 3241, `e-flexbox-base` + `e-div-block-base` * respectively, confirmed live via each card's own real DOM class list). R3.7A.2J already corrected * this NATIVELY on both templates (current pages are visually correct); this rule is the SHARED, * Code-owned backstop so a future archive built with the same atomic widgets is correct from day one, * without requiring a human to rediscover and manually zero out the same native per-instance setting * again. `.fgma-archive-card`/`.fgma-archive-card__media` are the new generic primitives; Portfolio's * `.fgma-project-archive-card`/`.fgma-project-archive-card__media` and Insights' `.fgma-insight-card`/ * `.fgma-insight-card__media` are compounded into the SAME rules for backward compatibility (one * shared rule, never a duplicate per archive) -- their own frozen Elementor templates are NOT edited * again this pass (R3.7A.2J's native `padding:0` overrides are left in place as harmless defensive * redundancy; this rule is now the actual future-facing contract). * * Specificity: `.elementor .fgma-archive-card.e-flexbox-base` (etc.) reaches (0,3,0), strictly greater * than the native (0,2,0) atomic base rules, using only real, confirmed-present stable classes * (`.elementor`, the semantic card class, `.e-flexbox-base`/`.e-div-block-base` -- the exact class the * native rule itself targets, guaranteed present on any element the native rule could ever match) -- * wins outright regardless of load order, no `!important`. Portfolio's own `.fgma-project-archive- * card__media` is confirmed live to be a classic widget wrapper, never an atomic `e-div-block-base` * element (no competing native padding rule exists for it at all) -- included in the media rule * without the atomic-class compound (would never match otherwise), harmless since it only reinforces * the same already-correct `0` value. */ .elementor .fgma-archive-card.e-flexbox-base, .elementor .fgma-project-archive-card.e-flexbox-base, .elementor .fgma-insight-card.e-flexbox-base { padding: 0; gap: 0; } .elementor .fgma-archive-card__media.e-div-block-base, .elementor .fgma-insight-card__media.e-div-block-base, .fgma-project-archive-card__media { padding: 0; } /** * R3.7A.2M: generic vertical-rhythm contract (media->title, title->meta). Confirmed live: * Production Portfolio's and Production Insights' real card markup use the BYTE-IDENTICAL title class * combo (`paragraph-list-item mt-sm duration-500 group-hover:text-red lg:header-5`) and the * BYTE-IDENTICAL meta class combo (`text-grey mt-3xs paragraph-sm`) -- a genuinely SHARED rhythm * contract, not archive-specific, re-verified fresh this pass, never assumed from the earlier * "~21px"/"~5.5px" user measurement alone. `mt-sm`/`mt-3xs` map to `--space-sm`/`--space-3xs`, both * byte-identical clamp formulas to the already-existing `--fgma-space-sm`/`--fgma-space-3xs` tokens * (confirmed: `--space-sm` computes to ~20.2px and `--space-3xs` to ~5.35px at a 1324px viewport, * matching the user's own browser measurements almost exactly) -- no new token, no raw pixel value. * * `gap: 0` is added to the R3.7A.2K card-root rule above (same selector group, one extra declaration) * to neutralize any ambient flex `gap` so these explicit per-element margins are the SINGLE owner of * vertical rhythm -- confirmed live this was a REAL, non-hypothetical risk: Portfolio's own card root * (`.fgma-project-archive-card`) already carried its own `gap: var(--fgma-space-xs)` in * `fgma-portfolio-archive.css`, which would otherwise ADD on top of these new explicit margins and * produce double-counted spacing (confirmed live Insights' own card root carries no per-instance gap * of its own at all -- Loop Item 3241's own inline style block has zero rules for its card root -- so * this risk was Portfolio-specific, but the neutralization is applied to the whole shared card-root * rule for one consistent future contract). Portfolio's own now-redundant `gap` value is neutralized in * `fgma-portfolio-archive.css` itself (see that file's own comment) rather than deleted. * * Title: confirmed live root cause of "no space between media and title" on Insights was NOT a missing * rule -- `.fgma-insight-card__title{margin-block-start:var(--fgma-space-sm);...}` already existed * (R3.7A.2A) and was already corrected for its own specificity fight in R3.7A.2L (`.elementor * .fgma-insight-card__title.e-heading-base{margin-block-start:var(--fgma-space-sm);}`, (0,3,0), beats * the native `.elementor .e-heading-base{margin:0px;}` at (0,2,0)) -- that fix is LEFT IN PLACE in * `fgma-insights-archive.css` (harmless, computes the identical value, not deleted per this pass's own * "no need to delete harmless historical CSS" guidance) and is superseded in spirit by this shared rule, * which now also covers Portfolio and any future atomic- or classic-widget-based archive card title. * Portfolio's own title is a CLASSIC Heading widget (`elementor-widget-heading`, never `e-heading-base`, * confirmed live) with its own native per-instance `margin:-2px 0px ...` at (0,3,0) (Loop Item 3157's * own inline style, confirmed live) -- `.elementor .fgma-project-archive-card__title.elementor-widget. * elementor-widget-heading` reaches (0,4,0), strictly greater, using only real, confirmed-present * stable classes, wins outright at every viewport (including its own separate `@media(max-width:767px)` * native override, since specificity ranking is independent of which media query a rule sits in). * * Meta: same root cause, same fix shape, for the previously-unfixed title->meta gap. Insights' meta is * ALSO an Atomic Heading widget (`

`, confirmed live) * -- `.fgma-insight-card__meta{margin-block-start:var(--fgma-space-3xs);...}` (R3.7A.2A) was ALSO * always losing to the identical native `.elementor .e-heading-base{margin:0px;}` (0,2,0) reset, the * exact same bug R3.7A.2L already diagnosed for the title but never checked for meta. Portfolio's meta * is a Shortcode widget (`elementor-widget-shortcode`, confirmed live) with NO native per-instance * margin of its own at all (confirmed: no rule exists anywhere for its own generated element ID), so * Code's own existing `.fgma-project-archive-card__meta{margin:0;...}` was the sole real owner there -- * a plain, un-compounded selector suffices for it. * * R3.7A.3E: `color` added -- confirmed live this pass, Team's own title (an Atomic Heading widget, * `e-heading-base`, identical shape to Insights') had NO rest-state color rule anywhere -- the exact * same inherited-theme-link-red gap (`a{color:#c36}`, `hello-elementor`'s own reset default) R3.7A.2C * already diagnosed and fixed for Insights specifically, just never generalized here. Reuses the * identical confirmed black token Insights' own rule already sets (harmless redundancy there -- same * value, (0,3,0) here vs its own (0,1,0), no visible change) and is fully inert for Portfolio (whose * own classic-widget title already resolves to black via Elementor's native Style-tab Global Color * binding, never CSS, and never carries this generic class). */ .elementor .fgma-archive-card__title.e-heading-base, .elementor .fgma-insight-card__title.e-heading-base, .elementor .fgma-archive-card__title.elementor-widget.elementor-widget-heading, .elementor .fgma-project-archive-card__title.elementor-widget.elementor-widget-heading { margin-block-start: var(--fgma-space-sm); color: var(--e-global-color-v4-fgma-black); } .elementor .fgma-archive-card__meta.e-heading-base, .elementor .fgma-insight-card__meta.e-heading-base, .fgma-archive-card__meta, .fgma-project-archive-card__meta { margin-block-start: var(--fgma-space-3xs); } /** * R3.7A.3E: generic archive-card HOVER contract, promoted from the already-proven, byte-identical * Portfolio (R3.7A.1-V5)/Insights (R3.7A.2C) implementations. Confirmed live this pass: Production * Portfolio, Insights and Team all share the exact same conceptual interaction on the confirmed real * `.group`/`group-hover:` markup -- portrait `scale(1.04)`, `duration-700 ease-in-out` (`.7s cubic- * bezier(.4,0,.2,1)`, matching the transition curve already proven on Portfolio's/Insights' own base * image rules), name/title recolors to the confirmed real brand-red token, metadata/role is never * touched by any hover rule (Production's own `.text-grey`/`paragraph-sm` role line carries no * `group-hover:` modifier at all on any of the three archives) -- a genuinely single, shared * interaction, not three coincidentally-similar ones. * * `.fgma-archive-card__media img` (generic base rule, new) -- confirmed live this pass Team's own * `` had NO base rule anywhere (no `object-fit`/`height:100%`/`transition`) -- it happened to * render correctly today only because every current source portrait is already pre-cropped square, not * because the CSS contract was actually complete. Mirrors Insights' own proven `.elementor * .fgma-insight-card__media img` rule verbatim (same `.elementor` compound, same properties) so the * frame reliably clips/fills and the hover transition has something to animate regardless of a future * non-square source image. Inert for Portfolio/Insights (neither's own `` carries the bare * generic `fgma-archive-card__media` class), so this cannot double up with either archive's own * existing base image rule. * * Hover selectors are grouped to cover each archive's own REAL, confirmed DOM shape rather than a * single invented shape: Insights and Team already carry (or, for Team, ARE) the interactive element * as a plain ``, so `.fgma-archive-card:hover .fgma-archive-card__title`/`.fgma-insight-card. * fgma-insight-card__link:hover .fgma-insight-card__title` reach the visible text directly (both are * Atomic Heading widgets with no extra inner-link nesting); Portfolio's card is a `
` (never * natively focusable, hence `:focus-within` there) wrapping a CLASSIC Heading widget whose visible text * sits two levels deeper on `.elementor-heading-title` -- the exact selector shape already proven in * `fgma-portfolio-archive.css` is reused verbatim here, not reinvented. Portfolio's own defensive * `transform: none` wrapper-reset (neutralizing a real, confirmed legacy Customizer Additional-CSS rule * that only Portfolio's own legacy `fgma-featured-projects__card-image` class exposes it to) is also * reused verbatim -- Insights/Team never carry that legacy class, so it is inert, harmless scope * creep for them, never a real risk. * * Portfolio's and Insights' own existing per-file hover rules are deliberately left completely * untouched -- both already set the exact same values these new shared rules set, so there is no * double-transform or conflicting-transition risk (two rules resolving to the identical computed value * is not a conflict), and removing proven, working, frozen-archive CSS for zero visual benefit is * exactly the risk this pass's own "no broad cleanup unless necessary" guidance warns against. */ .elementor .fgma-archive-card__media img { display: block; width: 100%; height: 100%; object-fit: cover; transition: transform .7s cubic-bezier(.4, 0, .2, 1); } .fgma-archive-card:hover .fgma-archive-card__media img, .fgma-archive-card:focus-within .fgma-archive-card__media img, .fgma-insight-card.fgma-insight-card__link:hover .fgma-insight-card__media img, .fgma-insight-card.fgma-insight-card__link:focus-within .fgma-insight-card__media img, .fgma-project-archive-card.fgma-featured-projects__card-link:hover .fgma-project-archive-card__media img, .fgma-project-archive-card.fgma-featured-projects__card-link:focus-within .fgma-project-archive-card__media img { transform: scale(1.04); } .fgma-project-archive-card.fgma-featured-projects__card-link:hover .fgma-project-archive-card__media, .fgma-project-archive-card.fgma-featured-projects__card-link:focus-within .fgma-project-archive-card__media { transform: none; } .fgma-archive-card:hover .fgma-archive-card__title, .fgma-archive-card:focus-within .fgma-archive-card__title, .fgma-insight-card.fgma-insight-card__link:hover .fgma-insight-card__title, .fgma-insight-card.fgma-insight-card__link:focus-within .fgma-insight-card__title, .fgma-project-archive-card.fgma-featured-projects__card-link:hover .fgma-project-archive-card__title.fgma-featured-projects__card-title .elementor-heading-title, .fgma-project-archive-card.fgma-featured-projects__card-link:focus-within .fgma-project-archive-card__title.fgma-featured-projects__card-title .elementor-heading-title { color: var(--e-global-color-v4-fgma-brand-red); } /* --- Filter bar / trigger / drawer (parallels the R3.7A.1-V9/V10 Portfolio filter-bar contract) - */ /** * R3.7A.2G: filter-bar desktop alignment + mobile full-width, ported from the proven R3.7A.1-V9/V10 * Portfolio mechanism (`fgma-portfolio-archive.css`'s own `.fgma-portfolio-filter-bar` rules), which * the shared `.fgma-archive-filter-bar` class had never received at all -- confirmed live, this file * only ever set a bare `justify-content: space-between` here (R3.7A.2A), the exact single-property * mechanism V9 already proved UNRELIABLE alone (nothing forces the actual flex-item wrappers to the * widths that make that alignment hold up, so Insights was silently exposed to that same V9-era bug * this whole time on desktop, and had NO mobile-width rule at all). Confirmed live via the real DOM * (`elementor-element-5cfd39e.fgma-archive-filter-bar` > `elementor-element-da06c96` [chips/active- * filters] + `elementor-element-357f040` [Trigger] -- the identical two-child shape Portfolio's own bar * has) and the real generated CSS (`post-3249.css`): NEITHER child wrapper carries any native * width/flex-basis override at ANY breakpoint (unlike Portfolio's Template 3160, which has its own * native per-instance rules for this -- see below), so they were falling back entirely to Elementor's * own unconstrained Atomic Container default. * * Portfolio's OWN file/rule is deliberately left untouched: its own already-proven implementation * already fully solves this for Portfolio (confirmed live, no complaint this round for either desktop * alignment or mobile width), so compounding `.fgma-portfolio-filter-bar` into this generic rule would * only be a redundant, zero-benefit duplicate for an already-frozen, already-working archive -- unlike * the Filter Trigger typography fix above, there is no live Portfolio bug here for a shared rule to * fix. `.elementor`/`.e-con` are compounded to reach a specificity strictly greater than Elementor's own * competing `:where()`-consumed custom-property chain, mirroring the identical established pattern. * * The mobile rule is a genuine ADDITION beyond what Portfolio's own file needed: Portfolio's mobile * full-width trigger/chips wrappers come from Elementor's own native per-instance mobile CSS on each * wrapper's generated class (confirmed live: `.elementor .e-efd9125{width:100%}`/`.elementor * .e-5685616{width:100%}` in Portfolio Template 3160's own `local-3160-frontend-mobile.css`) -- * Insights never received an equivalent native mobile override (confirmed live: no * `local-3249-frontend-mobile.css` file exists for Insights' template at all), so its Trigger wrapper * was silently left at Elementor's own unconstrained default width on mobile -- exactly the reported * bug. The same `:has()` relational-selector technique already proven for the desktop rule reaches the * real flex-item wrapper (an Elementor-generated element with no stable class of its own) via the * stable descendant `.fgma-archive-filter-trigger` class instead, scoped to Elementor's own real mobile * breakpoint convention (`max-width: 767px`, confirmed live against Portfolio's own native mobile CSS * above), not the unrelated `600px`/`768px` boundaries used elsewhere in this file for other rules. */ .elementor .fgma-archive-filter-bar.e-con { justify-content: space-between; margin-block-end: var(--fgma-space-xl); } @media (min-width: 768px) { .elementor .fgma-archive-filter-bar.e-con { flex-wrap: nowrap; } .elementor .fgma-archive-filter-bar > *:has(.fgma-archive-filter-trigger) { width: auto; margin-inline-start: auto; } } /** * R3.7A.3F: mobile full-width, belt-and-suspenders across the whole chain. Confirmed live this pass: * the wrapper-only `width:100%` rule above (R3.7A.2G) correctly reaches the real flex-item wrapper (the * `:has()` match against the confirmed real DOM was re-verified this pass, still correct) and carries * strictly greater specificity than every confirmed competing native rule -- but user visual QA proves * the RENDERED button itself still shows as a small content-width pill on Insights/Team, "visual * reality overrides previous reports." Rather than continuing to chase which single link in the * wrapper -> widget -> `` chain is the real culprit, this explicitly sets `width:100%` at all three * confirmed-real, stable levels -- the flex-item wrapper (unchanged from R3.7A.2G), the Trigger widget * div itself (`.fgma-archive-filter-trigger`), and the actual clickable anchor (`.fgma-archive-filter- * trigger .elementor-button`) -- exactly matching this pass's own explicit required target. Confirmed * live no native rule sets `width` on either the widget or the button at any breakpoint for Insights/ * Team (`post-3249.css`/`post-3277.css`), so there is nothing to fight -- these are pure additions, not * specificity battles. Desktop (`min-width:768px` above) is untouched, so the Trigger remains * content-width and right-aligned there. * * R3.7A.3F-R4: real rendered DOM/computed-style diagnosis identified one more structural gap, shared * by Insights and Team alike: Portfolio's own native mobile settings additionally provide `flex-wrap: * wrap` on the bar itself, plus `width:100%` on the ACTIVE-FILTERS wrapper (not just the Trigger * wrapper) -- confirmed live, Insights'/Team's own active-filters wrapper carries no native width * override either, so with `flex-wrap` still `nowrap`-free-defaulting and no explicit `wrap`, an empty * active-filters wrapper shrinks to its own padding-only content size (~20px) and sits beside the * Trigger in the same row instead of stacking onto its own full-width row -- with a filter active, * both flex items are squeezed into one row instead of each spanning its own. `flex-wrap: wrap` on the * bar plus `width: 100%` on BOTH structural wrappers (grouped into the same rule, same `:has()` * technique already proven for the Trigger wrapper) reproduces Portfolio's own proven mobile stacking * exactly -- `.fgma-archive-active-filters` itself is never removed/hidden, only its own flex-item * ancestor is forced to take a full row, so pills/removal/URL-hydration/fragment-sync all keep working * unchanged. */ @media (max-width: 767px) { .elementor .fgma-archive-filter-bar.e-con { flex-wrap: wrap; } .elementor .fgma-archive-filter-bar > *:has(.fgma-archive-active-filters), .elementor .fgma-archive-filter-bar > *:has(.fgma-archive-filter-trigger) { width: 100%; } .fgma-archive-filter-trigger { width: 100%; } .fgma-archive-filter-trigger .elementor-button { width: 100%; } } /** * R3.7A.2G: Filter Trigger sizing parity. Confirmed live root cause: BOTH archives' Trigger widgets * carry near-identical native Elementor per-instance settings (`font-size:17px;padding:16px 30px 16px * 30px;border-radius:30px`, confirmed live on both Portfolio's `elementor-element-33906c3` and * Insights' `elementor-element-b45aa7a`) EXCEPT `font-weight` -- Portfolio's is `800`, Insights' is * `500` -- and the plain `.fgma-archive-filter-trigger .elementor-button` rule below was only ever * (0,2,0), an exact TIE with that native `.elementor-element-XXXXXXX .elementor-button` rule (also * (0,2,0)); Elementor's own CSS loads after this file, so at that tie the NATIVE per-instance weight * always won on both archives, never this rule's own `font-weight:600` -- the shared rule was * reaching both archives (contrary to one candidate root cause), but losing the specificity fight on * both, just to two DIFFERENT native fallback values, which is exactly the visible inconsistency * (Portfolio heavier/800, Insights medium/500, neither the confirmed real Production weight). * * `.elementor .fgma-archive-filter-trigger.elementor-widget.elementor-widget-button .elementor-button, * .elementor .fgma-portfolio-filter-trigger.elementor-widget.elementor-widget-button .elementor- * button` reaches (0,5,0) -- strictly greater, using only real, confirmed-present stable classes on * both widgets (`.elementor`, `.elementor-widget`, `.elementor-widget-button`, each archive's own * Trigger class) -- wins outright on both archives regardless of load order, no `!important`. * Portfolio's own distinct `.fgma-portfolio-filter-trigger` class is deliberately compounded into this * SAME shared rule (in the shared file, not a Portfolio-specific one) rather than duplicated into * `fgma-portfolio-archive.css` -- this is the explicitly-requested "most reusable way possible" fix: * ONE rule, not two, and any future archive only ever needs to add its own class to this same list (or * simply consume `.fgma-archive-filter-trigger` directly and never need a listing at all). Values set * to the confirmed real Production contract (`_nuxt/D2EsIDjZ.js`'s `.btn,.btn-red` base + the * Trigger's own confirmed `py-[16px] px-[30px]` override, R3.7A.2F): `--fgma-weight-heavy` (`800`, * matches Production's `AvenirHeavy`), `--fgma-step-0` (matches `var(--step-0)`), `16px 30px` padding * (already matched natively; set explicitly here too for full, deterministic ownership). * * R3.7A.2H: `transition` added -- confirmed live directly in Production's own compiled CSS (fetched * fresh from the real Production HTML this pass, not the screenshot): `.btn-red{background:rgb(var( * --c-red-rgb)/1);...transition:background .3s}` / `.btn-red:hover{background:rgb(var(--c-red-hover- * rgb)/1)}`. The hover COLOR itself was already correct here (`--e-global-color-v4-fgma-red-hover` * resolves to `#C31400`, confirmed live in `post-7.css` -- byte-identical to Production's own real * `--c-red-hover-rgb:195 20 0`, and `--e-global-color-v4-fgma-brand-red` resolves to `#F21400`, * byte-identical to Production's own `--c-red-rgb:242 20 0`), but the color swap was instantaneous -- * Production's is a subtle `.3s` fade. No per-rule `prefers-reduced-motion` guard is added: no global * provision exists to hook into (confirmed -- only `fgma-back-to-top.css` has its own local guard), and * every other transition already in this file family (`fgma-archive.css`/`fgma-insights-archive.css`/ * `fgma-portfolio-archive.css`'s own image-zoom/title-color transitions) is likewise unguarded -- * matching that established convention exactly, not inventing a new one. */ .elementor .fgma-archive-filter-trigger.elementor-widget.elementor-widget-button .elementor-button, .elementor .fgma-portfolio-filter-trigger.elementor-widget.elementor-widget-button .elementor-button { background: var(--e-global-color-v4-fgma-brand-red); color: var(--e-global-color-v4-fgma-white); border-radius: 999px; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-heavy); font-size: var(--fgma-step-0); line-height: 1.35; padding: 16px 30px; transition: background .3s; } /** * R3.7A.2I: confirmed live root cause of "hover doesn't work" -- this hover/focus-visible rule was only * ever (0,3,0) (`.fgma-archive-filter-trigger .elementor-button:hover` = 2 classes + 1 pseudo-class), * strictly LOWER than the rest-state rule directly above (0,5,0). A `:hover`/`:focus-visible` condition * does not exempt a rule from the ordinary cascade: at all times, including while hovering, BOTH the * always-on rest rule and this conditional rule match the element, and the cascade picks whichever has * the HIGHER specificity for the `background` property -- our own (0,5,0) rest rule was silently * beating our own (0,3,0) hover rule, so hovering never visibly changed anything (not a selector- * doesn't-match bug -- `:hover` fires correctly, the winning declaration just never moved off the rest * value). Raised to the identical compounded shape as the rest rule plus the pseudo-class, reaching * (0,6,0) -- strictly greater than our own rest rule (and every native competitor), so it wins * outright and deterministically at every viewport on both archives. */ .elementor .fgma-archive-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:hover, .elementor .fgma-archive-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:focus-visible, .elementor .fgma-portfolio-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:hover, .elementor .fgma-portfolio-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:focus-visible { background: var(--e-global-color-v4-fgma-red-hover); color: var(--e-global-color-v4-fgma-white); } .elementor .fgma-archive-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:focus-visible, .elementor .fgma-portfolio-filter-trigger.elementor-widget.elementor-widget-button .elementor-button:focus-visible { outline: 2px solid var(--e-global-color-v4-fgma-control-blue); outline-offset: 2px; } /** * R3.7A.2E: mobile height parity with Clear All. Confirmed live root cause: each archive's Apply * widget carries its OWN native Elementor per-instance mobile padding override at * `@media(max-width:767px)` -- Portfolio's real value is `padding:16px 30px 16px 30px`, Insights' is * `padding:23px 30px 23px 30px` (confirmed live in each template's own generated CSS) -- genuinely * different native settings drifting apart per archive, exactly the failure mode a single shared * system must not repeat. Both native rules reach (0,4,0) (`.elementor-XXXX .elementor-element. * elementor-element-XXXXXXX .elementor-button`); `.elementor .fgma-archive-filter-apply.elementor- * widget.elementor-widget-button .elementor-button` reaches (0,5,0) using only real, confirmed-present * stable classes (`.elementor`, the widget's own `.elementor-widget`/`.elementor-widget-button`, the * shared semantic class) -- strictly greater, so it wins outright at every viewport, regardless of * load order, no `!important` needed. `font-family`/`font-size`/`line-height`/`padding` are set to the * exact same values `.fgma-archive-filter-clear-all` already uses below, so the two CTAs are now * driven by one identical, Code-owned typography/padding contract instead of each archive's own * independently-drifting native Elementor settings -- future archives inherit this automatically. * * R3.7A.2F correction: `padding`/`font-weight` were still visibly too large versus Production. * Confirmed live directly in Production's own compiled component (`_nuxt/D2EsIDjZ.js`, the Filter * drawer's `Apply`/`Clear All` buttons): both share one real base rule, `.btn,.btn-red{align-items: * center;display:inline-flex;font-family:AvenirHeavy;font-size:var(--step-0);gap:8px;justify-content: * center;line-height:1.35;padding:8px 18px 7px}` -- `padding: 8px 18px 7px`, not `16px 30px` (that * larger 16px/30px padding is real, but confirmed live to belong only to the separate Filter TRIGGER * button, which has its own `py-[16px] px-[30px]` override on top of this same base rule -- the * drawer's Apply/Clear-All buttons never carry that override). `font-weight` corrected from a * hardcoded `600` to the confirmed real `AvenirHeavy` weight via the already-existing `--fgma-weight- * heavy` token (`800`) -- `font-size`/`line-height` were already correct (`var(--fgma-step-0)`/ * `1.35`, matching Production's own `var(--step-0)`/`1.35` exactly) and are unchanged. * * R3.7A.2H: `transition` added -- confirmed live, Production's real Apply button carries the identical * `btn-red` class as the Trigger (`_nuxt/D2EsIDjZ.js`: `class:"btn-red relative"`), so it shares the * exact same `transition:background .3s` contract -- see the Trigger rule above for the full color- * token verification (`--e-global-color-v4-fgma-red-hover` already resolves to the confirmed real * `#C31400`). No `prefers-reduced-motion` guard, matching this file's own established convention. * * R3.7A.2I: `.fgma-portfolio-filter-apply` compounded in -- confirmed live root cause of "Portfolio * drawer footer CTAs still too tall": Portfolio's OWN dedicated widget class (`.fgma-portfolio-filter- * apply`, still present and rendered on Portfolio's own frozen widget wrapper, `elementor-element- * d6a2115`) was NEVER a consumer of this rule -- only the generic `.fgma-archive-filter-apply` was ever * targeted here, so Portfolio's Apply button fell through entirely to its own separate, stale * `fgma-portfolio-archive.css` rule (no padding/font-size of its own, `font-weight:600` hardcoded) plus * Elementor's own native per-instance rule (confirmed live on `elementor-element-d6a2115`: `font-size: * 18px;font-weight:600;line-height:27px;padding:17px 30px 17px 30px`) -- the exact oversized, never- * corrected values the user is seeing. Compounded here using the identical proven grouped-selector * pattern already established for the Trigger fix (R3.7A.2G): reaches (0,5,0) on Portfolio's own widget * too (`.elementor`, `.elementor-widget`, `.elementor-widget-button`, `.fgma-portfolio-filter-apply`), * strictly beating both Portfolio's own stale (0,2,0) rule and the native (0,4,0) rule. Portfolio's own * `fgma-portfolio-archive.css` rule is deliberately left in place, unedited -- now fully superseded/ * dead for the properties this rule owns, per the same "leave frozen file alone, let the shared rule * win on specificity" precedent already used for the Trigger. */ .elementor .fgma-archive-filter-apply.elementor-widget.elementor-widget-button .elementor-button, .elementor .fgma-portfolio-filter-apply.elementor-widget.elementor-widget-button .elementor-button { background: var(--e-global-color-v4-fgma-brand-red); color: var(--e-global-color-v4-fgma-white); border-radius: 999px; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-heavy); font-size: var(--fgma-step-0); line-height: 1.35; padding: 8px 18px 7px; width: 100%; transition: background .3s; } /** * R3.7A.2I: hover/focus-visible raised to the identical compounded shape as the rest rule above, plus * `.fgma-portfolio-filter-apply` -- fixes the exact same "own rest rule beats own hover rule" cascade * bug diagnosed and fixed for the Trigger above (was (0,3,0), now (0,6,0)/(0,5,0) on Portfolio's class, * strictly greater than the rest rule in both cases). */ .elementor .fgma-archive-filter-apply.elementor-widget.elementor-widget-button .elementor-button:hover, .elementor .fgma-archive-filter-apply.elementor-widget.elementor-widget-button .elementor-button:focus-visible, .elementor .fgma-portfolio-filter-apply.elementor-widget.elementor-widget-button .elementor-button:hover, .elementor .fgma-portfolio-filter-apply.elementor-widget.elementor-widget-button .elementor-button:focus-visible { background: var(--e-global-color-v4-fgma-red-hover); } .fgma-archive-filter-close .elementor-button { background: var(--e-global-color-v4-fgma-white); color: var(--e-global-color-v4-fgma-off-black); border: 1px solid var(--e-global-color-v4-fgma-light-gray); border-radius: 999px; font-weight: 600; } .fgma-archive-filter-close .elementor-button:hover, .fgma-archive-filter-close .elementor-button:focus-visible { background: var(--e-global-color-v4-fgma-off-white); } .elementor .fgma-archive-filter-apply.elementor-widget.elementor-widget-button .elementor-button:focus-visible, .elementor .fgma-portfolio-filter-apply.elementor-widget.elementor-widget-button .elementor-button:focus-visible, .fgma-archive-filter-close .elementor-button:focus-visible { outline: 2px solid var(--e-global-color-v4-fgma-control-blue); outline-offset: 2px; } .fgma-archive-filter-drawer { gap: var(--fgma-space-sm); } /* Drawer header ("Filter by:" left / Close top-right) and footer (Clear All left / Apply right, each * ~50% width, same row) -- parallels the R3.7A.F3 fix, same real Elementor `:where()`-bypass technique * (see fgma-portfolio-archive.css's own header/footer rule comments for the full root-cause * evidence): setting the literal property directly at any non-zero specificity beats Elementor's own * `--justify-content`/`--flex-direction` custom-property chain regardless of load order. */ .fgma-archive-filter-drawer__header { justify-content: space-between; border-bottom: 1px solid var(--e-global-color-v4-fgma-light-gray); } .fgma-archive-filter-drawer__footer { flex-direction: row; border-top: 1px solid var(--e-global-color-v4-fgma-light-gray); } .fgma-archive-filter-drawer__footer > .fgma-archive-filter-apply, .fgma-archive-filter-drawer__footer > *:has(.fgma-archive-filter-clear-all) { flex: 1 1 0; } .fgma-archive-filter-drawer__footer > *:has(.fgma-archive-filter-clear-all) { order: 1; } .fgma-archive-filter-drawer__footer > .fgma-archive-filter-apply { order: 2; } /** * R3.7A.2E: "Filter by:" heading weight. Confirmed live: BOTH Portfolio's (`e-a048985-faf7c7f`) and * Insights' (`e-6d5cf25-03c5196`) drawer headings are Elementor's newer Atomic Heading widget, each * with its own generated per-instance class carrying `font-weight:400` (confirmed identical on both * archives -- Portfolio was never actually at the correct 500 either, so this is a genuine shared * correction, not an Insights-only patch). Neither heading carries a dedicated semantic class of its * own; `.fgma-archive-filter-drawer__header > h2` reaches it robustly using only the already-existing * shared container class plus the real, structural element type (the heading is confirmed live to be * a direct child of the header container on both archives, the only other child being the Close * button widget) -- no new Elementor class or generated ID needed. Specificity (0,1,1) strictly beats * each archive's own per-instance `.e-XXXXXXX-XXXXXXX{font-weight:400;...}` rule ((0,1,0)) regardless * of load order. `font-size`/`color` are deliberately left alone -- both archives already confirmed * identical (`30px`/`#000000`, both already the confirmed real Avenir LT Std family via each archive's * own per-instance rule) and the block brief only asks for the weight correction. */ .fgma-archive-filter-drawer__header > h2 { font-weight: var(--fgma-weight-medium); } /** * R3.7A.2E: filter-group vertical rhythm. Confirmed live root cause: `.fgma-archive-filters` (the * shared root wrapper `Insight_Filter_Controls_Renderer`/`Portfolio_Filter_Controls_Renderer`-style * renderers both emit) had NO rule at all in this shared file -- Portfolio's own visual rhythm only * ever came from its own distinct `.fgma-portfolio-filters{display:flex;flex-direction:column;gap: * var(--fgma-space-sm);}` rule in `fgma-portfolio-archive.css`, which the generic `.fgma-archive- * filters` class Insights renders never matched -- so Insights' groups had no flex/gap at all, * stacking as bare block-level `
`s with zero space between them ("Category" -> "Tags" reading as * one continuous block). Reusing the identical token (`--fgma-space-sm`) as the approved Portfolio * baseline here makes this the single shared owner for BOTH archives going forward -- Portfolio's own * rule is left completely untouched (zero risk), and this new rule only ever matches the generic * class no Portfolio markup carries. */ .fgma-archive-filters { display: flex; flex-direction: column; gap: var(--fgma-space-sm); } /* --- Filter groups / chips (parallels the R3.7A.F2 Production-confirmed chip contract) ---------- */ .fgma-archive-filter-group__label { display: block; margin-bottom: .5em; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-heavy); font-size: var(--fgma-step-0); color: var(--e-global-color-v4-fgma-black); } .fgma-archive-filter-options { list-style: none; margin: 0; padding: 0; display: flex; flex-wrap: wrap; gap: .5em; } .fgma-archive-filter-option { list-style: none; } .fgma-archive-filter-option__link { display: inline-flex; align-items: center; gap: .35em; border: 1px solid var(--e-global-color-v4-fgma-light-gray); border-radius: 999px; padding: 8px 18px 7px; background: var(--e-global-color-v4-fgma-white); color: var(--e-global-color-v4-fgma-black); text-decoration: none; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-book); font-size: var(--fgma-step-0); line-height: 1.35; } .fgma-archive-filter-option__link:hover { border-color: var(--e-global-color-v4-fgma-brand-red); color: var(--e-global-color-v4-fgma-brand-red); } .fgma-archive-filter-option__link:focus-visible { outline: 2px solid var(--e-global-color-v4-fgma-control-blue); outline-offset: 2px; } .fgma-archive-filter-option__link[data-fgma-archive-filter-selected] { background: var(--e-global-color-v4-fgma-off-white); color: var(--e-global-color-v4-fgma-black); font-weight: var(--fgma-weight-heavy); } /** * R3.7A.2F correction: confirmed live directly in Production's own compiled component * (`_nuxt/D2EsIDjZ.js`), Clear All shares the identical real base rule as Apply -- * `.btn,.btn-red{...font-family:AvenirHeavy;font-size:var(--step-0);line-height:1.35;padding:8px 18px * 7px}` -- `padding: 8px 18px 7px`, not `16px 30px` (that larger value belongs only to the separate * Filter Trigger button's own confirmed `py-[16px] px-[30px]` override, never the drawer's Apply/ * Clear-All). `font-weight` corrected to the confirmed real `AvenirHeavy` weight via the existing * `--fgma-weight-heavy` token (`800`), matching `.fgma-archive-filter-apply .elementor-button`'s own * identical R3.7A.2F correction exactly, so both CTAs stay driven by one identical contract. * * R3.7A.2I: `.fgma-portfolio-filter-clear-all` compounded in -- confirmed live, Portfolio's own Clear * All anchor (Code-authored markup, ``) never carries the generic `.fgma-archive-filter-clear-all` class at all, so this rule * never matched it in the first place -- a selector-doesn't-reach-the-element gap, not a specificity * fight (both are Code-authored plain anchors, no competing Elementor per-instance rule for either). * Portfolio fell through entirely to its own separate, stale `fgma-portfolio-archive.css` rule * (`padding:16px 30px;font-weight:600`), the exact oversized values the user is still seeing. Both * classes are single-class selectors ((0,1,0) each) compounded into ONE rule here, so there is no * duplicate/competing declaration to fight a specificity or load-order battle against -- Portfolio's own * `fgma-portfolio-archive.css` rule is left in place, unedited, now fully superseded for these * properties by virtue of no longer being the only rule matching the element. */ .fgma-archive-filter-clear-all, .fgma-portfolio-filter-clear-all { display: inline-flex; align-items: center; justify-content: center; width: 100%; border: 1px solid var(--e-global-color-v4-fgma-light-gray); border-radius: 999px; padding: 8px 18px 7px; background: var(--e-global-color-v4-fgma-white); color: var(--e-global-color-v4-fgma-off-black); text-decoration: none; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-heavy); font-size: var(--fgma-step-0); line-height: 1.35; } .fgma-archive-filter-clear-all:hover, .fgma-portfolio-filter-clear-all:hover { background: var(--e-global-color-v4-fgma-off-white); } .fgma-archive-filter-clear-all:focus-visible, .fgma-portfolio-filter-clear-all:focus-visible { outline: 2px solid var(--e-global-color-v4-fgma-control-blue); outline-offset: 2px; } /* --- Active-filter pills outside the drawer (parallels the R3.7A.F2 Production-confirmed contract) */ .fgma-archive-active-filters { display: flex; align-items: center; flex-wrap: wrap; gap: .5em; } .fgma-archive-active-filters__list { list-style: none; margin: 0; padding: 0; display: flex; flex-wrap: wrap; gap: .5em; } .fgma-archive-active-filters__tag { list-style: none; } .fgma-archive-active-filters__remove { display: inline-flex; align-items: center; gap: .4em; border-radius: 999px; padding: .35em .9em; background: var(--e-global-color-v4-fgma-light-gray); color: var(--e-global-color-v4-fgma-black); text-decoration: none; font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-book); font-size: var(--fgma-step-0); text-transform: capitalize; } .fgma-archive-active-filters__remove:hover { color: var(--e-global-color-v4-fgma-brand-red); } .fgma-archive-active-filters__remove:focus-visible { outline: 2px solid var(--e-global-color-v4-fgma-control-blue); outline-offset: 2px; } /* --- Empty state / loading status / native-pagination suppression ------------------------------ */ .fgma-archive-empty-state { margin: 0; text-align: center; color: var(--e-global-color-v4-fgma-gray); font-size: 1.1em; padding-block: var(--fgma-space-sm); } .fgma-archive-loading-status { margin: 0; padding-block: var(--fgma-space-sm); text-align: center; color: var(--e-global-color-v4-fgma-gray); font-size: .9em; } /** * Mirrors the R3.7A.1 FINAL Portfolio pagination-suppression rule exactly -- hides the real, live * native Elementor "Numbers" pagination nav ONLY once the shared JS engine has confirmed infinite * loading can actually run (`data-fgma-archive-infinite-loading`, the generic counterpart to * Portfolio's own `data-fgma-portfolio-infinite-loading`) -- never unconditionally, never * `!important`, never a generated/template/post ID. */ html[data-fgma-archive-infinite-loading] .fgma-archive-results .elementor-pagination { display: none; } /* --- R3.7Q-043B: Global Search results visual parity --------------------------------------------- * Search Results Template 3556 / Loop Item 3553 remain a fully generic global search (Page/Project/ * Expertise/Team Member/Insight) -- this is a pure visual layer. Search query behavior, pagination, * returned post types, and Header live search are completely untouched; only visual classes were * added to Template 3556/Loop Item 3553's existing widgets (never their query/content settings). * * `.fgma-search-results`/`.fgma-search-result-card` are NOT new classes this ticket introduces -- * confirmed live (not assumed) they already existed as real Elementor Global Classes on the * container/card root, each with their own already-generated CSS (`global-3556-frontend-desktop.css`: * `.fgma-search-results{max-width:1300px;padding-inline:20px;...gap:30px;}` / * `.fgma-search-result-card{padding:20px;gap:10px;}`) -- these ARE the exact hardcoded values this * ticket's own brief described. `.fgma-archive-card` was added alongside the existing * `.fgma-search-result-card` on the card root (inherits the shared media/title/hover rules above, * and its own `padding:0;gap:0` already outranks the Global Class's 20px/10px at (0,3,0) vs (0,2,0), * confirmed live). The container override below targets the real, pre-existing `.fgma-search-results` * class directly, never a new invented one. */ /* Container: replaces the pre-existing Global Class's own hardcoded max-width (1300px), 20px * gutters, 60px block padding and 30px gap with the same --fgma-content-max/--fgma-gutter/ * --fgma-space-xl tokens the Portfolio archive's own hero+results containers already use. * * R3.7Q-043B geometry follow-up: live-inspected `document.styleSheets` confirmed this element's * real class list is `... e-con e-atomic-element e-flexbox-base ... fgma-search-results ...` -- * it never carries an `.e-flexbox` class (that class belongs to a different atomic element type), * so the original `.fgma-search-results.e-flexbox` selector here never matched anything and the * Global Class's hardcoded 1300px/20px/60px/30px values were still winning live. Fixed by * compounding the real `.e-con` class instead, which the element does carry, restoring (0,3,0) so * this rule actually beats the Global Class's (0,2,0) rule. * * `padding-block` is intentionally 0 here (not carried over from the old 60px): Portfolio's own * top rhythm is owned entirely by `.fgma-portfolio-archive-hero`'s own `padding-block: * var(--fgma-space-lg)` (confirmed live, `fgma-portfolio-archive.css`), not by an outer wrapper -- * an outer padding-block here would double-stack with `.fgma-search-archive-hero`'s own * `padding-block: var(--fgma-space-lg)` below, which is exactly what was producing Search's * mismatched top spacing (60px root + 42px hero = 102px, vs. Portfolio's 42px). `gap` uses * `--fgma-space-xl`, the same token every other FGMA archive (Team, Expertise, Insights) already * uses for the deliberate space between its intro block and its first grid row. */ .elementor .fgma-search-results.e-con { max-width: var(--fgma-content-max); padding-inline: var(--fgma-gutter); padding-block: 0; margin-inline: auto; gap: var(--fgma-space-xl); } /** * Header parity: a new eyebrow/H1/subtitle hero, mirroring `.fgma-portfolio-archive-hero`'s own * layout exactly (`fgma-portfolio-archive.css`) -- same `--fgma-space-lg` block padding, same * `--fgma-space-md` gap between the three stacked text elements. No separate max-width/gutter is * declared here -- this hero sits INSIDE the same `.fgma-search-results` container above, which * already owns the shared content-max/gutter contract; declaring it a second time would be a * duplicate, competing owner. No Filter CTA exists here or is added, per this ticket's own scope. * * Confirmed live: this container carries the native `.e-flexbox-base` atomic class, whose own base * rule (`base-desktop.css`, `.elementor .e-flexbox-base{padding:10px;display:flex;flex-direction: * row;}`) is (0,2,0) -- a bare `.fgma-search-archive-hero` alone (0,1,0) loses to it. `.elementor` * compounded in reaches (0,2,0)+ via the class itself plus `.e-flexbox-base`, i.e. (0,3,0), the same * proven pattern already used throughout this file/Portfolio's own CSS. */ .elementor .fgma-search-archive-hero.e-flexbox-base { display: flex; flex-direction: column; gap: var(--fgma-space-md); padding: 0; padding-block: var(--fgma-space-lg); } .fgma-search-archive-subtitle { margin: 0; } /** * R3.7Q-043B geometry follow-up -- top rhythm below the global header. Live-inspected (not assumed): * Portfolio's real top rhythm is NOT owned by `.fgma-portfolio-archive-hero`'s own `padding-block: * var(--fgma-space-lg)` (that only accounts for 42px) -- it is owned by a literal Elementor "Advanced * > Margin" widget setting on the eyebrow widget itself, confirmed live in Template 3160's own * generated CSS: `.elementor-3160 .elementor-element.elementor-element-f66d4a2{margin:180px 0 ... 0}` * (post-3160.css), stepping down to `100px` under its own `@media(max-width:767px)` block. This is a * real, already-existing, per-widget Elementor value on Portfolio itself, not a shared --fgma-* token * (Portfolio has no token for this dimension to reuse) -- so reusing it verbatim here, at the same * 767px breakpoint Portfolio itself uses, is the literal "existing rule" this ticket calls for, never * a newly-eyeballed number. Search's eyebrow widget carries no Elementor-side margin of its own * (confirmed live in post-3556.css), so this single-class rule needs no compounding to win -- nothing * else sets margin-top on it. */ .fgma-search-archive-eyebrow { margin-top: 180px; } @media (max-width: 767px) { .fgma-search-archive-eyebrow { margin-top: 100px; } } /* Grid gap: replaces Elementor's own hardcoded 30px Loop Grid default with an existing shared * spacing token -- desktop/tablet/mobile COLUMN counts themselves are set natively on Template * 3556's own Loop Grid widget settings (columns/columns_tablet/columns_mobile), never here. * `.fgma-search-grid` -- a stable custom class added to the Loop Grid widget itself -- is used * instead of a generated `.elementor-element-XXXXXXX`/`.elementor-3556` selector, matching this * file's own established "no generated instance/template-ID selector" constraint. * * R3.7D.1 correction: live column-gap was measured at 30px against Portfolio's real 40px, a visible * mismatch -- confirmed live in `fgma-portfolio-archive.css`'s own header comment, Portfolio's real * column gap is NOT a `--fgma-space-*` token at all, it is Template 3160's own native per-instance * Loop Grid setting (`--grid-column-gap:40px`), reused verbatim there rather than approximated by a * fluid token. `--grid-column-gap` is corrected to the same literal `40px` here for byte-identical * parity -- row gap is left on the existing shared `--fgma-space-md` token (untouched, out of this * ticket's confirmed scope). * * R3.7D.1 selector correction: confirmed live via rendered DOM inspection, `.fgma-search-grid` and * `.elementor-grid` are NOT the same element -- `.fgma-search-grid` is the OUTER Loop Grid widget * wrapper, `.elementor-grid` is a separate, inner descendant (`.elementor-loop-container.elementor- * grid`, the real CSS grid Elementor's own native gap rule targets). The compounded selector * `.fgma-search-grid.elementor-grid` therefore never matched any real element -- a selector-doesn't- * reach-the-DOM bug, not a specificity fight -- so `--grid-column-gap`/`--grid-row-gap` were never * actually set anywhere and Elementor's own `var(--grid-column-gap, 30px)` fallback kept winning * (confirmed live post-deploy: column gap still measured 30px despite this rule's presence). Fixed to * a descendant selector reaching the real inner grid element directly; the literal `40px` value and * the shared `--fgma-space-md` row-gap token are unchanged. */ .fgma-search-grid .elementor-loop-container.elementor-grid { --grid-row-gap: var(--fgma-space-md); --grid-column-gap: 40px; } /** * R3.7D.1: real result thumbnails cropped to Portfolio's own proven frame. Confirmed live: Search's * real media wrapper carries the bare `.fgma-archive-card__media` class with no aspect-ratio of its * own, so each card rendered at whatever ratio its own source image happened to be (measured ~1.736 * on a Project result), visibly inconsistent card-to-card and versus Portfolio's own uniform frame. * `--fgma-media-ratio` (confirmed live = `3 / 2`) is the exact same token Portfolio's own media * wrapper already uses (`fgma-portfolio-archive.css`, `.fgma-project-archive-card__media{aspect- * ratio:var(--fgma-media-ratio)}`) -- reused verbatim, no new token. Scoped to `.fgma-search-result- * card` only, not the bare shared `.fgma-archive-card__media` class, so Insights'/Team's own already- * correct media frames (out of this ticket's scope) are completely untouched. */ .fgma-search-result-card .fgma-archive-card__media { aspect-ratio: var(--fgma-media-ratio); } /** * Missing-image placeholder: confirmed live, not assumed -- Elementor's own `theme-post-featured- * image` widget renders NOTHING at all (not even an empty wrapper element) when a result post has no * featured image (Expertise is the real, confirmed example). No suitable existing neutral placeholder * asset was found in the media library (`FGMA_monogram_-_red_bgnd.png` is a saturated brand-red * square, not a neutral field; `fgma-logo.png` is a transparent-background full lockup, not a filled * neutral box) -- per this ticket's own preference order, this is the CSS-generated fallback (option * C), never a new uploaded asset, never a per-post fake featured image. * * `:has()` on the card root detects the widget's absence directly from real DOM structure -- never a * post-type check, never a per-post ID -- so this works identically for any future result type with * no featured image, with zero special-casing. The `::before` box reuses the exact same * `--fgma-media-ratio` aspect-ratio and off-white token every other neutral FGMA surface already * uses, occupying the identical media geometry a real image would, so card alignment never shifts. * Results that already have an image never match `:not(:has(...))` at all, so this rule is completely * inert for them. */ .fgma-search-result-card:not(:has(> .elementor-widget-theme-post-featured-image))::before { content: ""; display: block; width: 100%; aspect-ratio: var(--fgma-media-ratio); background: var(--e-global-color-v4-fgma-off-white); } /* Meta: plain text only -- hides the post-info widget's own generic default icon (a plain tag glyph, * never post-type-specific), matching Portfolio's own icon-less metadata line. Confirmed live: a bare * 2-class selector here only TIES (0,2,0) Elementor's own `.elementor-widget .elementor-icon-list-icon * {display:flex;...}` (`widget-icon-list.min.css`, loaded after this file) and loses the tie to load * order -- `.elementor` compounded in reaches (0,3,0), strictly greater, wins regardless of order. */ .elementor .fgma-search-result-card .elementor-icon-list-icon { display: none; } /** * Title/meta typography: confirmed live, not assumed -- root-caused as an INHERITANCE defeat, not a * specificity fight: a bare, unscoped `.elementor-widget-heading .elementor-heading-title` rule * (Footer Template 3145's own generated CSS, `post-3145.css`, loaded on every page including Search) * sets font-family/color DIRECTLY on the real `

` text element * itself. A rule on this widget's own OUTER wrapper only ever sets an INHERITED value for that H3 -- * which a direct match on the H3 itself always wins, regardless of the wrapper rule's own specificity * (inheritance is the lowest-priority source in the cascade). These rules instead reach the real text * elements directly -- `.elementor-heading-title` for the title, `.elementor-icon-list-text` for the * meta -- reusing the exact same tokens Portfolio's own equivalent rules already use * (`--fgma-font-family`, `--fgma-weight-medium`/`--fgma-weight-book`, `--fgma-step-3`/`--fgma-step-0`) * -- no new token. Scoped through the bare `.fgma-archive-card__title`/`__meta` classes (which * Portfolio/Insights never carry), so this is fully inert for their own title/meta elements. * * R3.7D.1 correction: `--fgma-step-3` was the wrong token, not merely a value regression -- live * measurement showed Search's title rendering at 34.4px/34.4px against Portfolio's real 27px/36px, * visibly too large, the exact symptom this ticket describes. Portfolio's own card title (confirmed * live, `fgma-portfolio-archive.css`) already carries its own identical R3.7D.1 correction from * `--fgma-step-3` to `--fgma-step-2` (Production's real `.header-5{font-size:var(--step-2)}` * contract) -- reused verbatim here, never a newly-eyeballed value. `line-height: 1.35` is added to * match Production's own real `.header-4, .header-5{font-family:AvenirMedium;line-height:1.35}` * contract (confirmed live, `docs/visual-audit/evidence/network/phase-5b4-team-deepdive-data.json`), * which resolves to Portfolio's measured 36px at 27px font-size -- Portfolio's own rule never sets * `line-height` itself only because its Classic-widget title already inherits a matching native * per-instance value Code does not need to touch; Search's Atomic-heading title has no equivalent * native rule, so it is set explicitly here. */ .elementor .fgma-archive-card__title.elementor-widget.elementor-widget-heading .elementor-heading-title { font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-medium); font-size: var(--fgma-step-2); line-height: 1.35; color: var(--e-global-color-v4-fgma-black); } /* Hover: same inheritance-defeat fix as the rest-state color above -- the shared * `.fgma-archive-card:hover .fgma-archive-card__title` rule (below) only sets an inherited value on * this same wrapper, which the direct H3 rule above would otherwise keep winning at rest. Reusing the * exact same brand-red token/technique already proven for Portfolio/Insights. */ .fgma-archive-card:hover .fgma-archive-card__title.elementor-widget.elementor-widget-heading .elementor-heading-title, .fgma-archive-card:focus-within .fgma-archive-card__title.elementor-widget.elementor-widget-heading .elementor-heading-title { color: var(--e-global-color-v4-fgma-brand-red); } .elementor .fgma-archive-card__meta.elementor-widget.elementor-widget-post-info .elementor-icon-list-text { font-family: var(--fgma-font-family); font-weight: var(--fgma-weight-book); font-size: var(--fgma-step-0); line-height: 1.35; color: var(--fgma-gray); }