/* 07 — Forms
   Owns: the Gravity Forms (Orbital) sizing, spacing and submit button
   Depends on: 01-tokens
   See also:   includes/gravity-forms-theme-layer.php — the colours and radius

   ── The rule for this file ───────────────────────────────────
   GRAVITY FORMS IS THEMED BY ASSIGNING ITS VARIABLES, NEVER BY OUT-SPECIFYING
   ITS SELECTORS. There is not one rule here that targets a .gform_*, .gfield_*
   or .gform_wrapper element. Orbital exposes 747 custom properties — every
   value below is one of them — and going around them means owning a selector
   fight with a plugin updated far more often than this theme.

   If something looks like it needs a real selector, search the list first:

     grep -o -- '--gf-[a-z0-9-]*' \
       wp-content/plugins/gravityforms/assets/css/dist/gravity-forms-*.css |
       sort -u

   It is nearly always there. The uppercase submit button below looks like it
   needs a rule and does not (--gf-ctrl-btn-text-transform).

   ── Why half of this lives in PHP ────────────────────────────
   AND HOW TO TELL WHICH HALF, because guessing wrong is silent. Gravity Forms
   prints a <style> block per form, inline, after every stylesheet:

     #gform_wrapper_4[data-form-index="0"].gform-theme { …64 properties… }

   Those 64 are the colour system plus --gf-radius. At 1-2-0 with an id that is
   not knowable ahead of time, no stylesheet can beat it, so assignments for
   ANY of those properties are discarded here without warning — which is what
   had happened to the --gf-color-primary line in 01-tokens.css, leaving the
   submit button Gravity Forms' stock blue on a site that has no blue buttons.
   Those properties are registered through the plugin's Theme Layer API
   instead; see includes/gravity-forms-theme-layer.php.

   Everything below is a property that block does NOT emit — sizes, spacing,
   type and the button's geometry — so it is reachable from CSS, and CSS is
   where it belongs. The test for a new property is simply whether it appears
   in that inline block; if it does, it goes in the PHP file.

   ── Why :root is in the selector ─────────────────────────────
   Gravity Forms also declares defaults on `.gform-theme--api,
   .gform-theme--framework` — a bare 0-1-0 — in
   gravity-forms-theme-framework.min.css. A block written here as
   `.gform-theme--framework { … }` scores the same, so the winner is load
   order, and the plugin's stylesheet is enqueued when a form renders, after
   every file in css/. :root adds a second 0-1-0; 0-2-0 beats the defaults and
   load order stops mattering.

   All three theme classes are listed because they are siblings on the same
   element, not alternatives — which of them a form carries depends on its own
   theme setting. */
:root .gform-theme--framework,
:root .gform-theme--foundation,
:root .gform-theme--api {

    /* ── Type ────────────────────────────────────────────────
       --gf-font-family-base ships as `initial`, which resolves to the browser
       default rather than to the page — a Gravity Form renders in Times on a
       site set in Barlow unless this is assigned. The three family slots
       (primary/secondary/tertiary) all chain to base, so one line does it. */
    --gf-font-family-base:    var(--font-body);
    --gf-font-size-primary:   1rem;      /* controls */
    --gf-font-size-secondary: 0.875rem;  /* labels, field descriptions */

    /* Weight is set on the -primary label slot directly rather than through
       --gf-font-weight-secondary, which it derives from: that token also feeds
       field descriptions and validation text, which should stay lighter. */
    --gf-ctrl-label-font-weight-primary: 600;

    /* ── Size and padding ────────────────────────────────────
       Control height is a HEIGHT, not padding. --gf-ctrl-padding-y ships as 0
       and the box is sized by --gf-ctrl-size-*, with the text centred in it;
       setting a vertical padding would ADD to that height rather than create
       it. 52px against Orbital's 38px default — the site had this at 30px,
       below even the stock value, which is where the cramped look came from.

       A textarea is the exception: it has no fixed height to centre within, so
       it takes a real padding-y. */
    --gf-ctrl-size-md:            50px;
    --gf-ctrl-padding-x:          16px;
    --gf-ctrl-textarea-height:    160px;
    --gf-ctrl-textarea-padding-y: 14px;

    /* ── Spacing between fields ──────────────────────────────
       This is the .gform_fields grid gap. NOT --gf-field-gap-*, which is the
       gap BETWEEN THE PARTS OF ONE FIELD — a name field's first/last inputs, a
       choice list's options. An easy pair to confuse, and confusing them reads
       as "the row gap setting does nothing".

       Orbital's 40px row gap is built for the labelless, placeholder-only
       forms the design reference uses. These forms carry labels, which already
       put 8px above every control, so 40px on top of that leaves the fields
       floating apart. 24px reads as one form. */
    --gf-form-gap-y: 16px;
    --gf-form-gap-x: 16px;

    /* Space above the submit row. --spacing-lg so the button separates from
       the last field by more than the fields separate from each other, which
       is what makes it read as the end of the form rather than another row. */
    --gf-form-footer-margin-y-start: var(--spacing-lg);

    /* ── Submit button ───────────────────────────────────────
       Matched to .btn / .btn-primary in 02-base.css — uppercase, 600, the same
       letter-spacing, and (via the theme layer) the same accent fill — so the
       one button on the page that actually submits something does not look
       like it came from a different site.

       Height is stated rather than inherited: --gf-ctrl-btn-size-md chains to
       --gf-ctrl-size-md, so the button would silently track the input height,
       and wanting those two to differ is the normal case. */
    --gf-ctrl-btn-size-md:        50px;
    --gf-ctrl-btn-padding-x-md:   32px;
    --gf-ctrl-btn-font-size-md:   0.9375rem;
    --gf-ctrl-btn-font-weight:    600;
    --gf-ctrl-btn-text-transform: uppercase;
    --gf-ctrl-btn-letter-spacing: 0.04em;
}

/* ── Forms on a dark band ────────────────────────────────────
   The dark-band inversion in 10-sections.css turns headings, body copy and
   links white. It does not reach a form: a <label> is none of those, and the
   controls are white panels that should stay white whatever is behind them —
   the same "light island" argument the card rules make there. So the label is
   the only thing that needs saying. Everything else about the form is already
   right on navy or on red.

   THIS SETS A THEME TOKEN, NOT A GRAVITY FORMS ONE, and that indirection is
   the whole trick. --gf-ctrl-label-color-primary is one of the 64 properties
   the plugin's inline block owns at 1-2-0, so assigning it here would do
   nothing. The theme layer emits it as
   `var(--rw-gf-label-color, var(--text))` instead, which turns it into a
   question this file can answer: --rw-gf-label-color is an ordinary inherited
   custom property, so setting it on the ROW flows down into the form and the
   plugin's own block picks it up. Specificity never enters into it.

   The same token carries the required asterisk, whose default --gf-color-danger
   red is legible on navy and nearly invisible on the accent band.

   .rw-dark-bg is included so this also covers a row whose dark background came
   from a photo or a gradient rather than from a band class. */
.rw-dark-bg,
.rw-section--dark,
.rw-section--accent {
    --rw-gf-label-color: var(--white);
}