/**
 * BPS Lite — Contact Form 7 skin.
 * ============================================================================
 * Added 0.2.8. Before this file, BPS Lite shipped **zero** CF7 CSS — measured
 * across the whole plugin tree 2026-08-15. That matters because CF7 is the
 * ruled form stack for the Lite tier (Blueprint Forms + BMeta are Pro-only, by
 * design), so the recommended way to put a contact form on a Lite site produced
 * an unstyled browser-default form sitting inside a branded page.
 *
 * What CF7 inherited without this file, measured on 0.2.7:
 *   - submit button fill .... only inside .light/.light2/.dark/.dark2 sections.
 *                             light3 and dark3 got nothing (fixed in shapes.css).
 *   - input / textarea ...... warm-organic and soft-rounded only, with HARDCODED
 *                             borders and focus rings that ignore the palette.
 *                             modern-flat styled them not at all.
 *   - errors and success .... nothing whatsoever. CF7's own red default, against
 *                             whatever the site's brand happens to be. On a demo
 *                             this is the most visible gap of the lot.
 *
 * 🪤 WHY A SEPARATE HAND-WRITTEN FILE. `bps-lite-core.css` and every
 * `skin-*.css` are COMPILED OUTPUT of `build/compile-skins.php`, which needs an
 * active moa-bps-base to run. Hand-editing them is silently wiped by the next
 * compile. Same reasoning as `bps-lite-shapes.css`; see its header.
 *
 * Colour comes from the palette, via the local --cf7-* bindings below (see the
 * note there for why the context tokens cannot be used directly here), so a
 * palette change repaints the form automatically. The only fixed colours are
 * the validation red and success green, which are SEMANTIC — a form must say
 * "this is wrong" in a colour a user reads as wrong, not in the brand accent.
 * `bps-lite-forms.css` sets the same precedent for its own success notice.
 *
 * Specificity: `.wpcf7-form` + element is (0,1,1)-(0,2,0), which is enough
 * against CF7's own stylesheet and Astra's. No `!important` is used except
 * where a measured rule already carries it — see the submit button below.
 */

/* --------------------------------------------------------------------------
 * LOCAL TOKEN BINDING — read this before changing any colour below.
 *
 * 🪤 The context tokens (--border-color / --accent / --text-color) are bound by
 * the skin ON the `.section` element, and they DO NOT reach deep descendants of
 * a CF7 form: measured 2026-08-15 on a real contact page, the section computed
 * `--border-color: #DCE7E7` while the `<input>` inside it computed EMPTY, so
 * every rule written as `var(--border-color, #ccc)` silently painted the #ccc
 * fallback and the form ignored the palette entirely. It looks like the CSS
 * never loaded. It had.
 *
 * The palette LITERALS (--light-border / --dark-accent / …) are declared on
 * :root and do inherit everywhere. So bind a local set here, per tone, and use
 * only those below. Anything reading a bare context token in this file is a bug.
 * ----------------------------------------------------------------------- */
