/*
 * Kate Angelo — Formidable Forms brand theme
 * -------------------------------------------------------------------------
 * Restyles Formidable's built-in "with_frm_style" theme (its native
 * CSS-custom-property theming API) to match the kateangelo.com brand.
 *
 * VERIFIED brand colors:
 *   Old flat navy (pre-v1.2.0 page/section background, now RETIRED as a
 *   page bg but reused below as the form field bg — see v1.2.0 notes):
 *                                       #020F24
 *   NEW lighter royal-blue page background (v1.2.0, sampled from the home
 *   hero + About royal-blue section — see assets/site-recolor.css for the
 *   full gradient definition):     #1a4a90 → #0d3170 → #08204d
 *   Royal blue (form field bg through v1.1.0, pulled directly from the live
 *     footer newsletter signup field's inline style — see v1.0.6 notes
 *     below; RETIRED as the field bg in v1.2.0, see v1.2.0 notes):
 *                                       #0F3271
 *   Gold (CTAs / accents / required):  #F5D000
 *   Gold hover (from header button):   #FFE033
 *   Gold active/pressed:               #E0BC00
 * Fonts: Poppins (labels/help text, matches rest of site), "Space Mono"
 *   (form fields + submit button — pulled from the footer newsletter field,
 *   which uses font-family:'Space Mono',monospace).
 *
 * ── v1.2.0 CHANGE LOG (field contrast retune) ───────────────────────────────
 * The site's dark base recolored from flat navy #020F24 to a lighter
 * royal-blue gradient (#1a4a90 → #0d3170 → #08204d — see site-recolor.css).
 * The v1.0.6 field background (#0F3271) was chosen specifically because it
 * was LIGHTER than the old #020F24 page, giving visible separation. Against
 * the NEW, lighter page background that relationship inverts — #0F3271 now
 * sits close enough in luminance to the new page tone (especially the
 * lighter #1a4a90 end of the gradient) to visually blend in.
 *
 * FIX: field background flipped to go DARKER than the page instead of
 * lighter — reusing the old flat navy `#020F24` itself as the new field
 * fill (--bg-color / --bg-color-active / the autofill box-shadow color
 * below). This guarantees strong separation against every stop in the new
 * gradient (darkest new stop #08204d is still meaningfully lighter than
 * #020F24) and is a deliberate design callback: the retired page color
 * becomes the "well" the input sits in. Border strengthened alongside it,
 * from `rgba(255,255,255,.15)` to `rgba(255,255,255,.32)`, for a visible
 * edge even where a field sits over a very dark part of the page. Gold
 * caret/typed-text/placeholder treatment (v1.0.7) and the submit button's
 * gold fill + specificity/!important fix (v1.0.5/v1.0.6) are UNCHANGED —
 * re-verified this round against the live formidableforms.css hardcoded-
 * blue rule, selector shape identical, our override still (0,0,4,1) +
 * !important vs Formidable's (0,0,3,1), still wins.
 *
 * SCOPING — this entire file is nested under `.frm_forms.with_frm_style`,
 * which is Formidable's own root wrapper class. It cannot exist on the
 * Elementor nav/footer or any other plugin's markup, so it is safe from
 * the site-wide CSS-leak issue documented for home-landing.css (bare nav/
 * footer selectors bled onto Elementor menus). Do NOT add bare/global
 * selectors to this file — keep every rule nested under .frm_forms.
 * This file is enqueued sitewide on every singular page/post whenever
 * Formidable is active (see functions.php ka_child_formidable_theme_css),
 * so it is NOT narrowed to form 13 — any current or future Formidable
 * form on the site (confirmed live as of this round: form 1 "Contact Me"
 * on /contact/ and /press-kit/, form 9 on /ai-interest-form/, form 13 on
 * /fp-launch-team/) automatically inherits this look.
 *
 * ── v1.0.6 CHANGE LOG ─────────────────────────────────────────────────────
 *
 * Kate changed direction: instead of the v1.0.5 light ice-blue card, every
 * Formidable form should now match the visual style of the FOOTER
 * newsletter signup field (the small MailerLite "Free eBook — Subscribe to
 * the Newsletter" field/button in the site footer) and sit directly on the
 * dark navy page background, with no card.
 *
 * 1) CARD REMOVED. The entire v1.0.5 ice-blue card treatment on
 *    `.frm_forms.with_frm_style` (background #E9F1F9, 1px #C7DAEA border,
 *    16px border-radius, 38px padding, box-shadow, 720px max-width, plus
 *    its 600px-breakpoint padding override) has been deleted outright. The
 *    form's outer wrapper now carries no background/border/shadow/sizing
 *    of its own again, so it sits transparently on whatever section
 *    background the page provides (the site's dark navy, same context as
 *    the footer).
 *
 * 2) FIELDS re-themed to match the live footer field. Verified directly
 *    from the footer's own rendered markup (an inline-styled MailerLite
 *    <input>, not a stylesheet rule):
 *      background: #0F3271
 *      border: 1px solid rgba(255,255,255,.15)
 *      color: #EEF2F8
 *      font-family: 'Space Mono', monospace
 *      padding: .7rem 1rem (~10.5px 15px at this site's ~15px root
 *        font-size) — scaled up here to 14px 18px for a full-width,
 *        multi-field form so it doesn't feel cramped next to labels/help
 *        text at normal reading size.
 *      font-size: the footer field itself is .75rem (~11px), which reads
 *        fine as a single compact accessory field but is too small for a
 *        full multi-field form; bumped to 15px here for legibility while
 *        keeping the monospace character.
 *    NOTE ON BORDER-RADIUS: the live footer field/button pairing has NO
 *    border-radius set anywhere (not inline, not in home-landing.css) —
 *    it renders with square corners because it's a single squared-off
 *    input+button assembly. Kate asked for a 2px radius on form fields
 *    specifically (a deliberate, barely-there softening for a taller,
 *    multi-field form context where fully square corners read harsher
 *    than they do on the compact footer field) — applied as `--border-
 *    radius: 2px` below. Flagging this as the one value that is a
 *    judgment call rather than a literal 1:1 copy of the live footer CSS.
 *    Placeholder text uses `--text-color-disabled` (Formidable's own
 *    placeholder-color variable) set to a dimmed, lower-opacity version of
 *    the light text color rather than full-contrast white.
 *
 * 3) SUBMIT BUTTON — gold fill/text UNCHANGED from v1.0.5 (bg #F5D000,
 *    text #020F24, bold, uppercase, radius ~2-4px, hover #FFE033). NEW in
 *    v1.0.6: font-family 'Space Mono', monospace added to match the
 *    field/footer aesthetic (the footer's own "Join" button also uses
 *    Space Mono, confirmed in its inline style).
 *
 *    THE v1.0.5 SPECIFICITY FIX IS PRESERVED, UNCHANGED, AND RE-VERIFIED
 *    THIS ROUND. Formidable's own live, DB-generated stylesheet
 *    (wp-content/plugins/formidable/css/formidableforms.css — re-fetched
 *    and re-checked live on this round, selector shape is IDENTICAL to
 *    what was documented in v1.0.5) still contains:
 *
 *      .frm_style_formidable-style.with_frm_style input[type=button],
 *      .frm_style_formidable-style.with_frm_style .frm_submit button,
 *      .frm_form_submit_style {
 *          font-family:"Lucida Grande","Lucida Sans Unicode",Tahoma,sans-serif;
 *          background: rgba(5,125,205,1); /-- hardcoded literal blue --/
 *          ...
 *      }
 *
 *    That selector is (0,0,3,1) specificity. Our override rule below
 *    (`.frm_forms.with_frm_style .frm_submit .frm_button_submit` /
 *    `.frm_forms.with_frm_style .frm_submit button.frm_button_submit`) is
 *    (0,0,4,1) — one class more specific — AND carries `!important`, so it
 *    keeps winning regardless of DOM order or any future Formidable
 *    Styler re-save. `font-family: 'Space Mono', monospace !important;`
 *    was added into this SAME override rule (not a separate one) so it
 *    rides the identical specificity/!important guarantee as the
 *    background/border/color fix — no new specificity war introduced.
 *
 *    FIELD FONT-FAMILY note: Formidable's field font-family comes from
 *    `font-family: var(--font)` on `.with_frm_style input[type=text], ...`
 *    (specificity 0,0,2,1) — and `var(--font)` is the SAME variable used
 *    for field labels (`.frm_primary_label{font-family:var(--font);...}`).
 *    That means the --font variable can't be repointed to Space Mono
 *    without also flipping labels to monospace, which is explicitly NOT
 *    wanted (labels stay Poppins). So field font-family is set via a
 *    dedicated override rule (below) at (0,0,3,1) specificity — still
 *    higher than Formidable's (0,0,2,1) — targeting only the field
 *    elements, leaving --font (and therefore labels) on Poppins.
 *
 * 4) LABELS + HELP/DESCRIPTION TEXT flipped BACK to light (this reverses
 *    v1.0.5's dark-on-card flip, returning to the v1.0.4 approach, since
 *    the form is on the dark navy page again): labels #EEF2F8, help/
 *    description text #B9C4D9. Checkbox/radio OPTION TEXT and section
 *    dividers follow the same light treatment for the same reason. Labels/
 *    help text stay Poppins — the Space Mono treatment is only for the
 *    monospace field/button aesthetic pulled from the footer, not for all
 *    form typography.
 *
 *    Required-field asterisk renders gold (--required-color: #F5D000) as
 *    a side effect of a prior specificity fix, not an intentional design
 *    choice — left as-is per Kate, do not "fix" it back to red.
 *
 * 5) CHECKBOXES/RADIOS — gold `accent-color: #F5D000` unchanged from prior
 *    rounds.
 *
 * OUT OF SCOPE (explicitly, per Kate) — Jetpack's own contact form styling
 * and any MailerLite/Elementor-native embedded forms (like the footer
 * field itself) are separate systems that render outside Formidable's
 * `.frm_forms` markup entirely, so none of this CSS reaches them. Follow-up
 * work if Kate wants those visually matched too.
 *
 * ── v1.0.7 CHANGE LOG (two live field-level bug reports from v1.0.6) ──────
 *
 * 1) AUTOFILL BACKGROUND — browser autofill (Chrome/Edge's native
 *    `:-webkit-autofill` UA style, plus the standardized `:autofill`
 *    pseudo-class for other engines) was painting its own light/gray
 *    background + black text over our royal-blue fields on autofilled
 *    inputs. Fixed with the standard giant-inset-box-shadow + text-fill-
 *    color trick — see the dedicated AUTOFILL OVERRIDE block below.
 *
 * 2) ENTERED-TEXT COLOR — typed/entered field text is now explicitly gold
 *    (#F5D000) instead of the v1.0.6 light off-white (#EEF2F8), with
 *    caret-color also set to gold (previously unset). See the full
 *    investigation notes inline above the updated field override rule:
 *    the v1.0.6 text WAS already rendering light (not literally dark) on
 *    real typed input — verified via live computed-style inspection — so
 *    this is a value change (light -> gold) plus a defensive !important
 *    override, not a specificity fight against some other plugin/theme
 *    rule. Placeholder text is untouched and stays dimmed-light
 *    (rgba(238,242,248,0.55)), so real content stays visually distinct
 *    from an empty field's placeholder hint.
 */

