/*
 * Kate Angelo — Site Recolor: flat navy → lighter royal-blue gradient (v1.2.0)
 * -----------------------------------------------------------------------------
 * FOUNDATIONAL round 1 of a 5-item batch. Items #2 (new Books landing page)
 * and #4 (Speaking page) will be built ON TOP of the exact values below —
 * treat this file as the source of truth for "the site's new dark base."
 *
 * v1.2.4 UPDATE: QA found this file only ever covered isolated hero/
 * showcase sections, leaving most of the site on either the old #020F24
 * navy or Astra's white default. See the "v1.2.4 — ROUND 2" block further
 * down for the base-unification, footer-retire, Signup, and Contact fixes
 * that complete this recolor. The About page's lower-section fix is in a
 * separate dedicated file (assets/about-lower-sections-fix.css) — see that
 * file's header for why.
 *
 * ── WHERE THE COLORS CAME FROM (sampled, not invented) ──────────────────────
 * Fetched the live home page (/) and About page (/about-2/) and inspected
 * their actual per-post Elementor stylesheets + the KBM home-landing.css that
 * drives the home page's animated "constellation" hero:
 *
 *   1. Home hero (.hero in home-landing.css, the literal "constellation"
 *      section Kate referenced):
 *        background: radial-gradient(ellipse 80% 70% at 50% 45%,
 *          #1a4a90 0%, #0d3170 50%, #08204d 100%);
 *   2. Home page's own flat design-token (`--bg` in home-landing.css :root,
 *      used everywhere else on the home page as the flat fallback):
 *        --bg: #0d3170;
 *   3. About page (/about-2/) "royal-blue" sections (elements kaab0003,
 *      kaabc021-024 in post-7778.css) — these are a FLAT solid fill, not a
 *      literal gradient:
 *        background-color: #0F3271;
 *      (#0F3271 is close enough to #0d3170 above to be the same family —
 *      treated as already-consistent, not reproduced as a third value.)
 *
 * DECISION: standardize sitewide on the home hero's own real 3-stop values,
 * reshaped as a vertical linear gradient (the hero uses a radial vignette,
 * which suits a single full-viewport moment; a linear version suits generic
 * stacked page sections better — direction is the only thing adapted, every
 * color is copied verbatim):
 *
 *   NEW BASE GRADIENT:  linear-gradient(180deg, #1a4a90 0%, #0d3170 50%, #08204d 100%)
 *   NEW BASE SOLID (fallback / repeated-section fill): #0d3170
 *
 * These replace the OLD flat navy `#020F24` wherever it was previously used
 * as a page/section BACKGROUND on brand pages. `#020F24` itself is NOT
 * deleted from the brand — see formidable-theme.css v1.2.0 notes, it is
 * reused as the new form-field fill (needs to be darker than the new,
 * lighter page now, whereas before it needed to be lighter — see that
 * file's change-log for the full reasoning).
 *
 * ── CONTRAST (WCAG) — verified via relative-luminance ratio, see report ────
 *   gold #F5D000  on #1a4a90 = 5.73:1   |  on #0d3170 = 8.23:1  |  on #08204d = 10.50:1
 *   white #EEF2F8 on #1a4a90 = 7.70:1   |  on #0d3170 = 11.06:1 |  on #08204d = 14.12:1
 * All combinations clear WCAG AA (4.5:1 body / 3:1 large-text) with real
 * margin; the lightest stop (#1a4a90) is the only one worth watching if the
 * gradient is ever pushed lighter still — by design it's used mostly at
 * gradient EDGES/decorative full-viewport moments (#kbm-intro splash, the
 * 404 stage) rather than as a flat solid text background.
 *
 * ── SCOPE — brand pages only, blog untouched ────────────────────────────────
 * Scoped to: the sitewide Elementor header's scrolled state, KBM book
 * landing pages (`body.single-book`), and the one dark section on
 * /fp-launch-team/ (page 7887). Every selector below is either scoped to a
 * `body.single-book` / `body.page-id-7887` ancestor or is a class that only
 * ever exists inside a Formidable/KBM/Elementor-header context. Nothing here
 * targets `.ka-blog-archive` or `body.single-post` (those stay light, per
 * their own v1.1.0 stylesheets, which remain untouched and keep winning on
 * their own higher-specificity selectors).
 *
 * Pages that do NOT get a body-section recolor here, and why:
 *   - Home page: ALREADY on this exact palette (home-landing.css is the
 *     SOURCE of these values) — zero-touch, confirmed live has no #020F24.
 *   - /about-2/: explicitly out of scope for this round (Step 2's page list
 *     doesn't include it) — it was only used as a sampling source.
 *   - /books/, /contact/, /press-kit/, /ai-interest-form/: verified live —
 *     none of these currently have a `#020F24` section of their own. They
 *     use Elementor's generic default-kit blue (/books/, /contact/,
 *     /press-kit/: `--e-global-color-fa09a94:#1E3D58` /
 *     `--e-global-color-60ee535:#057DCD`) or plain white — a separate,
 *     pre-existing, unrelated design leftover, not "the flat navy base"
 *     this task is recoloring. They still inherit the header/footer/
 *     form-field changes below since those are shared sitewide. Flagging
 *     this clearly for items #2/#4 to properly resolve when those pages are
 *     rebuilt.
 *
 * Enqueued sitewide (functions.php `ka_child_site_recolor_css`), immediately
 * after formidable-theme.css, on every front-end request — safe to load
 * everywhere because every rule is scoped by a real body/page class.
 *
 * v1.2.5 EXCEPTION TO THE ABOVE SCOPING RULE: the sitewide heading-font
 * override added at the bottom of this file (search "SITEWIDE TYPE
 * UNIFICATION") is deliberately NOT scoped to a body/page class — it
 * targets real heading tags everywhere, INCLUDING the blog. That is
 * intentional and matches this round's brief: the blog's LIGHT color
 * theme (background/text colors) stays completely untouched, but the same
 * Oswald heading FONT applies there too for sitewide consistency. Every
 * other rule in this file keeps the original page/body-class scoping
 * described above.
 */