.wpcf7-form {
  --cf7-border: var(--light-border, #ccc);
  --cf7-accent: var(--light-accent, #0066cc);
  --cf7-ink:    var(--light-text, #1a1a1a);
  --cf7-field:  #fff;

  /* The error hue. NOT the painted colour — the tip mixes this with the band's
   * own ink so one token reads on a cream band and a near-black one alike. See
   * the validation block below. A palette wanting a different red sets this. */
  --cf7-error:  #e5484d;

  /* 🔴 ASTRA OWNS THE FIELD TEXT COLOUR AND WE ASK IT NICELY RATHER THAN OUTBIDDING IT.
   * Added 2026-09-13. Astra prints inline theme CSS in <head> carrying
   *
   *   .wpcf7 input.wpcf7-form-control:not([type=submit]):focus { color: var(--ast-form-input-focus-text, #475569) }
   *
   * at **(0,4,1)**, plus a bare-element twin for the resting state. This file's own rule
   * is (0,2,1), and the inline block is emitted after the enqueued stylesheets, so Astra
   * wins on specificity AND on source order. Result: typed text turned slate #475569 on
   * a near-black field the moment the input had a value — invisible in every static
   * check, because an EMPTY field measures correctly. Mark caught it by typing in it.
   *
   * 🪤 It transitions (Astra sets `transition: all .2s`), so a measurement taken straight
   * after typing catches an interpolated colour — #E0E3E6 on the way from white to slate
   * — which reads like a third mystery value and sent the first diagnosis sideways.
   * Measure after the transition settles, or read `-webkit-text-fill-color`.
   *
   * Astra reads a custom property by design, so supplying it is the supported route and
   * needs no specificity fight, no !important, and no duplication of Astra's selector
   * shape (which would break the day Astra changes it). It also fixes FIREFOX, which
   * ignores `-webkit-text-fill-color` entirely — the belt-and-braces line further down
   * masks this in Blink only, so on its own it would have left Firefox users typing
   * slate-on-black.
   *
   * Declared once, here, deliberately: `var(--cf7-ink)` is resolved on the INPUT, where
   * the dark binding below has already rebound --cf7-ink, so one declaration serves both
   * tones. */
  --ast-form-input-text:       var(--cf7-ink);
  --ast-form-input-focus-text: var(--cf7-ink);
}

/* 🔴 ON A DARK TONE THE FIELD IS A HOLE, AND WHAT YOU TYPE IN IT IS WHITE.
 * Rewritten 2026-09-13 from Mark's review: *"the input fields are pretty much black —
 * if the input fields are dark, having white text is better. People cannot see what
 * they're typing."*
 *
 * Two changes, both deliberate:
 *
 * 1. `--cf7-ink` is a literal `#fff`, NOT `var(--dark-text)`. A palette is free to set
 *    --dark-text to something soft for body copy — several on this estate do, and Lite
 *    ships --dark-text2/3 dimmer still — but a form field is not body copy. You have to
 *    be able to read what you are typing while you type it, so this one value does not
 *    take part in the palette's tonal range.
 *
 * 2. The field was `rgba(255,255,255,.06)`, which composites to rgb(26,32,45) on a navy
 *    pane — a 1.2:1 difference from the pane itself, so it does not read as an input at
 *    all until you find its border. A dark inset plus a brighter border makes the hole
 *    obvious, which is the half of Mark's note that is about the FIELD rather than the
 *    text: he described them as "pretty much black", so they may as well be, on purpose.
 */
.section:is(.dark, .dark2, .dark3) .wpcf7-form {
  /* 🪤 NOT `--dark-border`. That token is tuned for dividers and card edges against the
   * page — on momentum it is #26344F, which against a 32%-black field on a #0B1220 pane
   * measures 1.4:1 and leaves the input with no visible edge at all. Measured after the
   * first pass at this: field-versus-pane came out 1.04:1, i.e. the box was invisible
   * and only the text in it said a field was there. A form control has to announce
   * itself before it is focused, so the border is derived from the foreground instead. */
  --cf7-border: rgba(255, 255, 255, 0.24);
  --cf7-accent: var(--dark-accent, #66aaff);
  --cf7-ink:    #fff;
  --cf7-field:  rgba(0, 0, 0, 0.32);
}

/* --------------------------------------------------------------------------
 * Layout
 * ----------------------------------------------------------------------- */
.wpcf7 {
  max-width: 560px;
  /* 🪤 OWED-funnelgap-3, fixed 2026-09-20. The cap shipped without a centring rule, so
   * in a centred `moa-width-regular` band the form sat flush left in a ~1180px column
   * with a void beside it — it reads as broken layout, not a design choice. No gate
   * could see it: no overflow, no contrast failure, no missing alt, no filler string.
   * `margin-inline`, not `margin: 0 auto`, so vertical spacing from the band is kept.
   * The `.wpcf7-form { text-align: left }` rule below is correct and stays — a form
   * owns its own alignment. Only the capped BOX is centred. */
  margin-inline: auto;
}

/* A form owns its own alignment — dropped into a centred Elementor section it
 * would otherwise centre every label. Same fix, same reason, as
 * bps-lite-forms.css:22. */
.wpcf7-form {
  text-align: left;
}

.wpcf7-form p {
  margin: 0 0 1.1rem;
}

.wpcf7-form label {
  display: block;
  margin-bottom: 0.35rem;
  font-weight: 600;
  line-height: 1.3;

  /* 🔴 WAS `var(--cf7-ink)` — corrected 0.7.32. `--cf7-ink` is the ink that goes
   * INSIDE the input. A label sits OUTSIDE it, on the band, so painting it with the
   * field's ink is only correct while field tone happens to match band tone — and
   * breaking that match is the entire purpose of the form-style chip.
   *
   * Measured 2026-09-20 across four funnel lead pages the moment `moa-form-light`
   * was applied via `html_class`: apex 1.09:1, forge-method 1.07:1, northbeam
   * 1.03:1, momentum 1.06:1. Dark labels on dark bands, invisible.
   *
   * 🪤 The sibling rule in bps-lite-forms.css had the identical bug and was fixed
   * first — but that one is ancestor-scoped (`[class*="moa-form-"] .wpcf7-form
   * label`) so it only ever matched the CHIP route. A class applied through CF7's
   * `html_class` lands ON the form, where that selector cannot reach, and this rule
   * kept painting. Two routes to the same variation, and a fix to one is not a fix
   * to the other — check both.
   *
   * `inherit` is right for every case: on a bare band the label takes the band's
   * colour; inside a panel that sets `color` (`.bps-cf7--card`) it takes the
   * panel's. A variant wanting something else sets `--cf7-label`. */
  color: var(--cf7-label, inherit);
}

/* --------------------------------------------------------------------------
 * Controls
 *
 * 🔴 The `height: auto; line-height: 1.4` pair is NOT tidiness — it is the
 * measured Astra defect from bps-lite-forms.css:56-75. `font: inherit` drags in
 * the body line-height (Astra 17px/1.65 = 28.05px line box) while Astra pins
 * form fields to height:40px, so 28.05 + 20.4 padding + 2 border = 50.45px of
 * content in a 40px box and the text clips — worst on <select>. Do not remove.
 * ----------------------------------------------------------------------- */
.wpcf7-form input[type="text"],
.wpcf7-form input[type="email"],
.wpcf7-form input[type="tel"],
.wpcf7-form input[type="url"],
.wpcf7-form input[type="number"],
.wpcf7-form input[type="date"],
.wpcf7-form input[type="password"],
.wpcf7-form select,
.wpcf7-form textarea {
  display: block;
  width: 100%;
  padding: 0.6rem 0.75rem;
  border: 1px solid var(--cf7-border);
  border-radius: var(--radius-base, 6px);
  background: var(--cf7-field);
  color: var(--cf7-ink);
  /* 🔴 `-webkit-text-fill-color` alongside `color`, not instead of it. Where both are
   * set the FILL wins for rendering, so a UA sheet, an autofill preview or a theme rule
   * that sets only `-webkit-text-fill-color` can dim typed text while `color` still
   * computes correctly — which is exactly the shape of the report that led here:
   * measured white on an empty field, measurably duller once filled. Setting both
   * closes the gap rather than leaving the two properties free to disagree. */
  -webkit-text-fill-color: var(--cf7-ink);
  font: inherit;
  height: auto;
  line-height: 1.4;
  box-sizing: border-box;
}

.wpcf7-form textarea {
  min-height: 6rem;
  resize: vertical;
}

.wpcf7-form input:focus,
.wpcf7-form select:focus,
.wpcf7-form textarea:focus {
  outline: 2px solid var(--cf7-accent);
  outline-offset: 1px;
  border-color: var(--cf7-accent);
}

/* Checkbox / radio groups stack rather than running inline off the edge. */
.wpcf7-form .wpcf7-checkbox,
.wpcf7-form .wpcf7-radio {
  display: flex;
  flex-direction: column;
  gap: 0.4rem;
}

.wpcf7-form .wpcf7-list-item {
  margin: 0;
  display: flex;
  align-items: center;
  gap: 0.5rem;
}

.wpcf7-form .wpcf7-list-item-label {
  font-weight: 400;
}

.wpcf7-form input[type="checkbox"],
.wpcf7-form input[type="radio"] {
  width: auto;
  margin: 0;
  accent-color: var(--cf7-accent);
}

/* --------------------------------------------------------------------------
 * Submit
 *
 * 🪤 bps-lite-core.css:169 paints `.section.<tone> input[type="submit"]` with
 * `!important`. CF7's submit IS an input[type=submit], so inside a toned section
 * it already picks up the accent fill — that is the ONE thing CF7 got for free.
 * These rules only add the shape (radius, padding, pointer) and must therefore
 * NOT set background-color, or they would fight a rule they cannot win against
 * and produce exactly the ghost-button confusion documented in the cookbook.
 * ----------------------------------------------------------------------- */
.wpcf7-form input[type="submit"],
.wpcf7-form button[type="submit"] {
  width: auto;
  padding: 0.75rem 1.75rem;
  border-radius: var(--button-radius, var(--radius-base, 6px));
  font: inherit;
  font-weight: 600;
  line-height: 1.4;
  height: auto;
  cursor: pointer;
  border: none;
  transition: opacity 0.2s ease;
}

.wpcf7-form input[type="submit"]:hover,
.wpcf7-form button[type="submit"]:hover {
  opacity: 0.9;
}

.wpcf7-form input[type="submit"]:disabled {
  opacity: 0.55;
  cursor: not-allowed;
}

/* --------------------------------------------------------------------------
 * Validation and response states.
 *
 * CF7 sets the state as a class on .wpcf7-response-output and appends
 * .wpcf7-not-valid-tip after the offending control. Left alone these render as
 * CF7's stock red border-box in the middle of a branded page.
 * ----------------------------------------------------------------------- */
/* 🔴 SPECIFICITY AND TONE, BOTH. Corrected 0.7.32 after measuring the painted page.
 *
 * 1. Astra prints `.wpcf7 .wpcf7-not-valid-tip { color:#DC2626 }` (0,2,0) as inline
 *    theme CSS whenever CF7 is active. A bare `.wpcf7-not-valid-tip` (0,1,0) never
 *    won — every tip in the estate was painted Astra red, not ours. `body[class]`
 *    takes this to (0,3,1).
 *
 * 2. 🪤 Winning is not enough. The tip renders OUTSIDE the field, directly on the
 *    band, so a fixed dark red is the wrong answer on a dark band — our own #b3261e
 *    measured 2.8:1 there, WORSE than the Astra red it would have replaced. The tip
 *    therefore follows the band exactly as the label does (`--cf7-label, inherit`):
 *    mixing in `currentColor` lightens the red on a dark band and deepens it on a
 *    light one, with no tone class to read. 🪤 Tone class is a ROLE, not a
 *    brightness — `currentColor` is the only signal here that is always literal.
 *
 * Measured after the change: 5.4:1 on light bands, 6.3:1 on dark. */
.wpcf7-not-valid-tip {
  display: block;
  margin-top: 0.35rem;
  font-size: 0.875em;
  font-weight: 500;
}

body[class] .wpcf7-form .wpcf7-not-valid-tip {
  color: var(--cf7-error, #e5484d);                              /* pre-2023 browsers */
  color: color-mix(in srgb, var(--cf7-error, #e5484d) 78%, currentColor);
}

.wpcf7-form .wpcf7-not-valid {
  border-color: #b3261e;
}

.wpcf7-form .wpcf7-response-output {
  margin: 1.25rem 0 0;
  padding: 0.85rem 1rem;
  border-radius: var(--radius-base, 6px);
  border: 1px solid;
  font-size: 0.95em;
}

/* Sent successfully. Mirrors bps-lite-forms.css's success notice exactly so the
 * two form stacks do not report success in two different greens. */
.wpcf7-form.sent .wpcf7-response-output {
  background: #e7f6ec;
  border-color: #b6e0c4;
  color: #1d643b;
}

/* Validation failed, submission failed, spam, or aborted. */
.wpcf7-form.invalid .wpcf7-response-output,
.wpcf7-form.unaccepted .wpcf7-response-output,
.wpcf7-form.payment-required .wpcf7-response-output {
  background: #fdf3e7;
  border-color: #e8c9a0;
  color: #7a4b12;
}

.wpcf7-form.failed .wpcf7-response-output,
.wpcf7-form.aborted .wpcf7-response-output,
.wpcf7-form.spam .wpcf7-response-output {
  background: #fdecea;
  border-color: #f5c2bd;
  color: #8c1d18;
}

/* --------------------------------------------------------------------------
 * Spinner — CF7 ships it as a bare grey pill with no vertical alignment.
 * ----------------------------------------------------------------------- */
.wpcf7-spinner {
  margin: 0 0 0 0.75rem;
  vertical-align: middle;
}

/* --------------------------------------------------------------------------
 * Two-column field rows.
 *
 * Opt-in, not automatic: wrap two fields in <div class="bps-cf7-row"> in the
 * CF7 form template. Local-business contact forms almost always want
 * Name | Email and Phone | Company paired, and CF7 emits plain markup that
 * takes grid without complaint.
 * ----------------------------------------------------------------------- */
.wpcf7-form .bps-cf7-row {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 0 1rem;
}

@media screen and (max-width: 512px) {
  .wpcf7-form .bps-cf7-row {
    grid-template-columns: 1fr;
  }
}

/* ============================================================================
 * FORM SHAPES — `bps-cf7--stacked` and `bps-cf7--inline`
 * ============================================================================
 * Added 2026-09-13 from Mark's sales-page review. Everything above styles the
 * FIELDS; nothing above decides the form's LAYOUT, so a lead-magnet opt-in and
 * a hero email-capture bar both render as the same full-width column of rows.
 *
 * 🪤 These are SHAPES, not markers. Mark's 2026-09-13 split: `bps-*` hook
 * classes paint nothing and only come alive under a body scope, while form
 * shapes, spacing and padding classes paint by design. A shape belongs in the
 * plugin because it is reusable structure; per-client colour and sizing on top
 * of it belongs in the site's own Head Code field. Named `bps-cf7--*` rather
 * than a bare `bps-*` so `gate-markers.py` does not read them as markers.
 *
 * Applied by adding the class to the CF7 form's own <form> tag via the
 * shortcode's `html_class` attribute:
 *
 *   [contact-form-7 id="12" html_class="bps-cf7--stacked"]
 *
 * 🪤 `html_class` lands on the <form> element itself, so the selectors below
 * are `.wpcf7-form.bps-cf7--x` at (0,2,0) — one step above the base rules in
 * this file, which is what lets a shape override them without !important.
 * ------------------------------------------------------------------------ */

/* STACKED — a lead-magnet pane. Label above field, fields flush, submit full
 * width. The default CF7 <p> wrapper carries a paragraph margin that reads as
 * a gap between a label and the input it belongs to; this closes it. */
.wpcf7-form.bps-cf7--stacked p {
  margin: 0 0 0.75rem;
}
.wpcf7-form.bps-cf7--stacked label {
  display: block;
  margin-bottom: 0.25rem;
}
.wpcf7-form.bps-cf7--stacked input[type=text],
.wpcf7-form.bps-cf7--stacked input[type=email],
.wpcf7-form.bps-cf7--stacked input[type=tel],
.wpcf7-form.bps-cf7--stacked textarea,
.wpcf7-form.bps-cf7--stacked select {
  width: 100%;
}
.wpcf7-form.bps-cf7--stacked input[type=submit],
.wpcf7-form.bps-cf7--stacked button[type=submit] {
  width: 100%;
  margin-top: 0.25rem;
}
.wpcf7-form.bps-cf7--stacked .wpcf7-response-output {
  margin: 0.75rem 0 0;
}

/* INLINE — a hero or banner capture bar: field and button on one line, wrapping
 * to stacked below 560px. `flex-wrap` rather than a media query on the parent so
 * it also collapses correctly inside a narrow column on a wide screen — the
 * optin panes are 40% of their row, which is under 560px long before the
 * viewport is. */
.wpcf7-form.bps-cf7--inline > p,
.wpcf7-form.bps-cf7--inline .bps-cf7-inline {
  display: flex;
  flex-wrap: wrap;
  align-items: stretch;
  gap: 0.5rem;
  margin: 0;
}
.wpcf7-form.bps-cf7--inline input[type=text],
.wpcf7-form.bps-cf7--inline input[type=email] {
  flex: 1 1 14rem;
  min-width: 0;
}
.wpcf7-form.bps-cf7--inline input[type=submit],
.wpcf7-form.bps-cf7--inline button[type=submit] {
  flex: 0 0 auto;
}
.wpcf7-form.bps-cf7--inline .wpcf7-spinner {
  align-self: center;
}

/* --------------------------------------------------------------------------
 * Placeholder, and Chrome's autofill.
 *
 * 🪤 AUTOFILL IS THE ONE CASE THE RULES ABOVE CANNOT REACH. Chrome paints
 * `input:-webkit-autofill` from its own internal sheet — a light-blue ground
 * with dark text — at a priority no author `background` declaration beats, and
 * it fires for anyone whose browser has their own name and email saved. On a
 * dark pane that is the exact symptom reported here: text that reads as dark
 * on dark, on fields that were already nearly invisible. It cannot be
 * reproduced headless, because a fresh Chromium has nothing saved to fill.
 *
 * The only reliable counter is an inset shadow the size of the field (Chrome
 * honours `box-shadow` where it ignores `background`) plus
 * `-webkit-text-fill-color`, which is what it actually renders the glyphs
 * with. The long transition is the second half of the trick: the internal
 * background is applied once on fill and never re-applied, so delaying the
 * property change indefinitely means it never visibly lands.
 * ----------------------------------------------------------------------- */
/* 🔴 0.7, NOT 0.55 — corrected 0.7.34 after measuring the PAINTED placeholder.
 *
 * 🪤 `opacity` is a separate property from `color`, so a harness reading
 * `getComputedStyle(el, '::placeholder').color` never sees it and over-reports
 * this badly. That blind spot is why these were reported as passing once: at
 * 0.55 the light-field placeholders measured 4.03–4.09:1 across the estate —
 * below 4.5:1 on every white field, on the text that tells a user what to type.
 *
 * Measured against both inks actually in the estate: #10150F needs >= 0.60 and
 * #3C2F2F needs >= 0.70 to clear 4.5:1 on white. 0.7 clears both with margin and
 * still reads as a hint rather than as entered text. Kept in step with Base's
 * _forms-cf7.scss so the two stacks do not fade placeholders differently. */
.wpcf7-form ::placeholder {
  color: var(--cf7-ink);
  opacity: 0.7;
}

.wpcf7-form input:-webkit-autofill,
.wpcf7-form input:-webkit-autofill:hover,
.wpcf7-form input:-webkit-autofill:focus,
.wpcf7-form textarea:-webkit-autofill,
.wpcf7-form select:-webkit-autofill {
  -webkit-text-fill-color: var(--cf7-ink);
  caret-color: var(--cf7-ink);
  -webkit-box-shadow: 0 0 0 100px var(--cf7-field) inset;
  box-shadow: 0 0 0 100px var(--cf7-field) inset;
  transition: background-color 5000s ease-in-out 0s;
}

/* 🪤 The inset shadow above paints a FLAT colour, so on a dark tone it has to be
 * a real colour rather than the translucent one the field normally uses — a
 * 32%-black inset over nothing renders as near-transparent and the light-blue
 * shows through anyway. Re-bind it opaque for the autofill case only. */
.section:is(.dark, .dark2, .dark3) .wpcf7-form input:-webkit-autofill,
.section:is(.dark, .dark2, .dark3) .wpcf7-form input:-webkit-autofill:hover,
.section:is(.dark, .dark2, .dark3) .wpcf7-form input:-webkit-autofill:focus {
  -webkit-box-shadow: 0 0 0 100px var(--dark-bg2, #141f35) inset;
  box-shadow: 0 0 0 100px var(--dark-bg2, #141f35) inset;
}

/* BPS-TRADES-2026-09-18 */

/* ============================================================================
 * CARD — `bps-cf7--card`
 * ============================================================================
 * A capture card: the form sits in its own light panel with a full-width dark
 * submit under it. Added 2026-09-18 from the Brisbane trades wireframes, where
 * every one of the ten puts exactly this on the right of the home hero.
 *
 * Pair it with the `moa-form-light` chip on an ancestor when the band is dark —
 * the shape here is layout and the chip is colour, the same split as everywhere
 * else in this file.
 *
 *   [contact-form-7 id="12" html_class="bps-cf7--card"]
 *
 * 🔴 LABELS ARE VISUALLY HIDDEN, NOT REMOVED. The wireframes label these fields
 * with placeholders alone, which is what makes the card read as five tight rows
 * rather than ten loose ones. A placeholder is not an accessible name, so the
 * <label> stays in the markup and is clipped — never `display:none`, which takes
 * it out of the accessibility tree along with the pixels.
 *
 * 🪤 Every colour is a palette token. Measured against the wireframe on Redgum:
 * card #ffffff = --light-bg, ink #0C2340 = --light-text, field border #D6DDE6 ≈
 * --light-border #E2E7ED, submit #0C2340 = --dark-bg. The card repaints per site
 * with no per-site CSS, which is the whole point of doing it here.
 * ------------------------------------------------------------------------ */
.wpcf7-form.bps-cf7--card {
  background: var(--light-bg, #ffffff);
  border-radius: var(--radius-lg, 10px);
  padding: clamp(1.25rem, 2.2vw, 1.875rem);

  /* 🔴 Added 0.7.32. The card paints a light panel but declared no `color`, so anything
   * inside it that inherits — a label, a reassurance line, a consent checkbox caption —
   * took the BAND's colour. On a dark band that is white text on a white card. It does
   * not bite today only because this shape visually hides its labels; unhide one, or add
   * any other text to the card, and it does. Setting it here means everything in the card
   * reads against the card, which is what a panel is for. */
  color: var(--cf7-ink, var(--light-text, #14171a));

  /* 🔴 The card declares the light locals ITSELF rather than relying on the
   * `moa-form-light` chip, because `bps-lite-forms.css` — where the chip lives — is not
   * enqueued on an Elementor page. Measured from the browser's own stylesheet list on a
   * live trades home page: core, skin, shapes, utilities, flavours and cf7 load; forms
   * does not. Declaring them here also beats `.section:is(.dark,…) .wpcf7-form`, which
   * sets the same properties ON the form element, so an ancestor could never win. */
}

/* 🪤 (0,3,1), one point above `.section:is(.dark,.dark2,.dark3) .wpcf7-form` at (0,3,0).
 * Both declare these locals ON THE FORM ELEMENT, so the more specific selector wins and
 * an ancestor chip can never reach them. Measured: at (0,2,0) the card painted white and
 * its fields stayed `rgba(0,0,0,.32)`. */
body[class] .wpcf7-form.bps-cf7--card {
  --cf7-field:  var(--light-bg, #ffffff);
  --cf7-ink:    var(--light-text, #14171a);
  --cf7-border: var(--light-border, #d6dde6);
  --cf7-accent: var(--light-accent, #0066cc);
}

.wpcf7-form.bps-cf7--card > :is(h2, h3, h4) {
  margin: 0 0 0.375rem;
  color: var(--light-text, #14171a);
  line-height: 1.15;
}

.wpcf7-form.bps-cf7--card > p {
  margin: 0 0 0.75rem;
}

/* the lede under the card title, and the fine print under the button */
.wpcf7-form.bps-cf7--card > p:first-of-type,
.wpcf7-form.bps-cf7--card small {
  color: var(--light-text, #14171a);
  opacity: 0.72;
  line-height: 1.6;
}

.wpcf7-form.bps-cf7--card small {
  display: block;
  text-align: center;
  font-size: 0.8125rem;
}

/* 🔴 clipped, not hidden — see the note above.
 * 🪤 It is the label's TEXT that is clipped, never the <label> itself: CF7 renders the
 * control INSIDE the label, so clipping the label collapses the input with it. Measured
 * on the live card — every field came out 30px wide and invisible. The generator wraps
 * the text in `.bps-cf7-lab` for exactly this. */
.wpcf7-form.bps-cf7--card .bps-cf7-lab,
.wpcf7-form.bps-cf7--card label > br:first-of-type {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

.wpcf7-form.bps-cf7--card .bps-cf7-row {
  margin-bottom: 0.625rem;
}

body[class] .wpcf7-form.bps-cf7--card :is(input, select, textarea):not([type="submit"]) {
  background: var(--cf7-field);
  color: var(--cf7-ink);
  border-color: var(--cf7-border);
  padding: 0.8125rem 0.875rem;
}

/* 🪤 `!important` here, and only here, for the reason this file already allows it:
 * `bps-lite-core.css` paints `.section.dark input[type="submit"]` with
 * `background-color: var(--cta) !important`. Measured on the card: the button came out
 * the coral accent on a white panel, which is the one combination the shape must not
 * produce. A specificity war cannot be won against `!important`, so this matches it. */
body[class] .wpcf7-form.bps-cf7--card :is(input, button)[type="submit"] {
  width: 100%;
  margin-top: 0.25rem;
  background-color: var(--dark-bg, #14171a) !important;
  border-color: var(--dark-bg, #14171a) !important;
  color: var(--dark-text, #ffffff) !important;
}

body[class] .wpcf7-form.bps-cf7--card :is(input, button)[type="submit"]:hover,
body[class] .wpcf7-form.bps-cf7--card :is(input, button)[type="submit"]:focus {
  background-color: var(--dark-bg2, var(--dark-bg, #14171a)) !important;
  border-color: var(--dark-bg2, var(--dark-bg, #14171a)) !important;
  color: var(--dark-text, #ffffff) !important;
}