.frm_forms.with_frm_style {

    /* ---- brand variables (Formidable's own theming API) ---- */
    --font: 'Poppins', 'Helvetica Neue', Arial, sans-serif;
    --base-font-size: 16px;
    --font-size: 16px;

    /* form title / description (only visible if a form is embedded with
       title=true / description=true — Launch Team + Contact use title=false).
       Light again now that the form sits directly on the dark navy page. */
    --title-size: 28px;
    --title-color: #EEF2F8;
    --title-margin-top: 0;
    --title-margin-bottom: 22px;
    --form-desc-size: 15px;
    --form-desc-color: #B9C4D9;
    --form-desc-margin-bottom: 24px;

    /* field labels — LIGHT again (v1.0.4 approach), form is back on navy. */
    --label-color: #EEF2F8;
    --weight: 600;
    --required-color: #F5D000;
    --required-weight: bold;

    /* field descriptions / help text — softer light-blue-grey for hierarchy
       under the near-white labels. */
    --description-font-size: 13px;
    --description-color: #B9C4D9;

    /* inputs, selects, textareas — match the live footer newsletter field:
       royal-blue bg, light text, subtle white-alpha border, monospace font
       (font-family applied via dedicated override rule below, since
       var(--font) is shared with labels — see comment above). */
    --field-font-size: 15px;
    --field-height: 50px;
    --line-height: 50px;
    --field-pad: 14px 18px;
    --field-margin: 22px;
    --field-weight: 400;
    --text-color: #EEF2F8;
    /* v1.2.0: border strengthened (.15 -> .32) for extra separation now that
       the field sits on a lighter page. */
    --border-color: rgba(255, 255, 255, 0.32);
    --field-border-width: 1px;
    /* v1.2.0: field bg flipped from the old light-on-navy royal blue
       (#0F3271, lighter than the page) to the RETIRED flat navy (#020F24,
       darker than every stop of the new page gradient) — see the v1.2.0
       change-log note above for why the direction flipped. */
    --bg-color: #020F24;
    --bg-color-active: #020F24;
    --border-color-active: #F5D000;
    --border-radius: 2px;

    /* disabled fields + placeholder text (Formidable maps ::placeholder
       color to --text-color-disabled) — a dimmed, lower-opacity version of
       the light text color, not full-contrast white. */
    --text-color-disabled: rgba(238, 242, 248, 0.55);
    --bg-color-disabled: rgba(2, 15, 36, 0.5);
    --border-color-disabled: rgba(255, 255, 255, 0.08);

    /* error state — keep a real, accessible red; brand-gold on an error
       reads as decorative, not urgent. Unchanged from prior rounds. */
    --text-color-error: #7A1F1F;
    --bg-color-error: #FDF1F1;
    --border-color-error: #C0392B;
    --border-width-error: 1.5px;

    /* checkboxes / radios — option text is light again (form is on navy). */
    --check-align: block;
    --check-font-size: 15px;
    --check-label-color: #EEF2F8;
    --check-weight: 400;

    /* section dividers inside long forms — light again for the same reason. */
    --section-font-size: 18px;
    --section-color: #EEF2F8;
    --section-border-color: #F5D000;

    /* submit button — gold CTA, unchanged from v1.0.5 (verified against
       the header "Free eBook" button + the footer's own "Join" button,
       which also uses this same gold). NOTE: these variables alone are NOT
       sufficient to win the cascade — see the dedicated override rule
       below, which is the real fix (carried over unchanged from v1.0.5). */
    --submit-font-size: 15px;
    --submit-bg-color: #F5D000;
    --submit-border-color: #F5D000;
    --submit-border-width: 2px;
    --submit-text-color: #020F24;
    --submit-weight: 700;
    --submit-border-radius: 4px;
    --submit-padding: 16px 36px;
    --submit-margin: 18px 0 0 0;
    --submit-hover-bg-color: #FFE033;
    --submit-hover-border-color: #FFE033;
    --submit-hover-color: #020F24;
    --submit-active-bg-color: #E0BC00;
    --submit-active-border-color: #E0BC00;
    --submit-active-color: #020F24;

    /* success / message styling — Formidable renders this as its own
       self-contained notice box, so a light bg + dark text card reads fine
       regardless of the page's own background. Unchanged. */
    --success-bg-color: #EAF7EE;
    --success-border-color: #B7E4C7;
    --success-text-color: #1E5631;

    /* ---- v1.0.6: NO card. The form sits directly on the page's dark
       navy background again — the entire v1.0.5 card block (max-width,
       margin, background-color, border, border-radius, padding,
       box-shadow) has been removed. ---- */
}