/* ── HEADER — sticky / transparent / scroll-blur ─────────────────────────────
 * The header (Elementor template #7729, class `.ka-site-header`) ALREADY has
 * Elementor Pro's/pro-elements' NATIVE Sticky + "Effects Offset" feature
 * configured and working — confirmed live: `.elementor-sticky--active` and
 * `.elementor-sticky--effects` are toggled automatically by Elementor's own
 * bundled frontend.min.js (grep-verified `effectsOffset`/`elementor-sticky--
 * effects` strings inside pro-elements' frontend.min.js). NO custom scroll
 * JS was written or is needed — this is a pure CSS re-theme of states that
 * already exist and already toggle correctly:
 *
 *   .ka-site-header, .ka-site-header.elementor-sticky--active   → transparent
 *     (already true, works unchanged against ANY page background, old or
 *     new — nothing to touch here)
 *   .ka-site-header.elementor-sticky--effects                   → solidified
 *     (previously flat opaque #020F24 — recolored + blurred below)
 *
 * Both rules below are (0,0,3,0) specificity (via the leading `body`) vs the
 * existing header-template custom-CSS rule at (0,0,2,0) — both carry
 * !important, so specificity is what decides; this wins regardless of
 * enqueue order.
 */
body .ka-site-header.elementor-sticky--effects {
  background-color: rgba(2, 15, 36, 0.82) !important;
  -webkit-backdrop-filter: blur(14px) saturate(140%) !important;
  backdrop-filter: blur(14px) saturate(140%) !important;
  box-shadow: 0 6px 30px rgba(0, 0, 0, 0.35) !important;
}

/* ── FOOTER — v1.2.4 update ───────────────────────────────────────────────
 * v1.2.0 kept the footer SOLID #020F24 on purpose, as a hard-stop anchor
 * (rationale kept below for history). This round's brief is explicit:
 * "RETIRE #020F24 as a base color entirely on brand pages" — no exceptions
 * carved out for the footer. The ANCHOR CONCEPT is kept (footer stays the
 * darkest, solid, unmoving frame element), but it's now expressed with the
 * new gradient family's own darkest stop (#08204d) instead of the retired
 * #020F24, so no #020F24 background remains anywhere on a brand page.
 *
 * Safe with respect to "blog stays untouched": the shared footer template
 * (#7765) already renders dark on blog/single-post pages by design (this
 * project's header+footer-stay-dark-on-both-theme-variants decision) — the
 * blog's LIGHT theme is scoped to its own body content
 * (.ka-blog-archive / body.single-post), never to this shared footer
 * template, so recoloring the footer here does not touch blog styling.
 *
 * v1.2.0 original note (kept for history): "kept SOLID #020F24, untouched,
 * on purpose — chosen as a hard stop rather than a gradient-into-footer
 * transition. The new gradient's darkest stop (#08204d) already sits close
 * in tone to the footer's #020F24, so the seam reads as a deliberate
 * 'anchor' rather than a jump; simpler and zero risk to the footer's
 * existing, unrelated CSS."
 */
