/*
 * zx-overrides.css — hand-written CSS overrides for staging2.
 *
 * This file replaces the practice of printing CSS inline from mu-plugins. Rules live here as a
 * real stylesheet so the browser can cache them, and so they are version-controlled with the
 * theme instead of existing only inside PHP.
 *
 * Enqueued from astra-child/functions.php -> child_enqueue_styles(), versioned with filemtime()
 * so an edit busts the cache on its own.
 *
 * RULES FOR ENTRIES
 *   - Scope every selector. Never global.
 *   - One block per problem, dated, with the reason and the measurement that justified it.
 *   - Say what would make the rule deletable, so it does not become permanent by accident.
 */


/* ---------------------------------------------------------------------------
 * 2026-09-01 — r215 "extra white space between the paragraph"
 * Was: mu-plugins/69-zx-r215-paragraph-parity.php (inline). Moved here 2026-09-02.
 *
 * staging flattens every <p> with an unscoped `p{margin-bottom:0 !important}` that still sits in
 * its header template's inline CSS. staging2's copy was deliberately scoped to
 * `.elementor-174880 p` on 2026-08-31, because unscoped it broke the AI World Tour speaker-card
 * heights. That was the correct fix, but it left staging2 with a 32px bottom margin on body
 * paragraphs — measured as text blocks rendering 58px tall where staging renders 26px.
 *
 * Restores staging's spacing ONLY inside Elementor text-editor widgets. The speaker cards use
 * ElementsKit `.profile-body` / `.profile-title` markup, not text-editor paragraphs, so the
 * 2026-08-31 fix is untouched. !important is deterministic here; it was the UNSCOPED version
 * that caused the earlier damage.
 *
 * DELETABLE WHEN: staging's unscoped `p{margin-bottom:0}` is removed from its header template and
 * both sides agree on paragraph spacing.
 * ------------------------------------------------------------------------- */
.elementor-widget-text-editor p {
    margin-bottom: 0 !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-01 — r124 footer subscribe form sits indented and narrower than staging
 * Was: mu-plugins/69-zx-r215-paragraph-parity.php (inline). Moved here 2026-09-02.
 *
 * staging renders form 164's field grid at padding 0. staging2 emits
 * `#gform_fields_164{padding:20px 21px 14px 24px}` from the UAEL GF Styler widget in the footer
 * template, whose CSS is served frozen from uploads/freshz-hf-css/ and therefore cannot be
 * corrected from the Elementor UI.
 * Measured: email field @0,0 415px wide on staging vs @24,20 370px wide on staging2.
 *
 * DELETABLE WHEN: the frozen footer CSS in uploads/freshz-hf-css/ is regenerated without that
 * padding, or the footer form stops using the UAEL GF Styler widget.
 * ------------------------------------------------------------------------- */
#gform_fields_164 {
    padding: 0 !important;
}


/* ---------------------------------------------------------------------------
 * 2026-08-31 — header CTA "Get Started" wrapped onto two lines at >=1600px
 * Was: mu-plugins/55-zycus-header-cta-nowrap.php. Moved here 2026-09-02.
 *
 * The button and the language switcher carry margins (25px / 5px / 7px) that exist in the
 * Elementor data on both environments, but staging neutralises them through ElementsKit's
 * generated CSS, which staging2 does not load. Rather than re-create that cascade, keep the
 * label on one line and let the button size to its text — and reproduce staging's
 * justify-content:flex-end on the header-right group, which was leaving the CTA 18px right of
 * where it belongs.
 *
 * DELETABLE WHEN: staging2 loads the same ElementsKit generated CSS as staging, or those
 * margins are removed from the header template's Elementor data.
 * ------------------------------------------------------------------------- */