/* Section/step heading style — v1.2.5: 'Fjalla One' -> 'Oswald' (Impact
   fallback), matching the new sitewide heading face (see functions.php's
   ka-fonts enqueue). Currently only shows when a form is embedded with
   title=true (Launch Team + Contact use title=false today), but fixed
   here for consistency/future use. Color untouched (--title-color:
   #EEF2F8, already solid light text on this site's navy/royal-blue page
   backgrounds — safe, unaffected by this font-only change). */
.frm_forms.with_frm_style .frm_form_title,
.frm_forms.with_frm_style h3.frm_form_title {
    font-family: 'Oswald', Impact, sans-serif;
    text-transform: uppercase;
    letter-spacing: 0.5px;
}

/*
 * Field font-family override — Formidable's own field rule reads
 * font-family from var(--font) (shared with labels), so it can't be
 * changed via the variable without also flipping labels to monospace.
 * This rule is (0,0,3,1) specificity — one class higher than Formidable's
 * own (0,0,2,1) field rule — and carries !important as insurance, same
 * defensive posture as the submit-button fix below.
 *
 * ── v1.0.7: ENTERED-TEXT COLOR ADDED TO THIS SAME RULE ────────────────────
 * Investigated where typed field text was actually coming from before
 * touching anything: Formidable's own base field rule
 * (`.with_frm_style input[type=text], ... , select, textarea
 * {color:var(--text-color); ...}`, specificity 0,0,2,1) reads our
 * `--text-color` variable, which v1.0.6 already set to `#EEF2F8` (light
 * off-white) on `.frm_forms.with_frm_style` at (0,0,2,0) — one class higher
 * than Formidable's own variable-setting default (`.with_frm_style{
 * --text-color:#555555;...}`, 0,0,1,0). Verified live via headless-browser
 * computed-style inspection (Chromium/Playwright against the live
 * /contact/ and /fp-launch-team/ pages): a real typed character in a text
 * input, and a live `<select>`'s own text/options, both already compute to
 * `rgb(238,242,248)` (#EEF2F8) — i.e. NOT dark, and nothing in Formidable's
 * plugin CSS, Astra's parent-theme CSS (astra-style.css / astra-inline.css,
 * checked directly), or this page's own Elementor per-post CSS sets a
 * higher-specificity or !important `color` on these elements. Elementor's
 * own dark-text input rule (`.elementor .e-form-input-base{color:#0c0d0e}`)
 * does NOT apply here — that class only exists on Elementor's native Form
 * widget, and these forms are embedded via Elementor's Shortcode widget,
 * which does not add that class to Formidable's markup.
 *
 * Conclusion: the "dark and hard to read" text Kate saw is consistent with
 * the SAME root cause as Issue 1 (browser autofill) — Chrome's native
 * `:-webkit-autofill` styling forces both the light autofill background
 * AND black text absent a `-webkit-text-fill-color` override, and v1.0.6
 * had no autofill rule at all yet. On a real, non-autofilled keystroke the
 * text was already rendering light, just not gold.
 *
 * Rather than repoint the shared `--text-color` variable to gold (it also
 * feeds Formidable's calculated-total display, file-dropzone text, the
 * SlimSelect custom-select widget, and the mini date-picker header — none
 * of which this request covers, same reasoning already used above for
 * `--font`), entered-text color is set here as a dedicated override on the
 * actual field elements only, riding the same (0,0,3,1) + !important
 * specificity already proven to win. `select option` is added to the
 * selector list (for the option text itself) and `:not(.frm_default)` is
 * added everywhere so Formidable's own dimmed "unselected default value"
 * state (the class it applies to a `<select>` still on its blank option)
 * is left alone rather than forced gold — the same placeholder/real-value
 * distinction Kate asked for, applied consistently to selects. In practice
 * the one live `<select>` on this site (fp-launch-team's State field) has
 * an empty/whitespace-only default option with no visible label, so this
 * exclusion has no visible effect today but keeps the rule correct if a
 * real placeholder-style option label is ever added.
 *
 * `caret-color` is set here too — v1.0.6 had none, so the blinking cursor
 * was the browser default (usually a dark/black tone) even though field
 * text itself was already light. Now both real-typed text and the caret
 * are gold, matching Issue 1's autofill fix (`-webkit-text-fill-color:
 * #F5D000` + `caret-color: #F5D000`) so there is no color mismatch between
 * autofilled and manually-typed text.
 *
 * ── v1.0.8 CHANGE LOG (post-submit confirmation message was illegible) ────
 *
 * Fixed the on-page confirmation message that appears after a successful
 * submit (form 13's redirect-delay message: "Application received! 🥳 …
 * 💛 Kate"), which rendered completely unstyled (dark text on the dark navy
 * page). Root cause + fix are documented in full immediately above the new
 * rule block near the bottom of this file (search "REDIRECT-DELAY
 * CONFIRMATION MESSAGE") — short version: the message's real class,
 * verified against the current Formidable Forms 6.32.1 plugin source, is
 * `.frm-redirect-msg`, NOT `.frm_message`, and its wrapper never carries the
 * `.frm_forms` class — so none of this file's existing `.frm_forms.with_frm_style`
 * rules, nor Formidable's own `.frm_message` styling, ever reached it.
 */