body .elementor-7765 .elementor-element.elementor-element-3204bc5:not(.elementor-motion-effects-element-type-background),
body .elementor-7765 .elementor-element.elementor-element-3204bc5 > .elementor-motion-effects-container > .elementor-motion-effects-layer {
  background-color: #08204d !important;
}

/* ── KBM BOOK LANDING PAGES (body.single-book) ───────────────────────────────
 * book-landing.css (Kate Book Manager plugin) is NOT edited directly — the
 * plugin ships/versions independently, and this round's brief calls for
 * delivery via child-theme CSS/zip. These are plain-specificity overrides
 * (all beat book-landing.css's un-important, lower-specificity originals),
 * kept as `!important` anyway for safety against any future plugin update
 * that might re-order its own cascade.
 *
 * NOTE: book-landing.css's `--kbm-bg` custom property is intentionally NOT
 * redefined here. It is dual-purposed in that stylesheet — used both for
 * page/section backgrounds AND (via `color: var(--kbm-bg)`) as the "near-
 * black text on a bright accent button" role on ~9 buttons/labels per book.
 * Overriding the variable globally would have accidentally lightened that
 * button text too, hurting contrast against `--book-accent` colors that are
 * bright and vary per book. Instead, every selector below is targeted
 * directly at the semantic "this IS a page background" usages only.
 */
body.single-book .kbm-wrap,
body.single-book .kbm-blurb,
body.single-book .kbm-related,
body.single-book .kbm-reviews,
body.single-book .kbm-series,
body.single-book .kbm-more-books,
body.single-book .kbm-reading-guide,
body.single-book .kbm-bonus,
body.single-book .kbm-modal__cover-col,
body.single-book .kbm-hero,
body.single-book .mask-layer,
body.single-book .kbm-questions-scene,
body.single-book .kbm-questions-bg {
  background: #0d3170 !important;
}

/* The fullscreen intro splash (#kbm-intro) is the one place on a book page
   that is a genuine, single, full-viewport moment with no adjacent stacked
   sections to seam against — gets the real sampled gradient instead of the
   flat fallback, echoing the home hero directly. */
body.single-book #kbm-intro {
  background: linear-gradient(180deg, #1a4a90 0%, #0d3170 50%, #08204d 100%) !important;
}

/* Bottom vignette fade behind the blurb cover image — dark end-stop updated
   to the new gradient's own darkest sampled value instead of the old navy. */
