/*
* Site-wide CSS, enqueued on every page (not gated to the standalone auth/dashboard pages
* the way auth.css/dashboard.css are) — kept in its own file so this stylesheet's scope
* stays obviously different at a glance from the page-scoped ones.
*
* ---------------------------------------------------------------------------------------
* Header "Get started" CTA (nav menu item id 21850, added during `add-marketing-site`
* §4.1's header fix).
*
* Corrected diagnosis (2026-07-30, verified against live computed styles): an earlier
* revision of this file assumed the theme's `.elementskit-btn` rules could never match a
* nav-menu item because they are scoped under `.elementor-widget … .ekit-wid-con`. That
* assumption was WRONG — the header nav *is* an ElementsKit nav-menu widget rendered
* inside the Elementor header template, so the full ancestor chain exists and the theme's
* ElementsKit compatibility layer
* (`keydesign-framework/includes/compatibility/elementskit/assets/css/keydesign-elementskit.css`)
* styles the `` completely on its own:
*
* .ekit-wid-con .elementskit-btn { ... } <- base pill ON THE
* .flip-button-effect … .elementskit-btn:after { ... } <- incoming hover label
* .flip-button-effect … .elementskit-btn:hover .button-wrapper <- outgoing label
*
* The old fix here re-declared that whole pill a second time on the inner ``, which
* produced a button *inside* a button: the theme's `` pill (18px 25px padding) wrapped
* our duplicate `` pill (12px 26px) — hence the oversized blob — and on hover the
* theme's `li::after` label slid in next to ours, showing the text twice.
*
* The fix now is the opposite: leave the pill and the flip animation entirely to the
* theme's own rules (so they track future theme token changes for free) and patch only
* what the theme cannot know about a nav-menu context:
*
* 1. the walker's `` must be a plain label, not a second pill / styled nav link;
* 2. the `` must not stretch to the 80px nav-row height
* (`.elementskit-menu-container{height:80px}`, post-104.css);
* 3. the theme's incoming `li::after` label (absolute, `top: 50%`) needs `left/right: 0`
* + centring in this context — in the theme's own buttons the static position of the
* pseudo-element lands on the label, but here it resolves against the full `` box;
* 4. the theme's `18px 25px` pill padding is tuned for an in-content CTA and crowds an
* 80px header row — 12px/26px matches the vendor demo's header button weight.
*
* The `.button-wrapper` span around the `` label (supplied by
* `DashboardController::wrap_header_cta_label()`) is still required: the theme's own
* flip rules target it directly for the outgoing half of the animation.
*/
/* ---------------------------------------------------------------------------------------
* CRITICAL: entry-animation failsafe (found 2026-07-30 during the §8 design audit).
*
* The bug: Elementor gives any widget with an entry animation the class
* `elementor-invisible`, whose only declaration is `visibility: hidden`. The element keeps
* its full layout height — it is invisible, not absent. Elementor's own frontend JS is
* supposed to remove that class when the widget scrolls into view, and on this stack it does
* not: `jQuery.fn.waypoint` is absent at runtime (asserted in the browser — Elementor's
* `frontend.min.js` loads, but the Waypoints binding it relies on never lands), so the class
* is never removed and the animation never fires.
*
* The impact was total, not cosmetic: on the home page **46 of 79 widgets** rendered with
* `visibility: hidden`, leaving ~5,000px of blank white space between the hero and the
* footer. Every marketing page was affected (home 46, features 12, contact 4, pricing 4,
* faq 3 — measured after a full programmatic scroll, so this is not "content that appears
* once you scroll"). Removing the class in the console restored 5,641 characters of real,
* finished, correctly-styled content that no visitor could see.
*
* Why the fix is CSS and not JS: a JS fix would depend on exactly the script-execution path
* that is already proven unreliable here, and would leave the content hidden for anyone on a
* slow connection until it ran. `visibility: visible` costs nothing, cannot fail, and needs
* no library. The trade-off is losing the fade-in flourish — content that is *reliably
* visible without animation* beats content that is *invisible with one*.
*
* Scoped to `.elementor-invisible` rather than blanket-overriding `visibility`, so it undoes
* exactly the one broken state and touches nothing else. `!important` is required: the
* Elementor rule it overrides carries the same specificity and loads from a stylesheet whose
* order relative to this one is not guaranteed.
*
* If Elementor's animation JS is ever repaired, this rule becomes a harmless no-op — the
* class is removed before it can match. Re-test before deleting it.
*/
.elementor-invisible {
visibility: visible !important;
}
/*
* `animated` without a running animation is the other half of the same failure: the theme's
* `animated-fast`/`animated-slow` helpers set `animation-fill-mode: both`, which holds an
* element at its keyframe-0 state (typically `opacity: 0`) when the animation never starts.
* Forcing full opacity for the same reason and with the same trade-off as above.
*/
.elementor-widget.elementor-invisible,
.elementor-invisible > .elementor-widget-container {
opacity: 1 !important;
}
/* ---------------------------------------------------------------------------------------
* Unresolved footer placeholders (found 2026-07-30 during the §8 design audit).
*
* The footer template ships five entries whose real values the Client has not supplied yet:
* four social profiles (`#PLACEHOLDER-x-url` and friends) and a support address, whose
* label renders as the literal string "[PLACEHOLDER: support contact email]" on **every
* page of the site**. Visitors currently see bracketed placeholder text in the footer and
* four social links that navigate nowhere.
*
* Hiding them is the correct interim state, not a workaround: an invisible entry is
* strictly better than a visibly-broken one, and unlike inventing a support address or
* guessing social URLs it makes no claim that could be wrong. The moment a real `href` is
* set in the footer template these selectors stop matching and the entries reappear on
* their own — the rule keys on the placeholder value itself, so it cannot outlive the
* problem it hides.
*
* `:has()` is used to hide the whole `` rather than just the ``, so no orphaned
* bullet or list gap is left behind.
*/
.elementor-icon-list-item:has(> a[href^="#PLACEHOLDER"]),
.elementor-icon-list-item > a[href^="#PLACEHOLDER"] {
display: none;
}
/* The "Get in touch" column's heading is left in place deliberately — it labels a column
that also carries the social icons block, which is styled separately and may still have
real entries. Only the placeholder rows themselves are suppressed. */
/* (2) don't stretch to the 80px nav row; padding now lives on the `` (below), not here —
the `` itself has no `href`, so if the pill's padding stayed on the `` the visible
button would be bigger than its own clickable area and clicks near the edges would land on
the `` background instead of the link. Everything else about the pill (background,
radius, hover colour, overflow, the flip animation) comes from the theme's own
`.elementskit-btn` rules. */
#menu-item-21850.elementskit-btn {
align-self: center;
display: inline-flex;
align-items: center;
height: auto;
padding: 0;
}
/* (1) the `` is the whole clickable pill, sized to match the theme's header-button
weight (12px 26px) instead of its in-content 18px 25px. Kill the nav-link chrome the
ElementsKit menu CSS puts on every `.ekit-menu-nav-link` (line-height sized to the nav
row, grey link colours on hover/focus). */
#menu-item-21850.elementskit-btn > .ekit-menu-nav-link {
display: inline-flex;
align-items: center;
justify-content: center;
padding: 12px 26px;
margin: 0;
height: auto;
line-height: 1.4;
background: none;
color: #fff;
font-family: var(--e-global-typography-accent-font-family, inherit);
font-size: var(--font-size-default, 14px);
font-weight: var(--e-global-typography-accent-font-weight, 600);
white-space: nowrap;
}
#menu-item-21850.elementskit-btn > .ekit-menu-nav-link:hover,
#menu-item-21850.elementskit-btn > .ekit-menu-nav-link:focus,
#menu-item-21850.elementskit-btn > .ekit-menu-nav-link:active {
background: none;
color: #fff;
}
/* (3) centre the theme's incoming flip label. The theme declares
`content: attr(data-text); position: absolute; top: 50%; transform: translate(0, 100%)`
(→ `translate(0, -50%)` + opacity 1 on hover) but leaves left/right at their static
position, which in this nav context resolves against the whole `` box instead of the
label. Only the horizontal placement is corrected here; content/position/timing stay the
theme's, so the animation keeps tracking any future theme changes. */
#menu-item-21850.elementskit-btn::after {
left: 0;
right: 0;
text-align: center;
}
/* Reduced-motion: suppress the flip (the duplicate label exists only to be animated) and
keep just the theme's colour change. The original label is forced to stay put because
the theme's `:hover .button-wrapper` rule would otherwise still slide it away. */
@media (prefers-reduced-motion: reduce) {
#menu-item-21850.elementskit-btn::after {
content: none;
}
#menu-item-21850.elementskit-btn:hover .button-wrapper {
transform: none;
opacity: 1;
}
}