.frm_forms.with_frm_style input[type="text"]:not(.frm_default),
.frm_forms.with_frm_style input[type="email"]:not(.frm_default),
.frm_forms.with_frm_style input[type="password"]:not(.frm_default),
.frm_forms.with_frm_style input[type="number"]:not(.frm_default),
.frm_forms.with_frm_style input[type="url"]:not(.frm_default),
.frm_forms.with_frm_style input[type="tel"]:not(.frm_default),
.frm_forms.with_frm_style input[type="search"]:not(.frm_default),
.frm_forms.with_frm_style select:not(.frm_default),
.frm_forms.with_frm_style select option,
.frm_forms.with_frm_style textarea:not(.frm_default) {
    font-family: 'Space Mono', monospace !important;
    color: #F5D000 !important;
    caret-color: #F5D000 !important;
}

.frm_forms.with_frm_style input::placeholder,
.frm_forms.with_frm_style textarea::placeholder {
    font-family: 'Space Mono', monospace !important;
    /* Placeholder color intentionally NOT set to gold here — it already
       inherits --text-color-disabled (rgba(238,242,248,0.55), a dimmed
       light tone) from the Formidable rule below this block's specificity,
       so a real typed value (gold) stays visually distinct from an empty
       field's placeholder hint (dimmed light). Do not add a color
       declaration to this rule. */
}