@media (min-width: 1600px) {
    .elementor-element-17c1756 .elementor-button,
    .elementor-element-17c1756 .elementor-button-text {
        white-space: nowrap !important;
    }
    .elementor-element-17c1756 .elementor-button-wrapper,
    .elementor-element-17c1756 .elementor-widget-container {
        width: auto !important;
    }
    .elementor-element-84ce139 {
        justify-content: flex-end !important;
    }
    .elementor-element-84ce139 > .elementor-element-17c1756 {
        margin-left: 0 !important;
    }
    .elementor-element-84ce139 > .elementor-element-4d808b8 {
        margin-left: 0 !important;
        margin-right: 0 !important;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-08-31 — top-level nav dropped "Ask Merlin AI" to a second row
 * Was: mu-plugins/56-zycus-nav-nowrap.php. Moved here 2026-09-02.
 *
 * The nested-menu list computed flex-wrap:wrap on staging2 but nowrap on staging. The five
 * items need ~591px inside a 590px list, so the fifth wrapped and space-between then spread
 * the other four (Community 483 vs 443, Company 686 vs 605, Resources 827 vs 705).
 * Scoped to >=1025px: below that the menu collapses to the mobile drawer and must keep wrapping.
 * Verified 2026-09-02: at 1025/1366/1600/1920 both hosts now compute nowrap, 5 items on 1 row,
 * identical widths (460/590/700/700).
 *
 * DELETABLE WHEN: the header template's own Custom CSS carries this nowrap on staging2 as it
 * does on staging.
 * ------------------------------------------------------------------------- */
@media (min-width: 1025px) {
    .e-n-menu .e-n-menu-wrapper .e-n-menu-heading,
    nav.e-n-menu ul.e-n-menu-heading,
    ul.e-n-menu-heading {
        flex-wrap: nowrap !important;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-09-01 — mega-menu hover highlight had sharp corners
 * Was: mu-plugins/61-zycus-megamenu-hover-radius.php. Moved here 2026-09-02.
 *
 * Two stacked elements of the same size (166x36) both paint rgb(1,51,165) on hover: the inner
 * .elementor-widget-container has border-radius 12px, its parent widget element has 0. The
 * square parent paints behind the rounded child, so its corners show past them. The 12px is the
 * design intent, so give the outer element the same radius rather than remove a background.
 * Targets widget CLASSES, never element ids — header ids differ between editions of this site.
 *
 * ⚠️ `overflow:hidden` deliberately carries !important here, which it did NOT need as a
 * footer-printed <style>. From a head-enqueued stylesheet it would otherwise lose on source
 * order to Elementor's own CSS.
 *
 * DELETABLE WHEN: the mega-menu image-box widgets carry the radius on the outer element in the
 * template itself.
 * ------------------------------------------------------------------------- */
.e-n-menu-content .elementor-widget-image-box,
.e-n-menu-content .elementor-widget-image-box > .elementor-widget-container,
.e-n-menu-content .new-zycus-mega-community,
.e-n-menu-content .new-zycus-mega-community > .elementor-widget-container {
    border-radius: 12px !important;
}
.e-n-menu-content .elementor-widget-image-box,
.e-n-menu-content .new-zycus-mega-community {
    overflow: hidden !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-01 — mega-menu dropdown items sat 8px right of their neighbours
 * Was: mu-plugins/62-zycus-megamenu-align.php. Moved here 2026-09-02.
 *
 * Measured on the Solutions panel: staging renders ALL 31 items at icon@8 with item padding 0.
 * staging2 applied the padding TWICE — on the widget element AND on its
 * .elementor-widget-container — so 27 items gained 8px of left inset. The 6 that "looked wrong"
 * were in fact the ones matching staging. This removes the duplicate from the widget element
 * only; the container keeps its 7px 8px, exactly as staging is built.
 *
 * DELETABLE WHEN: the duplicated padding is removed from the header template's Elementor data.
 * ------------------------------------------------------------------------- */
@media (min-width: 1025px) {
    .e-n-menu-content .elementor-widget-image-box.new-zycus-mega-community,
    .e-n-menu-content .new-zycus-mega-community.elementor-widget {
        padding: 0 !important;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-08-31 — Gravity Forms submit buttons collapsed to 107px
 * Was: mu-plugins/65-zycus-uael-gf-button-width.php. Moved here 2026-09-02.
 *
 * UAEL styles the GF submit with `.uael-gf-button-justify .gform_footer input[type=submit]`,
 * which only matches an <input>. Current Gravity Forms renders a <button>, so the rule misses:
 * measured 394x53 on staging vs 107x53 on staging2 at 1440px.
 *
 * The UAEL blocks below are now belt-and-braces: mu-plugin 73 converts the submit back to
 * <input> inside `uael-gf-styler` widgets, so UAEL's own CSS applies there again. They are kept
 * because 73 is deliberately scoped to that widget only.
 *
 * The `.zycus-form` block is NOT redundant and must stay: /schedule-a-demo renders
 * `<button class="gform_button">` with no <input> at all and is not a uael-gf-styler widget, so
 * 73 never touches it. Measured there 2026-09-02: 388x51, bg rgb(0,61,165), radius 8px, pad 16px.
 *
 * No !important, matching the original: this only has to beat the element default, and an
 * editor's per-widget width should still win.
 *
 * DELETABLE WHEN: Gravity Forms renders <input> again, or UAEL ships selectors that match
 * <button> (UAEL 1.45.2+).
 * ------------------------------------------------------------------------- */
.uael-gf-button-justify .gform_footer button[type="submit"],
.uael-gf-button-justify .gform_footer button.gform_button,
.uael-gf-button-justify .gform_page .gform_page_footer button[type="submit"],
.uael-gf-button-justify .gform_page .gform_page_footer button.gform_button {
    justify-content: center;
    width: 100%;
}
.uael-gf-button-center .gform_footer button[type="submit"],
.uael-gf-button-center .gform_footer button.gform_button,
.uael-gf-button-center .gform_page .gform_page_footer button[type="submit"],
.uael-gf-button-center .gform_page .gform_page_footer button.gform_button {
    display: flex;
    width: auto;
}
.zycus-form button.gform_button {
    width: 100%;
    background: var(--navy);
    color: #fff;
    font-family: var(--display);
    font-weight: 700;
    font-size: 1rem;
    padding: 16px;
    border: 0;
    border-radius: 8px;
    cursor: pointer;
    transition: background .15s ease, transform .15s ease;
}
.zycus-form button.gform_button:hover {
    background: var(--navy-deep);
    transform: translateY(-1px);
}
.zycus-form button.gform_button:disabled {
    opacity: .65;
    cursor: wait;
    transform: none;
}


/* ---------------------------------------------------------------------------
 * 2026-08-23 — AI World Tour campaign form fields stack centred
 * Was: mu-plugins/52-zycus-belgium-gf-fields-column.php. Moved here 2026-09-02.
 *
 * Safe in a sitewide stylesheet because every selector is pinned to an `.elementor-<post id>`
 * class, so it cannot match outside posts 273039 (Belgium) and 268589 (Turkey). That pinning is
 * deliberate: an earlier version targeted the bare field class `.mrelin-input` and restyled the
 * demo forms across the whole site (homepage x5, /solution/e-invoicing x6,
 * /merlin-experience-center x5). Do not loosen these selectors.
 *
 * No media query, on request: "mobile and above" = every width. No !important: these selectors
 * already beat UAEL's own `.uael-gf-style .gform_wrapper .gfield`.
 *
 * ⚠️ Element id 207e042 also exists on 258287 (Stockholm), 261013 (Paris), 261074 (Amsterdam)
 * and 273030 (South Africa) — those are deliberately NOT targeted. Add the post id if wanted.
 *
 * DELETABLE WHEN: the campaign template sets the column layout in Elementor itself.
 * ------------------------------------------------------------------------- */
/* 2026-09-03: wrapped in a mobile media query. Unscoped it also applied at 1440px,
   where display:flex on .gfield made the field row resolve 406px against staging's
   314px and pushed the submit 46px right (staging renders .gfield display:block
   there). The stacking this block provides is a mobile behaviour. */
@media (max-width: 768px) {
.elementor-273039 .elementor-element.elementor-element-63f81f7 .uael-gf-style .gform_wrapper li.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.elementor-273039 .elementor-element.elementor-element-63f81f7 .uael-gf-style .gform_wrapper div.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.elementor-273039 .elementor-element.elementor-element-63f81f7 .uael-gf-style .gform_wrapper .gf_progressbar_wrapper,
.elementor-273039 .elementor-element.elementor-element-63f81f7 .uael-gf-style .gform_wrapper fieldset.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.elementor-273039 .elementor-element.elementor-element-207e042 .uael-gf-style .gform_wrapper li.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.elementor-273039 .elementor-element.elementor-element-207e042 .uael-gf-style .gform_wrapper div.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.elementor-273039 .elementor-element.elementor-element-207e042 .uael-gf-style .gform_wrapper .gf_progressbar_wrapper,
.elementor-273039 .elementor-element.elementor-element-207e042 .uael-gf-style .gform_wrapper fieldset.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.parent-pageid-113092 .elementor-268589 .elementor-element.elementor-element-207e042 .uael-gf-style .gform_wrapper div.gfield:not(.gfield--type-hidden):not(.gform_hidden),
.parent-pageid-113092 .elementor-268589 .elementor-element.elementor-element-63f81f7 .uael-gf-style .gform_wrapper div.gfield:not(.gfield--type-hidden):not(.gform_hidden) {
    flex-direction: column;
    display: flex;
    align-items: center;
}
}



/* ---------------------------------------------------------------------------
 * 2026-09-02 — Solution thank-you: Download button in brand blue
 * Was: the <style> echoed from mu-plugins/47-zycus-solution-ty-empty-section.php.
 * ONLY the CSS moved. 47 still exists for its PHP half, which strips the
 * whitespace-only Elementor containers left behind after the Download button.
 *
 * The old comment in 47 said it had to inject into the output buffer "because
 * another mu-plugin filters out <style> tags added on wp_head". A properly
 * enqueued stylesheet is not subject to that filter at all, which is the whole
 * reason this belongs in a file rather than in PHP.
 *
 * MEASURED 2026-09-02 on /solution/esourcing-datasheet-thank-you:
 *     computed background-color rgb(0, 54, 176)  = #0036B0
 * !important is kept: Elementor sets the button colour per widget, and that
 * per-widget rule (0,4,0) would otherwise win from a stylesheet at position 9.
 *
 * DELETABLE WHEN: the thank-you template styles its own download button.
 * ------------------------------------------------------------------------- */
.single-solutions a.elementor-button[href$=".pdf"],
.single-solutions a.elementor-button[href$=".PDF"] {
    background-color: #0036B0 !important;
    border-color: #0036B0 !important;
    border-style: solid !important;
    color: #fff !important;
    fill: #fff !important;
}

.single-solutions a.elementor-button[href$=".pdf"]:hover,
.single-solutions a.elementor-button[href$=".PDF"]:hover {
    background-color: #0035af !important;
    border-color: #0035af !important;
    color: #fff !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Solution hero: keep the breadcrumb clear of the floating header
 * Was: mu-plugins/48-zycus-solution-breadcrumb-offset.php — file DELETED, this
 * is the whole of it. That plugin opened an output buffer on EVERY solution
 * page (template_redirect priority 8) purely to inject these three rules, so
 * moving them here also removes an ob_start from 274 solution pages.
 *
 * Elementor drives this hero's padding through the --padding-top custom
 * property, so we raise that rather than fight the .e-con rule that consumes
 * it. max() means a hero authored with more room keeps it — this only ever
 * adds clearance, never reduces it.
 *
 * MEASURED 2026-09-02 on /solution/procurement-orchestration:
 *     computed padding-top 90px, --padding-top = max(90px,0px)
 * 39 of 274 solution posts actually carry #solution_banner.
 *
 * DELETABLE WHEN: the hero is authored with its own padding-top and the
 * floating header no longer overlaps the breadcrumb.
 * ------------------------------------------------------------------------- */
.single-solutions #solution_banner {
    --padding-top: max(90px, var(--sb-authored-pt, 0px)) !important;
}

@media (max-width: 1024px) {
    .single-solutions #solution_banner {
        --padding-top: max(70px, var(--sb-authored-pt, 0px)) !important;
    }
}

@media (max-width: 767px) {
    .single-solutions #solution_banner {
        --padding-top: max(56px, var(--sb-authored-pt, 0px)) !important;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — AI World Tour speaker cards: .profile-header layout
 * Was: mu-plugins/63-zycus-profile-header-layout.php — file DELETED.
 *
 * THE DEFECT (client sheet: "'Meet your speakers' box height not equal")
 *   staging loads embedpress.css, which carries an *Instagram* profile-widget
 *   rule. ElementsKit's team widget happens to reuse the same class name, so on
 *   staging the speaker cards pick that padding up by accident. staging2 has no
 *   EmbedPress plugin (see mu-plugin 41 for the video side of the same gap), so
 *   the cards came out unequal — 484/484/494 vs staging's uniform 517.
 *   The declarations below are copied from staging's embedpress.css verbatim,
 *   so this reproduces staging rather than inventing a layout, and it is
 *   deliberately global because on staging the rule IS global.
 *
 * 🚨 WHY THE SELECTOR IS NOT THE ONE THE MU-PLUGIN USED
 *   ElementsKit ships this EXACT selector pair in widget-styles.css:
 *       .ekit-wid-con .profile-header, body .profile-header
 *           { display:inline-block; margin-bottom:38px; overflow:hidden; ... }
 *   The mu-plugin used the identical pair and only won because it printed at
 *   wp_head 998 — i.e. after every enqueued sheet. MEASURED in the page source:
 *   zx-overrides.css is stylesheet 9, ElementsKit's widget-styles.css is 28, so
 *   from here the identical selector would LOSE and display would fall back to
 *   inline-block, breaking the cards. Each half is therefore raised by exactly
 *   one element — (0,2,1) and (0,1,2) — which beats ElementsKit's (0,2,0) and
 *   (0,1,1) no matter what order the sheets load in, while staying safely below
 *   Elementor's per-widget rules (0,4,0). That last part matters: an editor's
 *   own border/margin controls must keep winning, and today they do — computed
 *   border-bottom-width is 0px and margin-bottom 0px on these cards even though
 *   both this rule and ElementsKit ask otherwise.
 *   !important is deliberately NOT used, for the same reason.
 *
 * MEASURED 2026-09-02 at 1440px, /campaigns/ai-world-tour-2026-dublin-edition:
 *     display flex, column, gap 30px, padding 16px 16px 30px
 *     header boxes 334x314 ×3, card heights 509/509/509
 *   and .../ai-world-tour-2026-belgium-edition:
 *     boxes 263x251 ×3 + 263x246, card heights 450/450/450/449
 *
 * DELETABLE WHEN: the speaker cards are rebuilt with their own layout, or
 * EmbedPress is installed on staging2.
 * ------------------------------------------------------------------------- */
body .ekit-wid-con .profile-header,
html body .profile-header {
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 30px;
    padding: 16px 16px 30px;
    border-bottom: 1px solid #ddd;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — AI World Tour speaker cards: rounded top corners
 * Was: mu-plugins/50-zycus-profile-header-radius.php — file DELETED.
 *
 * REQUESTED 2026-08-22:
 *     .ekit-wid-con .profile-header, body .profile-header
 *         { border-radius: 16px 16px 0 0; }
 *
 * Kept as a block of its own, immediately AFTER the layout block above, because
 * the two mu-plugins were ordered 998 (layout) then 999 (radius) on purpose.
 * They set disjoint properties so order cannot actually matter here, but the
 * documented intent is preserved rather than silently merged.
 * Selector raised the same way and for the same reason as the block above.
 *
 * MEASURED 2026-09-02: computed border-radius 16px 16px 0px 0px on Dublin and
 * Belgium. ElementsKit already sets overflow:hidden on this element, so the
 * image is clipped to the radius.
 *
 * DELETABLE WHEN: the card radius is set from the Elementor widget's own
 * border-radius control.
 * ------------------------------------------------------------------------- */
body .ekit-wid-con .profile-header,
html body .profile-header {
    border-radius: 16px 16px 0 0;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Homepage: LATAM blurb alignment + newsletter submit inside the pill
 * Was: mu-plugins/49-zycus-home-latam-align.php — file DELETED. That plugin opened
 * an output buffer on template_redirect just to inject these rules.
 *
 * 🚨 WHY EVERY SELECTOR IS PREFIXED :where(body.home) AND NOT body.home
 * The plugin gated on is_front_page(). The second rule targets element 0cbf4d3,
 * which lives in ElementsKit FOOTER template 174884 (and six other footer
 * templates) — i.e. it RENDERS ON EVERY PAGE. Dropped into a sitewide stylesheet
 * unprefixed, it would tuck the newsletter Submit inside the input pill across the
 * whole site, not just the homepage.
 *
 * A plain `body.home` prefix ADDS specificity, and the first A/B proved that
 * changes rendering: the footer rule measured
 *     before  position absolute, bottom 2px,  right 9px
 *     after   position absolute, bottom 24px, right 25px
 * — i.e. this rule is currently OVERRIDDEN by something more specific and has been
 * doing nothing; the extra element from `body.home` was enough to make it start
 * winning. `:where()` contributes ZERO specificity, so the scope is applied without
 * touching the cascade and the measured result is unchanged.
 *
 * ⚠️ NOTE FOR LATER (not changed here — this is a refactor, not a fix): the
 * newsletter-footer rule is inert. If the Submit really should sit at 24/25 inside
 * the pill, that is a separate decision and needs the overriding rule found first.
 *
 * e651d33 = the LATAM text widget; it must match the Fortune-500 block beside it.
 * Element ids are not unique across the four homepage variants (249372 current,
 * plus the fr/de translations and 272178), which is another reason to scope by
 * body class rather than trust the id alone.
 *
 * DELETABLE WHEN: the homepage widget is authored left-aligned and the footer form
 * positions its own submit.
 * ------------------------------------------------------------------------- */
/* 2026-09-03: restricted to >=768px. The rule's own goal is "match the Fortune-500
 * block beside it" (e556929) - but that block is text-align:center below 768px
 * (Elementor align_mobile), so forcing left here made the two boxes DISAGREE on
 * phones, which is what was reported. Live has no override at all here. Desktop
 * intent is unchanged. */
@media (min-width: 768px) {
    :where(body.home) .elementor-element-e651d33 {
        text-align: left !important;
        margin-left: 0 !important;
        margin-right: 0 !important;
    }

    :where(body.home) .elementor-element-e651d33 .elementor-widget-container,
    :where(body.home) .elementor-element-e651d33 p,
    :where(body.home) .elementor-element-e651d33 div {
        text-align: left !important;
    }
}

:where(body.home) .elementor-174884 .elementor-element.elementor-element-0cbf4d3 .gform_wrapper.gravity-theme .gform_footer {
    position: absolute;
    bottom: 24px;
    right: 25px;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Mobile tweaks
 * Was: mu-plugins/50-zycus-mobile-tweaks.php — file DELETED. It was already
 * sitewide with no page gate, and every declaration carries !important, so the
 * move is order-independent.
 *
 * 1. video facade play button hidden under 600px
 * 2. #meetAI ElementsKit tab row tightened under 768px
 * 3. demo-request email field full width under 545px
 * ------------------------------------------------------------------------- */
@media (max-width: 600px) {
    .fzv-pl { display: none !important; }
}

@media (max-width: 767px) {
    #meetAI .elementkit-tab-wraper .elementkit-nav-link {
        padding-top: 6px !important;
        padding-bottom: 6px !important;
        min-height: 0 !important;
        height: auto !important;
        line-height: 1.25 !important;
    }
    #meetAI .elementkit-tab-wraper .elementkit-nav-link * {
        margin-top: 0 !important;
        margin-bottom: 0 !important;
        line-height: 1.25 !important;
    }
    #meetAI .elementkit-tab-wraper .elementkit-tab-nav,
    #meetAI .elementkit-tab-wraper ul.elementkit-tab-nav {
        margin-bottom: 6px !important;
        padding-bottom: 0 !important;
    }
    #meetAI .elementkit-tab-wraper .elementkit-tab-content,
    #meetAI .elementkit-tab-wraper .elementkit-tab-content-wrapper {
        padding-top: 6px !important;
        margin-top: 0 !important;
    }
}

/*
 * 🚨 `body` prefix on the input, for the same reason as the block above but the other
 * way round. This rule was WINNING from wp_head; from stylesheet #9 it lost. MEASURED
 * on /solution/source-to-pay at 544px (the page that actually carries form 342 —
 * /schedule-a-demo does not):
 *     mu-plugin present  max-width 100%,  margin-right 20px,  box 517x56
 *     first move, plain  max-width 170px, margin-right -60px, box 320x56   << WRONG
 * The competing rule is also !important, so !important alone cannot settle it — only
 * specificity can. `body input#input_342_16` is (1,0,2) and wins wherever it loads.
 */
@media (max-width: 544px) {
    body input#input_342_16 {
        max-width: 100% !important;
        margin-right: 20px;
    }
    .gform_wrapper.gravity-theme .gfield.gfield--width-full { max-width: 100% !important; }
}










/* ---------------------------------------------------------------------------
 * 2026-09-02 — ElementsKit tab icon must be display:block
 * Was: mu-plugins/67-zycus-ekit-tab-icon-display.php — file DELETED.
 *
 * On staging the tab-nav icon computes to display:block; on staging2 it computes
 * to inline, and because .ekit-icon-image inherits line-height:142.857px an inline
 * image generates a 143px line box. That inflated every Merlin tab item:
 *     1440/1600px  li 100px -> 143px  (+43px x 3 tabs)
 *      768px       li  70px -> 143px
 *      390px       li  46px -> 137px
 * — the "reduce space between left side tabs" report (row 46), the tab
 * responsiveness complaint (row 28) and part of row 9. The stylesheet RULES are
 * identical on both sides; only the computed value differs, so this restores a
 * value rather than changing a design.
 *
 * Safe to move at (0,4,1): grepped elementskit-lite and elementskit — NOTHING in
 * either plugin's CSS sets display on .ekit-icon-image, the class appears only in
 * tab.php / advanced-tab.php. The inline is just the <img> default, so there is no
 * competing rule for load order to decide.
 *
 * DELETABLE WHEN: the tab widget's own CSS sets display on the icon image.
 * ------------------------------------------------------------------------- */
.ekit-wid-con .elementkit-tab-nav .elementkit-nav-item .ekit-icon-image img {
    display: block;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Animated-headline font-size parity
 * Was: mu-plugins/68-zycus-headline-specificity.php — file DELETED.
 *
 * Both environments load the SAME widget-animated-headline.min.css v4.2.0 with
 *     .elementor-headline { font-size: 43px }            (0,1,0)
 * but Astra's generated dynamic CSS differs:
 *     staging   .entry-content :where(h2), h2 {2.2em}   :where() => (0,1,0), ties
 *     staging2  .entry-content h2,         h2 {2.2em}              => (0,1,1), BEATS it
 * so inside .entry-content every animated headline collapsed to 2.2em x 16px =
 * 35.2px instead of 43px. Measured on /solution/strategic-sourcing-suite: "MORE"
 * and "PROFITABILITY DATA INSIGHTS CONTROL" were 43px on staging, 35.2px on
 * staging2, identical ancestor chains, both inside .entry-content.
 *
 * (0,2,1) out-specifies Astra while staying below Elementor's per-widget rule
 * .elementor-<page> .elementor-element-<id> .elementor-headline (0,3,0), which must
 * keep winning — that is exactly the staging cascade. Being specificity-decided
 * rather than order-decided, the move out of wp_head 99 is safe.
 *
 * DELETABLE WHEN: Astra emits :where() again, or the headlines carry explicit sizes.
 * ------------------------------------------------------------------------- */
.entry-content h1.elementor-headline,
.entry-content h2.elementor-headline,
.entry-content h3.elementor-headline {
    font-size: 43px;
    line-height: 1.2;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Leadership Team: 200px top padding above 1600px
 * Was: mu-plugins/41-zycus-leadership-1600-padding.php — file DELETED.
 *
 * uploads/elementor/css/post-174768.css defines element 39d3110 at four breakpoints:
 *     (base)                    --padding-top 20px    --padding-bottom 30px
 *     @media (max-width:1024px) --padding-top 100px
 *     @media (max-width:767px)  --padding-top 78px
 *     @media (min-width:1600px) --padding-top 200px   --padding-bottom 200px
 * so at >=1600px the block took 200px where every other breakpoint uses 20-100px.
 * It went unfound for a while because the page was being measured at 1440, below
 * the breakpoint, where the layout is already correct.
 *
 * Two details that must survive the move:
 *   1. It sets the CUSTOM PROPERTY, not padding-top. Elementor's .e-con rule
 *      resolves padding from var(--padding-top) and loads after the child theme, so
 *      a plain padding-top at equal specificity would be overridden.
 *   2. The `body` prefix is what makes it beat Elementor's own selector, so the
 *      result does not depend on stylesheet order — which is exactly why it is safe
 *      to move from stylesheet position 1 to position 9.
 *
 * MEASURED 2026-09-02 on /company/leadership-team:
 *     @1600  padding-top 20px, padding-bottom 200px   (the fix working)
 *     @1440  padding-top 20px, padding-bottom  30px   (base, untouched)
 *
 * NOT CHANGED: --padding-bottom is still 200px at this breakpoint. Only padding-top
 * was requested, and the bottom value may be intentional — flagged, not assumed.
 * DELETABLE WHEN: post-174768.css is re-authored with a sane 1600px padding-top.
 * ------------------------------------------------------------------------- */
@media (min-width: 1600px) {
    body .elementor-174768 .elementor-element.elementor-element-39d3110 {
        --padding-top: 20px;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — AI World Tour Turkey: undo the page's own body{display:flex}
 * Was: mu-plugins/64-zycus-turkey-body-display.php — file DELETED.
 *
 * THE DEFECT (client sheet: "Form design issue")
 *   Measured at 390x844:
 *     staging   body display block  overflow   0px  form gform_502 374x126 @x=8
 *     staging2  body display FLEX   overflow 212px  form gform_502 249x128 @x=346
 *   Desktop 1440 also overflowed by 55px on staging2, 0 on staging.
 *
 * WHY  The page's embedded markup ships `body{...display:flex;align-items:center;...}`.
 * Both environments have it; staging neutralises it with an inline
 * `html,body{display:block!important}` guard that staging2 lacks, so <body> really
 * becomes a flex container, the Elementor root shrinks from 390px to its content
 * width and is pushed off to the right, taking both Gravity Forms with it.
 *
 * SAFE TO MOVE even though the page carries inline <style> after </head>: the page's
 * own rule is plain `body{display:flex}` (0,0,1) with NO !important, while this is
 * (0,1,1) WITH !important — so it wins on the cascade, not on load order.
 *
 * Deliberately narrower than staging's unscoped guard: limited to the one page that
 * carries the offending rule. Only `display` is restored; the page's background and
 * font from that same rule are left alone, exactly as staging leaves them.
 *
 * MEASURED 2026-09-02 @390: body display block, horizontal overflow 0px,
 * #gform_wrapper_502 374x128.
 * DELETABLE WHEN: the Turkey template stops setting display:flex on body.
 * ------------------------------------------------------------------------- */
body.page-id-268589 {
    display: block !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Elementor Kit 24369: h2 uppercase (live parity)
 * Was: mu-plugins/53-zycus-kit-h2-uppercase.php — file DELETED.
 *
 * Live emits, from Kit 24369 global typography:
 *     .elementor-kit-24369 h2 { text-transform: uppercase; }
 * staging2 uses the same kit id but its kit data does not carry that setting, so
 * every h2 rendered title-case here and uppercase on live. A full diff of kit 24369
 * on 2026-08-27 showed exactly ONE difference between the two sites — this rule —
 * and a sweep of all 55 uppercase rules on a sample page confirmed nothing else can
 * match those headings. Verified not to be a CSS-trim artifact: still absent at
 * origin with ?zx_fullcss=1.
 *
 * 🚨 THIS RULE IS SITEWIDE AND HAS NO !important, AND THE MOVE MAKES IT LATER
 * As a mu-plugin it printed at stylesheet position 1 (wp_add_inline_style on
 * astra-theme-css); here it is position 9, ahead of Astra's dynamic CSS and five
 * child-theme sheets. At equal specificity that flips the winner. MEASURED before
 * the move, so any flip is detectable rather than theoretical:
 *     /                        21 h2 -> uppercase 12, capitalize 7, none 2
 *     /company/leadership-team 15 h2 -> uppercase 15
 *     /solution/e-invoicing    34 h2 -> uppercase 34
 *     /blog                    26 h2 -> uppercase 26
 *     .../turkey-edition       11 h2 -> uppercase  0   <-- this rule LOSES here today
 * The Turkey page is the canary: if the move made this rule start winning, its 11
 * headings would turn uppercase. The A/B in the rebuild log records the result.
 *
 * DELETABLE WHEN: kit 24369's typography on staging2 carries the uppercase setting,
 * at which point this becomes a duplicate of the kit's own rule.
 * ------------------------------------------------------------------------- */
.elementor-kit-24369 h2 {
    text-transform: uppercase;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Procure-Ace REGISTER form (35): white text on the dark panel
 * Was: mu-plugins/32-zycus-procure-ace-form.php — file DELETED.
 *
 * Form 35 sits on a #002971 navy panel. Two things were unreadable:
 *   consent line — field 42 is a checkbox, so the visible text is the
 *                  <label for="choice_35_42_1">, not the (empty) field label
 *   heading      — measured rgb(0,44,118) on rgb(0,41,113), a contrast ratio of
 *                  about 1.04:1, so it read as missing rather than as wrong
 *
 * Scoped to #gform_wrapper_35: there are four Procure-Ace forms (29, 31, 32, 35)
 * and only this one was asked for.
 *
 * ⚠️ Flagged, deliberately NOT changed: the required-field markers on that same
 * panel measure rgb(192,43,10) (#C02B0A), roughly 1.9:1 — also unreadable. It was
 * not requested, so the decision stays with the team.
 *
 * MEASURED 2026-09-02 on /procure-ace: consent rgb(255,255,255),
 * submit rgb(255,255,255), title rgb(255,255,255).
 * DELETABLE WHEN: the form is restyled for the dark panel at source.
 * ------------------------------------------------------------------------- */
#gform_wrapper_35 #field_35_42 label,
#gform_wrapper_35 #field_35_42 .gform-field-label,
#gform_wrapper_35 #field_35_42 .gchoice label,
#gform_wrapper_35 #field_35_42 legend,
#gform_wrapper_35 #field_35_42 .gfield_label {
    color: #fff !important;
}

#gform_wrapper_35 #field_35_42 a {
    color: #fff !important;
    text-decoration: underline;
}

#gform_wrapper_35 #gform_submit_button_35,
#gform_wrapper_35 .gform_footer input[type="submit"],
#gform_wrapper_35 .gform_footer button {
    color: #fff !important;
}

#gform_wrapper_35 .gform_title,
#gform_wrapper_35 h2.gform_title,
#gform_wrapper_35 .gform_heading .gform_title,
#gform_wrapper_35 .gform_description {
    color: #fff !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — "Meet Your Agentic AI": stack the vertical tab on phones
 * Was: mu-plugins/33-zycus-meetai-mobile.php — file DELETED.
 *
 * The section uses an ElementsKit tab in VERTICAL mode. Both
 *     .ekit-wid-con .elementkit-tab-wraper.vertical { display:flex }
 *     .elementor-249372 … .elementkit-tab-nav { flex-basis:45%; margin-right:27px }
 * apply at every width, so on a phone the nav kept 45% and the content was crushed
 * into the other half. Nothing in the existing responsive rules unstacks it.
 *
 * Two earlier attempts were visibly wrong and the third is what shipped:
 *   1.0.0  stacked it, but white-space:nowrap plus the theme's width:max-content made
 *          "Merlin Autonomous Negotiation Agent (ANA)" one long line overlapping the next tab
 *   1.1.0  allowed wrapping at 200px — no overlap, but the longest label broke onto four lines
 *   1.1.2  260px tab, 14px label, tight line-height — longest label on two lines
 *
 * MEASURED 2026-09-02 at 767px: wrapper display block, nav flex-basis 100% /
 * margin-right 0 / margin-bottom 20px / overflow-x auto / gap 12px, item 260x152,
 * link white-space normal / 14px / line-height 17.5px, content width 721px.
 *
 * 🚨 THE PADDING IS SPLIT ON PURPOSE — DO NOT PUT THE SHORTHAND BACK
 * This rule and the mobile-tweaks block earlier in this file (was mu-plugin 50) set
 * padding on the SAME selector at the SAME breakpoint. Today mu-plugin 33 prints at
 * stylesheet position 1 and 50 sits here at position 9, so 50 wins and the shipped
 * value is `6px 12px` — 6px top/bottom from 50, 12px sides from 33's shorthand.
 * The first attempt at this move carried `padding: 10px 12px !important` verbatim;
 * both blocks then lived in this file with 33 appended AFTER 50, so 33 started
 * winning. MEASURED, and the A/B rolled it back:
 *     A  padding 6px 12px   link 260x112  item 260x152  nav 721x156  wrapper 736x739
 *     B  padding 10px 12px  link 260x160  item 260x160  nav 721x164  wrapper 736x747
 * Rather than depend on block order inside one file, the conflict is removed: this
 * rule now sets ONLY the horizontal padding, and the vertical padding is left to the
 * mobile-tweaks block that already owns it. Same rendering, no ordering dependency.
 * (If the mobile-tweaks block is ever deleted, restore an explicit vertical padding
 * here — the widget default is not 10px.)
 *
 * Wholly inside max-width:767px and scoped to #meetAI, so desktop is untouched.
 * DELETABLE WHEN: the tab widget is given real responsive settings in Elementor.
 * ------------------------------------------------------------------------- */
@media (max-width: 767px) {
    #meetAI .elementkit-tab-wraper,
    #meetAI .elementkit-tab-wraper.vertical {
        display: block !important;
    }

    #meetAI .elementkit-tab-wraper.vertical > .elementkit-tab-nav,
    #meetAI ul.nav.nav-tabs.elementkit-tab-nav {
        flex-basis: 100% !important;
        width: 100% !important;
        max-width: 100% !important;
        margin-right: 0 !important;
        margin-bottom: 20px !important;
        display: flex !important;
        /* 2026-09-03: was row + overflow-x:auto, which showed ~1.3 tabs and made the
           short label look over-spaced next to the long one. Column stacks all three
           full width, so the 12px gap below is the ONLY space between them and is
           identical for every pair. Overlap - the reason the 260px basis existed -
           cannot happen once each tab owns its own line. */
        flex-direction: column !important;
        flex-wrap: nowrap !important;
        overflow-x: visible !important;
        overflow-y: visible !important;
        align-items: stretch !important;
        gap: 12px !important;
    }

    /* fixed-basis flex children, so two tabs can never overlap */
    #meetAI .elementkit-tab-wraper.vertical > .elementkit-tab-nav .elementkit-nav-item,
    #meetAI ul.nav.nav-tabs.elementkit-tab-nav .elementkit-nav-item {
        display: block !important;
        flex: 0 0 auto !important;
        width: 100% !important;
        max-width: 100% !important;
        margin: 0 !important;
    }

    #meetAI .elementkit-tab-wraper .elementkit-nav-link {
        white-space: normal !important;
        overflow-wrap: break-word !important;
        width: 100% !important;
        max-width: 100% !important;
        /* `height` is NOT set here — the mobile-tweaks block above owns it with
           height:auto, and that is what ships. Carrying this rule's original
           `height:100% !important` made the link fill the item: 260x112 -> 260x152.
           Same ordering conflict as the padding, same resolution. */
        display: flex !important;
        align-items: center !important;
        justify-content: flex-start !important;
        font-size: 14px !important;
        line-height: 1.25 !important;
        /* horizontal only — vertical padding is owned by the mobile-tweaks block above */
        padding-left: 12px !important;
        padding-right: 12px !important;
    }

    /* the icon must not steal width from the label */
    #meetAI .elementkit-tab-wraper .elementkit-nav-link .elementskit-tab-icon {
        flex: 0 0 auto !important;
        margin-right: 8px !important;
    }

    #meetAI .elementkit-tab-wraper > .elementkit-tab-content,
    #meetAI .elementkit-tab-wraper.vertical > .elementkit-tab-content,
    #meetAI .elementkit-tab-content {
        width: 100% !important;
        max-width: 100% !important;
        flex-basis: 100% !important;
        padding-left: 0 !important;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — /ai-council (page 125698): centre "Read Bio", hide the form slug
 * Was: mu-plugins/37-zycus-ai-council.php — file DELETED.
 *
 * The member buttons are UAEL dual-buttons, 26 on the page:
 *     .elementor-widget-uael-buttons > .elementor-widget-container
 *       > .uael-dual-button-outer-wrap > .uael-dual-button-wrap   <- display:flex
 *         > .uael-button-wrapper > a.elementor-button
 * UAEL only implements halign for its stacked variant, so `uael-button-stack-none`
 * inherits the flex default of flex-start and the button sat hard left. Centring
 * needs justify-content on the flex wrap — text-align cannot move a flex item.
 * Earlier attempts targeted `.elementor-widget-button` (matches 1 element, not a
 * member card) and `.elementor-button-wrapper` (matches 0).
 *
 * The form prints <h2 class="gform_title">Ai-council</h2> — the raw form slug —
 * directly beneath the real headings, so it is hidden.
 *
 * A third rule was REMOVED on 2026-08-28 and is deliberately not carried here: it
 * painted `.z_light_button` widget WRAPPERS #0036B0, matched exactly one element
 * (the "Become An AI Council Member" CTA) and produced a blue square behind the
 * button. staging2's own post-125698.css already styles that CTA correctly.
 *
 * MEASURED 2026-09-02 on /ai-council: dual-button-wrap justify-content center,
 * outer-wrap text-align center, 26 uael-buttons widgets.
 * DELETABLE WHEN: the cards are rebuilt, or UAEL implements halign for stack-none.
 * ------------------------------------------------------------------------- */
.elementor-125698 .elementor-widget-uael-buttons.z_light_button .uael-dual-button-wrap {
    justify-content: center !important;
}

.elementor-125698 .elementor-widget-uael-buttons.z_light_button .uael-dual-button-outer-wrap {
    text-align: center !important;
}

.elementor-125698 .gform_title {
    display: none !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — page spacing overrides
 * Was: mu-plugins/45-zycus-spacing-overrides.php — file DELETED.
 *
 * 1. /solution/procure-to-pay-software (208351) — a screen-height void below the
 *    section stack. Measured cause, #Platorm_covers on that page:
 *        element 58b93f7a   min-height 872px   margin-bottom 180px
 *    ⚠️ NOT caused by the TOC-as-tabs change (mu-plugin 44). Verified by measuring
 *    with that script active and inactive: docHeight 12980 both ways, identical
 *    visible slides, and on that page the TOC list never renders at all. The
 *    reservation is in the page's own Elementor settings.
 *    Elementor's custom properties are overridden as well as the plain declarations,
 *    because .e-con resolves its box from var(--min-height) / var(--margin-bottom).
 *    MEASURED 2026-09-02: min-height 0px, margin-bottom 0px.
 *
 * 2. Mega-menu hover highlight. Elementor's optimized-markup experiment is ACTIVE and
 *    drops the .elementor-widget-container wrapper (54 present vs 317 widgets), so the
 *    child theme's `.new-zycus-mega-community .elementor-widget-container:hover` rules
 *    stopped matching anything. Process still highlighted only because its rule targets
 *    the element itself. Re-pointed at the widget element, which now carries the class;
 *    values copied from leadership.css so the look is unchanged.
 *    MEASURED 2026-09-02 with the :hover state forced over CDP (the item lives inside a
 *    closed mega-menu, so a real hover cannot reach it): background rgb(1,51,165),
 *    image filter brightness(0) invert(1), title rgb(255,255,255).
 *
 *    NOT ADDED for the Products column, deliberately: leadership.css styles
 *    `.new-zycus-mega-product-li`, a class that appears ZERO times in the header
 *    template (EN 174880 and FR 271336 both), so those 6 rules never applied. Pointing
 *    them at `.new-zycus-products-conti .elementor-image-box-wrapper` was tried and
 *    reported back as wrong — it painted a light #EDF1F9 box over the blue. The Products
 *    items already carry .new-zycus-mega-community, so the rule below covers them.
 *
 * DELETABLE WHEN: (1) the page's Elementor settings are corrected; (2) the
 * optimized-markup experiment is turned off and the theme's own rules match again.
 * ------------------------------------------------------------------------- */
.elementor-208351 .elementor-element.elementor-element-58b93f7a {
    --min-height: 0px;
    min-height: 0 !important;
    --margin-bottom: 0px;
    margin-bottom: 0 !important;
}

.new-zycus-mega-community:hover { background-color: #0133A5 !important; }
.new-zycus-mega-community:hover img { filter: brightness(0) invert(1) !important; }

.new-zycus-mega-community:hover .elementor-image-box-title,
.new-zycus-mega-community:hover .elementor-image-box-description {
    color: #fff !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Homepage "Ready for Autonomous Procurement?" form: typed text white
 * Was: mu-plugins/74-zycus-css-fixes.php, entry `gf-typed-text-white` — file DELETED.
 *
 * The styling sets a transparent background, white border, white label and white
 * ::placeholder, but never a colour for the text the visitor TYPES — so it fell back
 * to the dark default and was invisible on the dark panel.
 *
 * ⚠️ Do NOT add `.uael-gf-style` to this selector. The same element id renders as a
 * `uael-gf-styler` widget on /en/ but as a plain `elementor-widget-shortcode` on /fr/
 * and /de/ — WPML swaps the widget type on the translations — so a uael-scoped rule
 * silently misses both. Keying on the element id + `.gform_wrapper` matches all three.
 * That is exactly how the first attempt at this fix failed.
 *
 * -webkit-text-fill-color is needed because Chrome's autofill overrides `color`.
 *
 * MEASURED 2026-09-02 on /: input and textarea colour rgb(255,255,255),
 * -webkit-text-fill-color rgb(255,255,255).
 * DELETABLE WHEN: the form's own styling sets an input colour.
 * ------------------------------------------------------------------------- */
.elementor-element-4639c87 .gform_wrapper input[type=text],
.elementor-element-4639c87 .gform_wrapper input[type=email],
.elementor-element-4639c87 .gform_wrapper input[type=tel],
.elementor-element-4639c87 .gform_wrapper input[type=url],
.elementor-element-4639c87 .gform_wrapper input[type=number],
.elementor-element-4639c87 .gform_wrapper textarea,
.elementor-element-4639c87 .gform_wrapper select {
    color: #FFFFFF;
    -webkit-text-fill-color: #FFFFFF;
}

.elementor-element-4639c87 .gform_wrapper input:-webkit-autofill,
.elementor-element-4639c87 .gform_wrapper input:-webkit-autofill:hover,
.elementor-element-4639c87 .gform_wrapper input:-webkit-autofill:focus {
    -webkit-text-fill-color: #FFFFFF;
    transition: background-color 9999s ease-in-out 0s;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — /events-upcoming-webinars carousel (1b12c4a): slide spacing
 * Was: mu-plugins/74-zycus-css-fixes.php, entry `events-carousel-slide-gap`.
 *
 * The 27px slide spacing lands on the flex wrapper's `gap` here, but on each slide's
 * `margin-right` on staging. Swiper measures slide width + margin when it builds its
 * transforms and ignores `gap`, so every slide after the first was 27px out.
 *
 * ⚠️ MEASURED STATE, carried deliberately: the `margin-right:27px` half APPLIES, the
 * `gap:0` half does NOT — computed on 2026-09-02 the wrapper still reports
 * gap/row-gap/column-gap 27px. Something more specific is setting it. This block
 * reproduces that exact state rather than "fixing" it, because a refactor must not
 * change rendering. If the carousel is still visibly out by 27px, the gap needs to be
 * beaten properly — that is a separate, deliberate change with its own measurement.
 * ------------------------------------------------------------------------- */
.elementor-element-1b12c4a .swiper-wrapper {
    gap: 0;
    row-gap: 0;
    column-gap: 0;
}

.elementor-element-1b12c4a .swiper-wrapper > .swiper-slide {
    margin-right: 27px;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — Solution TOC-as-tabs: the three script-applied classes
 * Was: the <style id="zx-toc-tabs-css"> in mu-plugins/44-zycus-solution-toc-tabs.php.
 * ONLY the CSS moved — 44 stays for its behaviour script, which is the whole feature.
 *
 * 🚨 EVERY SELECTOR HERE MATCHES A CLASS THAT 44'S OWN SCRIPT ADDS AT RUNTIME
 * (zx-toc-hidden, zx-toc-active, zx-toc-host). On a page where the script finds no
 * TOC/slide pairs and does nothing — the homepage, for instance — nothing carries
 * those classes and these rules match no element. That is the designed failure mode:
 * if the script never runs, every section stays visible and the page degrades to what
 * it does today, rather than to a page with its content missing. Hiding must never be
 * done by static CSS here.
 *
 * These rules were already in <head> (moved there from wp_footer on 2026-08-28 because,
 * printed at the end of <body>, the <style> arrived after first paint and forced a
 * re-layout of the whole document — measured repeatedly as the homepage's entire CLS,
 * 0.353, the largest Lighthouse penalty after LCP). Living in a stylesheet keeps that
 * property and removes one <style> from every page.
 *
 * The .zx-toc-host rule releases the container's reserved height while tabs are active:
 * measured on /solution/procure-to-pay-software, #Platorm_covers reserves min-height
 * 872px and margin-bottom 180px, which becomes an empty void with one section on screen.
 * The script removes the class when tabs are not active, restoring the reservation.
 *
 * MEASURED 2026-09-02 on /solution/intake-management: script reports
 * {"groups":3,"ready":true}, 4 elements hidden with display none, active TOC link
 * font-weight 700, host min-height 0px / margin-bottom 0px, only slide 0 visible.
 *
 * DELETABLE WHEN: 44 is deleted. These two must go together.
 * ------------------------------------------------------------------------- */
.zx-toc-hidden {
    display: none !important;
}

.elementor-toc__list-item.zx-toc-active > .elementor-toc__list-item-text-wrapper > a {
    font-weight: 700;
}

.zx-toc-host {
    min-height: 0 !important;
    margin-bottom: 0 !important;
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — 0-10 feedback slider on the two standalone thank-you pages
 * Was: the <style id="zx-tyslider-css"> printed at wp_head 999 from
 * mu-plugins/46-zycus-ty-slider.php. ONLY the CSS moved — that file keeps the
 * body_class() that adds `zx-tyslider` and the script that BUILDS this markup.
 * Delete them together or not at all.
 *
 * SCOPE IS SAFE IN A SITEWIDE SHEET: every selector starts at `.zx-tyslider`,
 * a body class 46 adds only on pages 267287 (/zycus-thank-you) and 62001
 * (/request-a-demo-thank-you). Nothing here can reach another page.
 *
 * WHY IT IS NOT PART OF mu-plugin 16: 16 owns this design for view-kh pages,
 * but its `fkh-thankyou` body class also carries hero band, thank-you card,
 * trust strip and sidebar chrome — and 36-zycus-kh-empty-content keys off that
 * SAME class to hide `.elementor-widget-theme-post-content`, so tagging a normal
 * page with it would silently blank a widget. Hence a separate scope class
 * carrying only the slider. The inner fkh-* names are kept because the JS that
 * creates those nodes is shared. If 16's slider design changes, mirror it here.
 *
 * The !important on the range input is deliberate and load-order-independent:
 * UAEL styles GF inputs at (0,10,1) with padding and a height, and without it the
 * browser's default range track shows through as a grey line under the bar.
 *
 * MEASURED 2026-09-02 at 1440px on both pages (identical), and at 390px:
 *   2 slider fields, 22 ruler ticks, card 438x176 (mobile 338x233)
 *   card bg rgb(255,255,255), border 1px rgb(238,242,248), radius 14px,
 *   padding 20px 22px 18px 88px  (mobile 80px 16px 18px)
 *   icon ::before 50x50 radius 50% bg rgb(234,242,255); question 2 rgb(230,247,241)
 *   note display block / visible / static / 13.5px / rgb(90,107,140)
 *   .fkh-sld flex, gap 16px, margin-top 14px; range height 22px, bg transparent
 *   ruler 16px tall, li absolute 12.5px rgb(123,138,165)
 *   value bubble 52x46 radius 12px rgb(234,241,253)/rgb(17,73,168);
 *   question 2 rgb(231,246,239)/rgb(12,107,76)
 *
 * DELETABLE WHEN: mu-plugin 46 is deleted.
 * ------------------------------------------------------------------------- */
.zx-tyslider{--fkh-navy:#14337e;--fkh-blue:#1668dc;--fkh-cyan:#4fd3ea;--fkh-ink:#5a6b8c;
  --fkh-line:#e4eaf3;--fkh-soft:#f4f8fd;--fkh-green:#0fae76}

/* GF's grid can put the two questions side by side; the reference design stacks them */
.zx-tyslider .gform_wrapper .gfield.kh-slider{grid-column:1/-1;max-width:none}

.zx-tyslider .gfield.kh-slider{background:#fff;border:1px solid #eef2f8;border-radius:14px;
  padding:20px 22px 18px;position:relative;padding-left:88px;
  box-shadow:0 4px 16px rgba(20,51,126,.07)}
.zx-tyslider .gfield.kh-slider::before{content:"";position:absolute;left:22px;top:22px;width:50px;height:50px;
  border-radius:50%;background:#eaf2ff no-repeat center/24px 24px}
.zx-tyslider .gfield.fkh-sld-1::before{
  background-image:url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%231668dc' stroke-width='1.8' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M12 20s-7-4.6-7-9.4A3.9 3.9 0 0 1 12 8a3.9 3.9 0 0 1 7 2.6C19 15.4 12 20 12 20z'/%3E%3C/svg%3E")}
.zx-tyslider .gfield.fkh-sld-2::before{background-color:#e6f7f1;
  background-image:url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%230fae76' stroke-width='1.8' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M4 10v4h3l6 4V6L7 10z'/%3E%3Cpath d='M17 9.2a4 4 0 0 1 0 5.6'/%3E%3C/svg%3E")}
.zx-tyslider .gfield.kh-slider .gfield_label{display:block;font-size:16.5px;font-weight:700;
  color:var(--fkh-navy);margin:0 0 3px}
/* GF keeps the instruction div hidden until validation; the reference shows it as a sub-label */
.zx-tyslider .gfield.kh-slider .gfield_description,
.zx-tyslider .gfield.kh-slider .gfield_instruction{display:block!important;visibility:visible!important;
  position:static!important;width:auto!important;height:auto!important;clip:auto!important;
  font-size:13.5px;line-height:1.5;color:var(--fkh-ink);padding:0;margin:0;background:none;border:0}

.zx-tyslider .fkh-sld{display:flex;align-items:center;gap:16px;margin-top:14px}
.zx-tyslider .fkh-sld__track{flex:1 1 auto;position:relative;min-width:0}
/* The input BOX is only a hit area - it must paint nothing. UAEL styles GF inputs with a
   (0,10,1) selector (padding:12px 10px, height), so these need !important to win; otherwise
   the browser's default range track shows through as a thin grey line under our bar. */
.zx-tyslider .fkh-sld input[type=range]{-webkit-appearance:none!important;appearance:none!important;
  display:block;width:100%;height:22px!important;min-height:0!important;max-height:none!important;
  margin:0!important;padding:0!important;border:0!important;outline:0!important;
  background:transparent!important;background-image:none!important;box-shadow:none!important;
  cursor:pointer;line-height:normal}

/* the visible bar lives on the track pseudo-element: light-cyan -> blue fill, grey remainder */
.zx-tyslider .fkh-sld input[type=range]::-webkit-slider-runnable-track{height:8px;border:0;
  border-radius:8px;box-shadow:none;
  background:linear-gradient(90deg,#a5dcf6 0%,#1668dc var(--fkh-pct,60%),
              #e3e7ee var(--fkh-pct,60%),#e3e7ee 100%)}
.zx-tyslider .fkh-sld input[type=range]::-moz-range-track{height:8px;border:0;border-radius:8px;
  box-shadow:none;
  background:linear-gradient(90deg,#a5dcf6 0%,#1668dc var(--fkh-pct,60%),
              #e3e7ee var(--fkh-pct,60%),#e3e7ee 100%)}
.zx-tyslider .fkh-sld input[type=range]::-moz-range-progress{background:transparent;height:8px}

/* target thumb: blue outer ring, white body, solid blue centre dot */
.zx-tyslider .fkh-sld input[type=range]::-webkit-slider-thumb{-webkit-appearance:none;appearance:none;
  width:22px;height:22px;border-radius:50%;box-sizing:border-box;margin-top:-7px;cursor:pointer;
  border:2.5px solid var(--fkh-blue);
  background:#fff radial-gradient(circle at 50% 50%,var(--fkh-blue) 0 4.5px,transparent 4.5px);
  box-shadow:0 2px 6px rgba(20,51,126,.25)}
.zx-tyslider .fkh-sld input[type=range]::-moz-range-thumb{width:22px;height:22px;border-radius:50%;
  box-sizing:border-box;cursor:pointer;border:2.5px solid var(--fkh-blue);
  background:#fff radial-gradient(circle at 50% 50%,var(--fkh-blue) 0 4.5px,transparent 4.5px);
  box-shadow:0 2px 6px rgba(20,51,126,.25)}
.zx-tyslider .fkh-sld input[type=range]:focus-visible{outline:2px solid var(--fkh-blue);outline-offset:6px}

/* ruler sits BELOW the track in flow, so it can never overlap the bar */
.zx-tyslider .fkh-ruler{list-style:none;margin:10px 0 0;padding:0;position:relative;height:16px;width:100%}
.zx-tyslider .fkh-ruler li{position:absolute;top:0;font-size:12.5px;line-height:16px;font-weight:500;
  color:#7b8aa5;transform:translateX(-50%);white-space:nowrap}

/* value bubble takes the colour of its question's icon */
.zx-tyslider .fkh-sld__val{flex:0 0 auto;min-width:52px;height:46px;border-radius:12px;
  background:#eef3fb;color:var(--fkh-navy);font-weight:800;font-size:18px;
  display:flex;align-items:center;justify-content:center}
.zx-tyslider .fkh-sld-1 .fkh-sld__val{background:#eaf1fd;color:#1149a8}
.zx-tyslider .fkh-sld-2 .fkh-sld__val{background:#e7f6ef;color:#0c6b4c}

@media (max-width:767px){
  .zx-tyslider .gfield.kh-slider{padding:18px 16px;padding-top:80px}
  .zx-tyslider .gfield.kh-slider::before{left:16px;top:18px}
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — brand-landing nav CTA must not overflow on phones
 * Was: mu-plugins/58-zycus-navcta-overflow.php — file DELETED. It echoed this at
 * wp_footer priority 1, i.e. deep in the body, and that placement was the only
 * reason one of its declarations won.
 *
 * THE DEFECT
 *   The hand-coded landing template lays its header out as
 *       .zycus-ppc-landing .nav-in { display:flex; gap:16px; padding:12px 20px }
 *         a.logo    w=162  flex-shrink:0
 *         a.nav-cta white-space:nowrap, default min-width:auto
 *   At 375px the CTA has only 157px to live in (375 - 20 - 162 - 16 - 20), but
 *   `nowrap` plus the default `min-width:auto` means a flex item cannot shrink
 *   below its text, so the button measured 221px and pushed the document to
 *   scrollWidth 420 — a sideways scrollbar on every phone.
 *
 *   The reference site happens not to overflow only because its copy of this
 *   template resolves the CTA font to Times New Roman (a narrow serif, 174px)
 *   while staging2 resolves it to ui-sans-serif (221px). Neither is the brand
 *   font, so the reference is not "correct" here — it is one font substitution
 *   away from the same bug.
 *
 * 🚨 WHY `body ` IS ON THE SECOND SELECTOR AND NOT THE FIRST
 *   Measured in the served HTML of /campaigns/zycus-brand-landing:
 *       template inline <style>  byte 119,596   (in <head>)
 *       zx-overrides.css <link>  byte  32,148   -> WE LOAD FIRST
 *       old mu-plugin <style>    byte 166,287   (after </head>) -> it loaded LAST
 *   The template declares, at (0,2,0):
 *       .zycus-ppc-landing .nav-cta { white-space: nowrap }
 *   and declares flex-wrap, row-gap, min-width and text-align NOWHERE. So:
 *     - `.nav-in { flex-wrap; row-gap }` has no competitor at all — left at (0,1,0)
 *     - `min-width` and `text-align` have no competitor either
 *     - `white-space` was a (0,2,0) TIE that the mu-plugin won purely by being
 *       later in the document. From this sheet it would lose, `nowrap` would come
 *       back and the overflow with it.
 *   One element of extra specificity — (0,2,1) — settles it wherever the sheets
 *   land. `!important` is not used: it would also override any future per-page
 *   authoring, which is not wanted for a defensive rule like this.
 *
 * SCOPE: measured, `.nav-in` exists on /campaigns/zycus-brand-landing only.
 * /use-cases renders ZERO `.nav-in` elements (a grep of the HTML suggested 6, but
 * those were occurrences inside CSS text, not markup) and /procurement-future-fund
 * currently 404s.
 *
 * MEASURED 2026-09-02 on /campaigns/zycus-brand-landing:
 *   @375  nav-in flex/wrap/row-gap 16px, cta white-space normal, min-width 0px,
 *         text-align center, cta 221x39, horizontal overflow 0px
 *   @480  identical, overflow 0px
 *   @1440 nav-in nowrap, cta nowrap/auto/start — untouched above the breakpoint
 *
 * DELETABLE WHEN: the landing template gives the CTA a shrinkable width itself.
 * ------------------------------------------------------------------------- */
@media (max-width: 480px) {
    .nav-in {
        flex-wrap: wrap;
        row-gap: 10px;
    }

    body .nav-in .nav-cta {
        min-width: 0;
        white-space: normal;
        text-align: center;
    }
}


/* ---------------------------------------------------------------------------
 * 2026-09-02 — /knowledge-hub footer form: submit button sits centred, not left
 *
 * REPORTED: "footer submit button left align".
 *
 * MEASURED at 1600px, computed values, both hosts:
 *     staging   footer 670x93   button 107x53 at offset   0px from the footer's left
 *     staging2  footer 670x85   button 107x53 at offset 281px  (dead centre)
 *   `.gform_footer` is `display:flex; justify-content:center` on BOTH sites, so the
 *   declaration is not what differs. staging left-aligns only because its button is
 *   `<input type="submit">` and the theme's `.gform_footer input[type="submit"]` rule
 *   gives it `margin-right:auto`. staging2 runs Gravity Forms 3.0.2, which renders
 *   `<button type="submit">`, and an `input[...]` attribute selector cannot match a
 *   <button> — so the auto margin never applies and the flex container centres it.
 *   (Same root cause as the GF3 button-width block above; see the plugin-drift note.)
 *
 * FIX: align the footer itself rather than depending on which tag GF emits, so this
 * survives a Gravity Forms upgrade or downgrade in either direction.
 *
 * SCOPE: form 163 only — the /knowledge-hub footer form. Form 164 on the same page is
 * already correct (its footer is exactly button-width, so alignment cannot show).
 *
 * DELETABLE WHEN: Ultimate Elementor is upgraded to 1.45.2 and its GF Styler emits
 * `button[type="submit"]` rules, or the theme's footer rule is rewritten to match both tags.
 * ------------------------------------------------------------------------- */
#gform_wrapper_163 .gform_footer,
#gform_wrapper_163 .gform-footer {
    justify-content: flex-start;
}

/* ===== KH view-kh (fkh) responsive fixes - 2026-09-03 =====================================
   Measured on /knowledge-hub/view-kh/on-demand-webinar/agentic-ai-source-to-pay-live-showcase
   at 360 / 390 / 414 / 768 / 1024 / 1600 px. */

/* 1. DynTube embeds carry a hard height (--zx-h: 575px) at every width, so under 950px the
      video letterboxes inside a fixed-height box - 288x575 on a 390px phone, ~400px of it
      empty. Height follows the embed's own aspect ratio instead. The literal 950/575 comes
      first as the fallback for engines that cannot divide two lengths in calc(). */
.zx-ose-dyntube > iframe { height: auto; aspect-ratio: 950 / 575; }
.zx-ose-dyntube > iframe { aspect-ratio: calc(var(--zx-w) / var(--zx-h)); }

/* 2. Under 768px the fixed header ends at y=71 while the hero H1 started at y=58, so the
      first line rendered behind the header (elementFromPoint returned the header container,
      not the H1). 68px clears it by 17px. The addon sets this padding with !important. */
@media (max-width: 767px) {
	body.fkh-thankyou .fkh-hero { padding-top: 68px !important; }
}

/* 3. The GravityWP number field draws its own ruler and value output over the same input the
      addon upgrades to .fkh-sld, so every question showed two rows of 0-10 and two value
      chips - and on mobile the GravityWP row (199px) did not line up with the track (147px).
      Keep the addon's slider, drop the duplicate chrome. */
.fkh-thankyou .gwp_slider_container > ul.gwp_ruler,
.fkh-thankyou .ginput_container.gwp_slider > output { display: none; }
.fkh-thankyou .gwp_slider_container { width: 100%; }
/* ===== end KH view-kh responsive fixes ================================================== */


/* ---------------------------------------------------------------------------
 * 2026-09-03 — Header language switcher: rows 6px shorter than live
 *
 * MEASURED at 1600px, live zycus.com vs staging2, both renders vouched for by the rig:
 *     row (li)     live 170x42   ·  s2 170x36
 *     line-height  live 25.6px   ·  s2 normal      <-- the whole difference
 *     dropdown     live 200x320  ·  s2 200x272     (6 rows x 6px = 36px, plus list margins)
 *     font-size / colour / padding already match once measured on the element that
 *     carries them (17px, rgb(16,16,16), 8px 12px)
 *
 * The two sites render this switcher with DIFFERENT markup: live puts the text straight in
 * the <li>, staging2 wraps it in an <a> and adds ARIA attributes (a newer WPML build). So
 * the rule targets the anchor, which is what carries the padding on staging2, and restores
 * live's line box.
 *
 * NOT "fixed", deliberately: `.mega-menu-lang-i` computes 20px wide on live and 70px here.
 * Measured inside it, the button (70x38), the svg (20x20) and the "EN" label (18x13) are
 * IDENTICAL on both — live's container is simply narrower than its own content. Matching
 * that would copy a quirk, not a design.
 *
 * DELETABLE WHEN: the switcher markup is aligned between the two sites.
 * ------------------------------------------------------------------------- */
.mega-lang-dropdown-sec li > a {
    line-height: 25.6px;
}

/* ----- view-kh video block: trim the nested padding on phones - 2026-09-03 -----------------
   Measured at 390px: the 174px video sat inside three stacked paddings - 18px on the post
   content widget, 10px on its e-con-inner, 50px on the inner e-con-inner - i.e. 178px of
   padding around a 174px video, block height 352px. Desktop (>=768px) is left alone. */
@media (max-width: 767px) {
	.fkh-thankyou .elementor-element-a9274ed { padding: 10px !important; }
	.fkh-thankyou .e-con-inner:has(.zx-ose-dyntube) {
		padding-top: 12px !important;
		padding-bottom: 12px !important;
	}
}
/* ----- end view-kh video block ----------------------------------------------------------- */

/* ----- view-kh sidebar + video width - 2026-09-03 ------------------------------------------
   1. Each post in the Recent Posts / Latest Knowledge Hub lists was separated by TWO rules
      11px apart: a dotted #ddd one (the widget's own) and a solid #eef2f8 li border-top.
      Pixel-verified at 1024: rows 193+204, 300+311, 426+437. Keep the dotted one.
   2. Latest Knowledge Hub items: .uc_post_list_box flips to flex-direction:column under
      768px, so the title dropped below the thumbnail. Desktop is row; keep row on phones.
   3. The video was only 304px wide of a 390px viewport because the post-content wrapper and
      its containers each add side padding. Zeroing them inside that wrapper only (never a
      shared ancestor - doing that stretched the sidebar cards to the viewport edge) gives
      344px, and with the aspect-ratio rule above the height follows: 184 -> 208px. */
.fkh-thankyou .ekit-post-list-wrapper > li.elementor-icon-list-item { border-top: 0 !important; }

@media (max-width: 767px) {
	.fkh-thankyou .uc_post_list_box { flex-direction: row !important; }

	.fkh-thankyou .elementor-element-a9274ed { padding: 10px 0 !important; }
	.fkh-thankyou .elementor-element-a9274ed .e-con,
	.fkh-thankyou .elementor-element-a9274ed .e-con-inner {
		padding-left: 0 !important;
		padding-right: 0 !important;
	}
}
/* ----- end view-kh sidebar + video width --------------------------------------------------- */


/* ---------------------------------------------------------------------------
 * 2026-09-03 — .rqstdemo email input: full width
 * The staging2-only .rqstdemo block in Customizer > Additional CSS was removed today;
 * staging has no such block and the same design comes from astra-child/style.min.css on
 * both hosts. Removing it fixed the input height (56px -> 41-48px) and made
 * /solution/source-to-pay, /solution/e-invoicing, /solution/supplier-management and the
 * eight AI World Tour pages match staging exactly.
 *
 * ONE declaration in it was load-bearing - width:100% on the input. A/B measured at
 * 1440px, three pages shrank without it:
 *     page                              with block   without    staging
 *     /home-new                         354x56       243x39     351x41
 *     /experience-merlin-intake…        277x56       243x39     274x41
 *     /campaigns/agentic-ai…benchmark   397x56       243x39     394x41
 * Restoring only the width, so the corrected height stays. Pages whose container is
 * already the input's width (the /solution set at 320px, the AWT set at 266px) are
 * unaffected - 100% of their container is the width they already had.
 *
 * DELETABLE WHEN: staging2's forms sit inside .uael-gf-style the way staging's do; that
 * wrapper is what sizes the container on staging.
 * ------------------------------------------------------------------------- */
.rqstdemo .gform_wrapper input[type="email"] {
    width: 100%;
}

/* Pinned to the three pages this was added for. Unpinned it also grew the AI World Tour
   field row - Turkey went to 406px against staging's 314px - because the body then fills
   whatever spare width the form has. */
.elementor-122948 .rqstdemo .gform_wrapper .gform-body,
.elementor-122948 .rqstdemo .gform_wrapper .gform_body,
.elementor-196603 .rqstdemo .gform_wrapper .gform-body,
.elementor-196603 .rqstdemo .gform_wrapper .gform_body,
.elementor-193808 .rqstdemo .gform_wrapper .gform-body,
.elementor-193808 .rqstdemo .gform_wrapper .gform_body {
    flex: 1 1 auto;
    min-width: 0;
}


/* ---------------------------------------------------------------------------
 * 2026-09-03 — "Refer a Colleague" form: fully rounded, every page
 * Requested explicitly: the bottom-of-page referral form's field and button should both
 * read as pills sitewide. That form is Gravity Forms 335 ("Campaign Referral Form"),
 * shared by all eight AI World Tour editions.
 *
 * NOTE: this is a design change, not staging parity - staging renders 20px here. 999px is
 * used instead of a fixed radius because the browser clamps it to half the height, so it
 * stays a true pill whatever the height resolves to (GF 3.0 renders <button>, which comes
 * out taller than the <input> GF 2.10.5 rendered).
 *
 * Scoped by form id, so no other form on the site is touched.
 * ------------------------------------------------------------------------- */
#gform_wrapper_335 input[type="email"],
#gform_wrapper_335 input[type="text"],
#gform_wrapper_335 textarea,
#gform_wrapper_335 select,
#gform_wrapper_335 .gform_footer input[type="submit"],
#gform_wrapper_335 .gform_footer button.gform_button,
#gform_wrapper_335 .gform_button,
#gform_submit_button_335,
button#gform_submit_button_335 {
    border-radius: 999px !important;
}

/* ----- WHAT SETS US AHEAD: stack the 3 columns on phones - 2026-09-03 -----------------------
   Two of the six solution pages carrying this block keep `flex-wrap: nowrap` at mobile, so the
   three cards stay side by side and squeeze to 105px wide / 436-494px tall at 390px:
       /solution/supplier-network    .elementor-element-4f2c964
       /solution/supplier-management .elementor-element-df633c9
   The four that render correctly (spend-analysis, contract-management, intake-management,
   source-to-pay) use `wrap` with full-width children - 374px wide, ~163px tall. This gives the
   two outliers the same behaviour. Desktop is untouched: measured identical at 1440px. */
@media (max-width: 767px) {
	.elementor-element-4f2c964,
	.elementor-element-df633c9 { flex-wrap: wrap !important; }

	.elementor-element-4f2c964 > .e-con,
	.elementor-element-df633c9 > .e-con { width: 100% !important; }
}
/* ----- end WHAT SETS US AHEAD ------------------------------------------------------------- */

/* 2026-09-03 — view-kh GWP slider squished on mobile (form 284px vs staging 348) */
@media (max-width: 767px) {
  body.fkh-thankyou .elementor-element.elementor-element-fa11ab7 {
    --padding-left: 12px; --padding-right: 12px;
    padding-left: 12px !important; padding-right: 12px !important;
  }
  body.fkh-thankyou .gform_wrapper .gfield--type-number {
    padding-left: 0 !important; padding-right: 0 !important;
  }
}

/* ----- campaign nav burger: 44px tap target - 2026-09-03 -----------------------------------
   Below 768px the campaign nav collapses to .e-n-menu-toggle, which renders as a bare 20x20
   icon - measured [711,33,20,20] at 744px (iPad Mini portrait) and [357,42,20,20] at 390px.
   That is under the 44x44 minimum tap target. This pads the hit area only; the icon itself
   stays 20x20 and the bar does not move. Verified: no overflow, no horizontal scroll, and
   768px+ is untouched (the toggle is display:none there). */
@media (max-width: 767px) {
	.e-n-menu-toggle {
		min-width: 44px !important;
		min-height: 44px !important;
		display: flex !important;
		align-items: center !important;
		justify-content: center !important;
	}
}
/* ----- end campaign nav burger ------------------------------------------------------------ */

/* 2026-09-03 — mega-menu icon sizes were inconsistent (12 distinct sizes vs staging's 6).
   Same 52x52 source file on both sites; the icons sit at max-width:100% so their size
   came from the parent cell, and some cells are narrower on staging2:
       Graph.png 4x4 · UsersThree-2 16x16 · Database 22x22   (staging: all ~25x25)
   Give the 52x52 icon set an explicit size instead of inheriting the cell.
   Scoped by the 52x52 attrs so the Integrations 25x23 icons and promo images are untouched. */
.e-n-menu-content img[width="52"][height="52"] {
  width: 25px !important;
  height: 25px !important;
  max-width: 25px !important;
  object-fit: contain;
}

/* ----- campaign nav dropdown: centre the rows - 2026-09-03 ---------------------------------
   In the collapsed (burger) nav every row is full width with justify-content:flex-end, so the
   labels and the Register Now pill were jammed against the right edge - measured at 744px
   (iPad Mini): row 744 wide, gap-left 616-683px, gap-right 9px. Same at 390px. Centring gives
   equal gaps (340/340, 319/319 at 744; 163/163, 142/142 at 390). Only applies while the menu is
   collapsed; at 768px+ the nav is a horizontal bar and this rule is out of scope. */
@media (max-width: 767px) {
	.e-n-menu-wrapper .e-n-menu-title { justify-content: center !important; }
}
/* ----- end campaign nav dropdown ----------------------------------------------------------- */

/* 2026-09-04 — Leadership team thumbnail rail height.
   This lived as element custom_css on container 02c3147 of the EN page ONLY. `_elementor_data`
   is WPML "copy once" (custom_fields_translation = 3), so /fr/ and /de/ never received it: the
   rail rendered at full content height (fr 1243px, de 1320px) instead of 582px, so it never
   scrolled and the sticky header covered the first row.
   Living in the shared stylesheet means every language gets it, permanently, regardless of WPML.
   It beats Elementor's `.e-con{height:var(--height)}` on SPECIFICITY (0,2,0 vs 0,1,0), not on
   source order, so moving it here is safe. */
.new-zycus-team-left-main .new-zycus-team-left-sec {
    height: 582px;
    overflow-y: scroll !important;
}

@media (max-width: 1599px) and (min-width: 1280px) {
    .new-zycus-team-left-main .new-zycus-team-left-sec {
        height: 445px;
    }
}

/* ------------------------------------------------------------------------
 * 2026-09-05 — mega-menu panel disappeared while moving title -> panel.
 *
 * The "Website Under Maintenance" strip (.elementor-element-7a5bf14, a prod2-only
 * container: position:absolute, inside the fixed #new_zycus_header) is painted across
 * y~137-187px, i.e. over the ~44px band between the menu title row (ends y~112) and the
 * top of the mega panel (starts y~156).
 *
 * The panel needs BOTH of these, from new_zycus_style.css:
 *     .e-n-menu-content { display:none }              + .e-active  -> display
 *     .e-n-menu:hover ... { visibility:visible }       nav :hover   -> visibility
 *
 * Crossing the strip takes the pointer off nav.e-n-menu, so `visibility` flips to hidden
 * INSTANTLY. The JS hover layer (zx-nav-hover) only manages `.e-active` / display and has
 * no say over `visibility`, which is why its 260ms close-delay could not compensate.
 *
 * The strip has zero interactive children (one text-editor widget), so it does not need
 * pointer events at all.
 * ------------------------------------------------------------------------ */
#new_zycus_header .elementor-element-7a5bf14 { pointer-events: none; }