body.single-book .kbm-blurb__img-wrap::after {
  background: linear-gradient(transparent 50%, #08204d 100%) !important;
}

/* ── FORM PAGE: /fp-launch-team/ (page ID 7887) ──────────────────────────────
 * The only one of the four listed form pages that actually has a flat
 * #020F24 page-section background of its own (Elementor element d9adfda).
 * /contact/, /press-kit/, /ai-interest-form/ do NOT — see the file-header
 * note above. This is a single full-page section, so it gets the real
 * 3-stop gradient directly (no seam risk, only one section on the page).
 * This page (7887) already renders correctly and is the visual/CSS
 * reference for the rest of the v1.2.4 round below.
 */
body.page-id-7887 .elementor-element-d9adfda {
  background: linear-gradient(180deg, #1a4a90 0%, #0d3170 50%, #08204d 100%) !important;
}

/* ══════════════════════════════════════════════════════════════════════════
 * v1.2.4 — ROUND 2: BASE unification + Signup + Contact
 * ══════════════════════════════════════════════════════════════════════════
 * v1.2.0/v1.2.1/v1.2.2 above only ever styled isolated hero/showcase
 * sections. This round completes the job: real PAGE-LEVEL base
 * backgrounds (body + Astra's own wrapper divs, so nothing can show
 * through as white even if Astra's Customizer sets its own container
 * background), on an explicit body/page-id allowlist — never a bare
 * `body{}` rule — so pages outside this round's scope (most notably
 * /books/, left as-is on purpose; the still-draft cover-constellation
 * page 7920; and anything not yet audited) are never touched.
 *
 * NOT included here: the About page (7778). Its lower sections
 * (.ka-about-hook/-bio/-endorsements/-newsletter, the CTA .ka-about__section)
 * are fixed section-by-section in the dedicated
 * assets/about-lower-sections-fix.css instead of via a page-level body
 * background, specifically so the top hero + pinned scroll-story (out of
 * scope this round, confirmed already correct) are never touched by a
 * blanket body-background rule. See that file's header comment for the
 * full root-cause writeup.
 */

/* ── Signup / Newsletter page (id 915) ────────────────────────────────────
 * Verified live: post-915.css sets no background-color of its own on any
 * top-level section/column — it was falling back to Astra's default
 * (white). No rogue one-off color here (unlike /contact/); this is a
 * plain missing-background case.
 */
body.page-id-915,
body.page-id-915 .site,
body.page-id-915 #content,
body.page-id-915 #primary,
body.page-id-915 .ast-container {
  background: linear-gradient(180deg, #1a4a90 0%, #0d3170 50%, #08204d 100%) !important;
}

/* The page's own "Free eBook" signup widget is MailerLite's hosted
 * groot.js "Embedded Form" (`<div class="ml-embedded" data-form="mhPw6P">`,
 * populated client-side from MailerLite's own account/form design config —
 * this is a DIFFERENT mechanism than the footer's own hand-coded, already-
 * correctly-gold `.ml-ft-form`). Its default account theme is the azure
 * #057DCD this ticket flags. Because the actual DOM MailerLite renders
 * inside that div is only ever visible after their script runs client-
 * side, these are BEST-EFFORT overrides using MailerLite's commonly
 * documented embedded-form class names — verify live in a browser after
 * upload; if MailerLite's script reinjects inline styles on top, the
 * account's own form design (mailerlite.com dashboard) may need the
 * button/field colors set there directly instead.
 */
body.page-id-915 .ml-embedded button,
body.page-id-915 .ml-embedded .ml-form-embedSubmit button,
body.page-id-915 .ml-embedded input[type="submit"] {
  background-color: #F5D000 !important;
  border-color: #F5D000 !important;
  color: #020F24 !important;
}
body.page-id-915 .ml-embedded input[type="email"],
body.page-id-915 .ml-embedded input[type="text"],
body.page-id-915 .ml-embedded .ml-form-fieldRow input {
  background-color: #0F3271 !important;
  border: 1px solid rgba(255,255,255,.32) !important;
  color: #F5D000 !important;
}

/* ── v1.2.9 fix (H1) — Signup page heading/body text contrast ────────────
 * The v1.2.4 pass above gave this page its page-level royal-blue background
 * and re-themed the MailerLite embed, but never touched the page's own
 * Elementor Heading/Text-Editor widget text colors — that's the gap this
 * round closes.
 *
 * Root cause, confirmed live: the H1 ("Craving Free stories & Insider
 * Perks?", widget `.elementor-element-056ae56`) carries
 * `color:var(--e-global-color-text)` in its own generated post-915.css —
 * Elementor Global Kit 19's "Text" global color, `#00120B`
 * (`rgb(0,18,11)`, confirmed via the Kit's own `.elementor-kit-19{...}`
 * custom-property block in post-19.css). That color is a light-background
 * default from the Kit and was never overridden for this page's dark
 * background, unlike every other brand page's headings. The body-copy
 * widget below it (`.elementor-element-41ca24e`) sets no color at all, so
 * it falls through to Astra core's own `body{color:#808285}` default —
 * also a light-background gray, also unfixed.
 * Font-family is NOT broken here: the sitewide Oswald catch-all
 * (`.elementor-heading-title{font-family:'Oswald',...!important}` above)
 * already wins over this widget's own literal `"Fjalla One"` declaration
 * — confirmed via load order (this file loads before post-915.css, and
 * `!important` wins regardless) — so only COLOR needs fixing here.
 *
 * New colors match the site's already-established convention for the
 * same kind of block elsewhere — the About page's own newsletter-signup
 * CTA (`.ka-about-newsletter__heading`/`__sub` in about-lower-sections-
 * fix.css), the closest direct analog to this page (both are newsletter
 * opt-in CTAs): WHITE `#EEF2F8` for the heading, and the same established
 * secondary-text convention `rgba(238,242,248,.72)` for body copy — not
 * gold, which this project reserves for a different CTA context
 * (fp-launch-team's launch-team heading).
 *
 * Verified contrast (WCAG AA) against every stop of this page's own
 * background gradient (#1a4a90 top / #0d3170 mid / #08204d bottom):
 *   heading #EEF2F8   — 7.70:1 / 11.06:1 / 14.12:1 (need ≥3:1 large text)
 *   body rgba(...,.72) — 4.84:1 /  6.47:1 /  7.87:1 (need ≥4.5:1 body text)
 * Both clear AA at every point in the gradient, including the worst case
 * (lightest stop, where the heading sits). For reference, the OLD colors
 * measured 1.21–2.22:1 (heading) and 2.25–4.12:1 (body) across the same
 * range — confirming the reported near-unreadable contrast.
 */
body.page-id-915 .elementor-element-056ae56 .elementor-heading-title {
  color: #EEF2F8 !important;
}
body.page-id-915 .elementor-element-41ca24e,
body.page-id-915 .elementor-element-41ca24e p {
  color: rgba(238, 242, 248, .72) !important;
}

/* ── Contact page (id 13) ─────────────────────────────────────────────────
 * Verified live via post-13.css:
 *   - .elementor-element-fdd048a is a real, empty ~107px-tall section
 *     (its one column's .elementor-widget-wrap has ZERO widgets inside —
 *     confirmed against the live HTML) carrying a leftover diagonal
 *     azure/navy gradient (#057DCD -> #1E3D58). It contributes nothing but
 *     an empty colored band before the real content — removed entirely.
 *   - The content section has TWO columns. .elementor-element-7f9a02f (the
 *     column wrapping the Formidable form) carries an explicit
 *     background-color:#FFFFFF of its own, which is what strands the
 *     already-correct, already-LIGHT-themed navy Formidable fields
 *     (formidable-theme.css styles them for a dark backdrop sitewide) on a
 *     white card — neutralized to transparent so the page-level gradient
 *     shows through and the fields finally sit on the background they were
 *     actually designed for.
 *   - .elementor-element-806bb9c (the contact-info column: heading, address/
 *     phone text, social icons) is DELIBERATELY LEFT WHITE — its own text
 *     colors (heading/icons at `--e-global-color-fa09a94:#1E3D58`, a dark
 *     navy) were never adapted for a dark backdrop. Verified via contrast
 *     math: #1E3D58 on the new gradient's mid-stop #0d3170 is ~1.1:1 —
 *     effectively invisible. Making this column transparent would trade a
 *     background mismatch for illegible text, which is worse. Only the
 *     page's OUTER background (body/Astra wrappers) changes here; the
 *     info column's own white card is untouched.
 */
body.page-id-13,
body.page-id-13 .site,
body.page-id-13 #content,
body.page-id-13 #primary,
body.page-id-13 .ast-container {
  background: linear-gradient(180deg, #1a4a90 0%, #0d3170 50%, #08204d 100%) !important;
}
body.page-id-13 .elementor-element-fdd048a {
  display: none !important;
}
body.page-id-13 .elementor-element-7f9a02f > .elementor-widget-wrap,
body.page-id-13 .elementor-element-7f9a02f > .elementor-element-populated {
  background-color: transparent !important;
}

/* ══════════════════════════════════════════════════════════════════════════
 * v1.2.5 — SITEWIDE TYPE UNIFICATION: Oswald as the site's heading face
 * ══════════════════════════════════════════════════════════════════════════
 * Kate's brief: replace 'Fjalla One' with 'Oswald' (Impact fallback) as the
 * ONE heading face across the entire site. Most brand-page heading rules
 * (About, Formidable) had their own literal 'Fjalla One' declaration and
 * were fixed directly in their own files (about-hero-fix.css,
 * about-lower-sections-fix.css, about-scroll-story.css, formidable-
 * theme.css). This rule is the sitewide CATCH-ALL for everywhere else,
 * because Fjalla One isn't only hardcoded in our own theme files — it's
 * also the live value of Elementor's GLOBAL KIT "Accent" typography preset
 * (`--e-global-typography-accent-font-family:"Fjalla One"`, confirmed live
 * in the Kit's own generated CSS, post-19.css). Any Heading widget (or
 * Essential-Addons post-grid title) anywhere on the site that uses that
 * Kit preset — confirmed live on /books/ (page 906)'s book-title links,
 * `.eael-entry-title a`, via `font-family:var(--e-global-typography-
 * accent-font-family)` — renders Fjalla One even though NO literal
 * "Fjalla One" string ever appears in that page's own CSS. Press-kit
 * (page 2016)'s `.elementor-heading-title` widgets have the opposite
 * drift: they use the Kit's "Secondary" preset (Poppins, the BODY font)
 * for headings, which is equally wrong for a heading/body typographic
 * hierarchy. Both are corrected below, sitewide and in one place, rather
 * than chasing every page's own per-post generated CSS file individually.
 *
 * WHY !important + a plain (non-nested) selector: Elementor's own
 * generated per-post CSS is enqueued AFTER this file (see the sitewide
 * <link> order confirmed live: ka-site-recolor-css loads before
 * elementor-frontend-css and every elementor-post-NNN-css), and every
 * widget rule it writes carries real specificity of its own (an
 * `.elementor-element-<id>` id-class). A plain `h1..h6`/`.elementor-
 * heading-title` rule without `!important` would lose on BOTH counts
 * (later source order AND higher specificity). `!important` is the only
 * lever that wins regardless of a future Elementor re-save re-ordering
 * that per-post CSS file. This mirrors the exact justification already
 * used throughout formidable-theme.css for the same kind of fight.
 *
 * SCOPE / SAFETY — this rule changes ONLY `font-family`. It never sets
 * `color`, so it cannot introduce or change any contrast relationship —
 * every heading keeps whatever color it already had (verified sampled/
 * computed per-page in this round's report). It targets:
 *   - real heading tags (h1-h6) and their anchor children (h1 a..h6 a) —
 *     the anchor-child case is required for /books/'s `.eael-entry-title
 *     a` book-title links, where the FONT is set on the <a> itself, not
 *     the parent tag, so it doesn't just inherit from a parent h-rule;
 *   - `.elementor-heading-title` — Elementor's own Heading widget wrapper
 *     class, in case that widget's chosen HTML tag is ever a non-heading
 *     element (div/span/p);
 *   - `.eael-entry-title` / `.eael-entry-title a` explicitly — the
 *     Essential Addons post-grid title class confirmed live on /books/.
 * Deliberately NOT extended to icon-box titles, testimonial names, or
 * other non-heading widget "title" classes — out of scope per the brief
 * (headings only).
 */
h1, h2, h3, h4, h5, h6,
h1 a, h2 a, h3 a, h4 a, h5 a, h6 a,
.elementor-heading-title,
.eael-entry-title,
.eael-entry-title a {
  font-family: 'Oswald', Impact, sans-serif !important;
}

/* ── Books page (id 906) — body-COPY font drift (not a heading issue) ────
 * Verified live via post-906.css: two elements on the "Girl Lost" featured
 * teaser hardcode a literal `font-family:"Schibsted Grotesk"` instead of
 * the site's established Poppins body font — `.elementor-element-5f5f9b4`
 * (the teaser's descriptive paragraph, a Text Editor widget) and the
 * `.elementor-button` inside `.elementor-element-cd13ee6` (a CTA chip).
 * Both are corrected to Poppins per this round's "audit body font drift"
 * requirement. Color/background are untouched (white text on that
 * teaser's own dark card background, and the button's own pink chip fill
 * — neither touched here, font-family only).
 */
body.page-id-906 .elementor-element-5f5f9b4,
body.page-id-906 .elementor-element-cd13ee6 .elementor-button {
  font-family: 'Poppins', 'Helvetica Neue', Arial, sans-serif !important;
}