/*
 * ── AUTOFILL OVERRIDE (v1.0.7, Issue 1) ───────────────────────────────────
 * Browser autofill (confirmed in Kate's screenshot: Email, Email-for-
 * NetGalley, City, State, Zip) paints its own native light/gray background
 * and black text via the internal `:-webkit-autofill` user-agent style,
 * which lives in a UA-origin stylesheet that normal author-origin
 * specificity/!important rules on `background-color`/`color` cannot beat
 * directly — the standard, well-documented workaround is to fight it with
 * an enormous inset `box-shadow` (which autofill does NOT special-case) to
 * visually cover the field with our own royal-blue background, plus
 * `-webkit-text-fill-color` (which DOES override autofill's own text-color
 * painting layer, unlike plain `color`). `1000px` spread is comfortably
 * larger than any real field on this site, including full-width textareas.
 * `transition: background-color 9999s ...` is the standard trick to stop
 * Chrome's own autofill "yellow flash" from briefly appearing before our
 * box-shadow paints over it.
 *
 * Both the `-webkit-` prefixed pseudo-class AND the standardized
 * `:autofill` pseudo-class (Firefox 86+, all recent Chromium/WebKit also
 * accept it) are included so this isn't Chromium/WebKit-only. Scoped to
 * `.frm_forms.with_frm_style` throughout — cannot leak outside a Formidable
 * form.
 */
.frm_forms.with_frm_style input:-webkit-autofill,
.frm_forms.with_frm_style input:-webkit-autofill:hover,
.frm_forms.with_frm_style input:-webkit-autofill:focus,
.frm_forms.with_frm_style textarea:-webkit-autofill,
.frm_forms.with_frm_style select:-webkit-autofill {
    -webkit-box-shadow: 0 0 0 1000px #020F24 inset !important;
    box-shadow: 0 0 0 1000px #020F24 inset !important;
    -webkit-text-fill-color: #F5D000 !important;
    caret-color: #F5D000 !important;
    transition: background-color 9999s ease-in-out 0s !important;
}

.frm_forms.with_frm_style input:autofill,
.frm_forms.with_frm_style input:autofill:hover,
.frm_forms.with_frm_style input:autofill:focus,
.frm_forms.with_frm_style textarea:autofill,
.frm_forms.with_frm_style select:autofill {
    -webkit-box-shadow: 0 0 0 1000px #020F24 inset !important;
    box-shadow: 0 0 0 1000px #020F24 inset !important;
    -webkit-text-fill-color: #F5D000 !important;
    caret-color: #F5D000 !important;
    transition: background-color 9999s ease-in-out 0s !important;
}

/* Native checkbox / radio accent color (modern browsers) — unchanged,
   gold accent regardless of card/no-card. */
.frm_forms.with_frm_style input[type="checkbox"],
.frm_forms.with_frm_style input[type="radio"] {
    accent-color: #F5D000;
    width: 18px;
    height: 18px;
}

/* Submit button: uppercase like the site's other CTA buttons (structural
   styling only — color/font-family handled by the dedicated override
   block below). */
.frm_forms.with_frm_style .frm_button_submit,
.frm_forms.with_frm_style button[type="submit"] {
    text-transform: uppercase;
    letter-spacing: 0.08em;
    cursor: pointer;
    transition: background-color 0.2s ease, border-color 0.2s ease;
}

/*
 * ── SUBMIT BUTTON COLOR + FONT OVERRIDE (v1.0.5 fix, carried forward
 *    unchanged in structure, extended with Space Mono in v1.0.6) ─────────
 * Beats Formidable's own hardcoded-blue base-state rule
 * (`.frm_style_formidable-style.with_frm_style .frm_submit button`,
 * specificity 0,0,3,1 — re-verified live this round, selector shape
 * unchanged) on BOTH specificity (this rule is 0,0,4,1 — four classes +
 * one element) AND `!important`, so it wins no matter which stylesheet the
 * browser parses last. Scoped to `.frm_forms.with_frm_style .frm_submit …`
 * only — cannot match anything outside a Formidable form.
 */
.frm_forms.with_frm_style .frm_submit .frm_button_submit,
.frm_forms.with_frm_style .frm_submit button.frm_button_submit {
    background-color: #F5D000 !important;
    border-color: #F5D000 !important;
    color: #020F24 !important;
    font-family: 'Space Mono', monospace !important;
}

.frm_forms.with_frm_style .frm_submit .frm_button_submit:hover,
.frm_forms.with_frm_style .frm_submit button.frm_button_submit:hover,
.frm_forms.with_frm_style .frm_submit .frm_button_submit:focus,
.frm_forms.with_frm_style .frm_submit button.frm_button_submit:focus {
    background-color: #FFE033 !important;
    border-color: #FFE033 !important;
    color: #020F24 !important;
}

.frm_forms.with_frm_style .frm_submit .frm_button_submit:active,
.frm_forms.with_frm_style .frm_submit button.frm_button_submit:active {
    background-color: #E0BC00 !important;
    border-color: #E0BC00 !important;
    color: #020F24 !important;
}

/* Focus ring that matches the gold active border above (keyboard a11y) */
.frm_forms.with_frm_style input:focus,
.frm_forms.with_frm_style select:focus,
.frm_forms.with_frm_style textarea:focus {
    outline: none;
    box-shadow: 0 0 0 3px rgba(245, 208, 0, 0.35);
}

/* Draft / secondary links (Save Draft, Previous) — light again (v1.0.4
   approach), form sits directly on the dark navy page. */
.frm_forms.with_frm_style .frm_save_draft,
.frm_forms.with_frm_style .frm_prev_page {
    color: #B9C4D9;
    font-family: 'Poppins', sans-serif;
    text-decoration: underline;
}

/* Field descriptions rendered below a field — light again, matches
   --description-color. */
.frm_forms.with_frm_style .frm_description {
    color: #B9C4D9;
}

/*
 * ── v1.0.8: REDIRECT-DELAY CONFIRMATION MESSAGE (fixes dark-on-dark bug) ──
 *
 * PROBLEM: after a successful submit, form 13 shows a celebratory message
 * ("Application received! 🥳 … 💛 Kate / Click here if you are not
 * automatically redirected") that rendered dark-on-dark and illegible
 * against the navy page.
 *
 * ROOT CAUSE, verified by reading the actual Formidable Forms plugin PHP
 * source (NOT assumed) — two sources cross-checked:
 *   1) The WordPress.org SVN trunk copy of the free "Formidable" plugin,
 *      fetched directly this round: plugins.svn.wordpress.org/formidable/
 *      trunk/classes/controllers/FrmFormsController.php. Its readme.txt
 *      Stable tag is 6.32.1 — matching Kate's locally-downloaded
 *      formidable-pro-6.32.zip almost exactly, and its front-end JS
 *      response-handling shape (redirect / delay / content / openInNewTab /
 *      fallbackMsg keys) was cross-verified byte-for-byte against the LIVE
 *      /wp-content/plugins/formidable/js/formidable.js fetched from
 *      kateangelo.com this round — so this is a high-confidence match for
 *      the code actually running on this site, not a guess from generic
 *      Formidable docs.
 *   2) Form 13's own live config, read via the site's REST API
 *      (GET /wp-json/frm/v2/forms/13, a route Formidable itself registers):
 *      confirms `"success_action":"redirect"`, `"redirect_delay":true`,
 *      `"redirect_delay_time":"8"`, and `"redirect_delay_msg"` containing
 *      Kate's exact celebratory text — i.e. this message is Formidable's
 *      formal "delay N seconds before redirecting, show this message
 *      during the delay" feature, not an edge-case fallback that rarely
 *      fires. It reliably shows for the full 8-second delay on every
 *      successful submission before the browser navigates to
 *      /book/fatal-pattern/.
 *
 * THE ACTUAL MARKUP (confirmed from FrmFormsController::get_redirect_message()
 * in the source above) is:
 *
 *   <div class="[whatever FrmFormsHelper::get_form_style_class() returns —
 *                always starts with " with_frm_style", NEVER includes the
 *                literal "frm_forms" class]">
 *     <div class="frm-redirect-msg" role="status">
 *       [Kate's message, run through wpautop() — real <p> tags]
 *       <br/>
 *       <a href="[redirect url]">Click here</a> if you are not automatically
 *       redirected.
 *     </div>
 *   </div>
 *
 * THIS IS WHY PRIOR ROUNDS' STYLING NEVER TOUCHED IT — two surprises versus
 * the "commonly .frm_message" assumption:
 *   (a) the class is "frm-redirect-msg" ONLY — Formidable does NOT also add
 *       "frm_message" here (that class is only used by the separate
 *       show_message_after_save()/show_lone_success_message() code path for
 *       non-redirect success actions), so none of Formidable's own
 *       `.with_frm_style .frm_message{...var(--success-*)...}` CSS (or our
 *       --success-bg-color/--success-border-color/--success-text-color
 *       variables set earlier in this file) ever applied to it — confirmed
 *       by grepping the live formidableforms.css fetched from kateangelo.com
 *       this round: zero rules reference "frm-redirect-msg".
 *   (b) the outer wrapper this message ships in does NOT carry the literal
 *       "frm_forms" class (only " with_frm_style" + a style-slug class) —
 *       so our EXISTING scoping root `.frm_forms.with_frm_style` (used
 *       throughout this file for the input/label/submit theming) can never
 *       match it either. That combination — no "frm_message" and no
 *       "frm_forms" — is exactly why this message reached production
 *       completely unstyled, inheriting the page/theme's default dark
 *       paragraph text color straight onto the dark navy background.
 *
 * SELECTOR CHOSEN: `.with_frm_style .frm-redirect-msg` (ancestor class that
 * IS always present, per source, + the message's own unique class), plus a
 * bare `.frm-redirect-msg` fallback for defense-in-depth. Both are safe from
 * leaking onto nav/footer/unrelated content — "frm-redirect-msg" is a
 * single-purpose class generated in exactly one function in the entire
 * Formidable codebase (confirmed via grep across the SVN trunk source), and
 * it cannot exist anywhere else on this site.
 *
 * Kate's message is written with blank-line-separated paragraphs and inline
 * <a> links (e.g. the "Fatal Pattern" and "from the publisher" links inside
 * her own copy, not just the trailing "Click here" fallback link) — these
 * get wrapped in real <p> tags by Formidable's own wpautop() call, so plain
 * `p` margin + `line-height` is sufficient for readable paragraph spacing;
 * no white-space hack needed. No card/background is added here, matching
 * the same "sits directly on the dark navy page, no card" direction Kate
 * set for the rest of the form in v1.0.6 — only spacing/color/typography are
 * applied. Emoji (🥳, 💛) are untouched: `color` never affects the color of
 * native color-emoji glyphs in any modern browser, so no exclusion rule is
 * needed for them.
 */
.with_frm_style .frm-redirect-msg,
.frm-redirect-msg {
    display: block;
    color: #EEF2F8 !important;
    font-family: 'Poppins', 'Helvetica Neue', Arial, sans-serif;
    line-height: 1.6;
    max-width: 700px;
    padding: 32px 36px;
}

.with_frm_style .frm-redirect-msg p,
.frm-redirect-msg p {
    color: inherit;
    margin: 0 0 1.15em 0;
}

.with_frm_style .frm-redirect-msg p:last-of-type,
.frm-redirect-msg p:last-of-type {
    margin-bottom: 0;
}

.with_frm_style .frm-redirect-msg a,
.frm-redirect-msg a {
    color: #F5D000 !important;
    text-decoration: underline;
    font-weight: 600;
}

.with_frm_style .frm-redirect-msg a:hover,
.with_frm_style .frm-redirect-msg a:focus,
.frm-redirect-msg a:hover,
.frm-redirect-msg a:focus {
    color: #FFE033 !important;
}

/* ── v1.2.4: invisible reCAPTCHA badge repositioning ─────────────────────
 * Any Formidable form using an invisible reCAPTCHA (data-size="invisible",
 * e.g. field id 6 / .frm-g-recaptcha on the Contact form) gets a badge
 * that Google's own script injects as `.grecaptcha-badge`, position:fixed,
 * appended directly to <body> — NOT nested inside the form or any of our
 * markup. Flagged live on /contact/ as "hanging off the right edge."
 * Google's Terms of Service require the badge stay visible (it cannot be
 * hidden), but explicitly allow repositioning it via CSS, which is what
 * this does — a small, deliberate offset from the true viewport corner
 * instead of wherever it lands by default. Unscoped (sitewide) since the
 * badge can appear on any page with an invisible-reCAPTCHA Formidable
 * form, not just Contact.
 *
 * CAVEAT: the badge's on-screen position also depends on whether any
 * ancestor of <body> has its own CSS `transform` (a `position:fixed`
 * descendant becomes relative to the nearest transformed ancestor instead
 * of the real viewport) — that can't be fully confirmed without live
 * browser devtools. This fix corrects the badge's own coordinates; if it
 * still renders off-position after upload, the next step is to find and
 * remove/adjust whatever transformed ancestor is capturing it.
 */

/* ── v1.2.9 fix (L4): bottom offset increased, 16px → 96px, to clear the
 * shared footer's (template #7765) bottom-right corner — the badge (fixed
 * bottom-right, ~60px tall per Google's standard invisible-badge box) was
 * landing on top of the footer's right-aligned "Connect" column content
 * at full scroll. Measured from the footer's own real, verified generated
 * CSS (post-7765.css): the footer's LAST section on the page is a
 * copyright bar (`.elementor-element-13ac3a8f`, 18px top + 18px bottom
 * padding = 36px chrome) whose right column is a right-aligned social-
 * icons row (`--icon-size:17px`, plus the icon widget's own default
 * padding — roughly 35-40px tall rendered) — a real, measured total of
 * ~71-76px for that bar alone. The OLD 16px offset put the badge's own
 * span at 16-76px from the true page bottom, which is almost exactly that
 * copyright bar's own height — meaning the top few pixels of the badge
 * were landing just above it, on the "Connect" column immediately above
 * (confirmed live as "slightly overlapping," consistent with only a
 * ~5-10px intrusion at that boundary). Moving the badge's own span to
 * 96-156px clears the ENTIRE copyright bar with room to spare (~20-25px
 * of margin above it) and, by the same margin, clears the Connect
 * column's own bottom edge (which sits right where the copyright bar
 * starts) rather than just barely grazing it. Horizontal position (right:
 * 16px) is unchanged — the reported collision was vertical/footer-height,
 * not horizontal, and Connect is still the rightmost column so the badge
 * stays visually aligned with it, just higher up.
 */
.grecaptcha-badge {
    right: 16px !important;
    bottom: 96px !important;
    z-index: 999 !important;
}
