/* Form field labels — visible.
 *
 * Ends the compromise recorded in CLAUDE.md's Forms section and in
 * `tools/cf7-harden-forms.php`. Every CF7 field carried a label, and every one
 * of them was `.screen-reader-text`: absolutely positioned, clipped to 1px.
 * The only thing a sighted visitor had to go on was the `placeholder`, which
 * disappears the moment they type — so anyone interrupted mid-form had nothing
 * left telling them which field they were in. WCAG 3.3.2 was satisfied for
 * assistive technology and for nobody else.
 *
 * The design direction unblocks this (§11): "drop `.screen-reader-text`, show
 * the labels." The markup change is in the tool, because CF7 form bodies live
 * in the database; this file is only what they look like.
 *
 * Two things about the colours:
 *
 * - Every value is `var(--ww-*, fallback)`. With the design system toggle OFF
 *   the fallbacks match the site as it stands; with it ON the same markup picks
 *   up the token palette. That is the pattern spec-panel.css established and
 *   the reason one component can serve both design states.
 * - `#4F4F4F` is the fallback because it is what the fields already use, and it
 *   measures 5.53:1 on the #D4D4D4 contacts panel and 8.19:1 on white — the
 *   worst ground a form lands on here is the panel, and it passes AA there.
 *
 * The placeholder is deliberately NOT restyled. `cf7-harden-forms.php` removes
 * any placeholder that merely repeated the label, so what is left is a genuine
 * hint or nothing at all.
 */

.ww-field {
  display: block;
}

.ww-field__label {
  display: block;
  margin-bottom: var(--ww-space-1);
  font-family: var(--ww-font-sans, inherit);
  font-size: var(--ww-text-sm, 0.875rem);
  font-weight: 500;
  line-height: 1.3;
  color: var(--ww-ink-2, #4F4F4F);
}

/* Spacing belongs to the label, not to the control.
 *
 * Left alone, the gap between one field and the next label measured 34px, 16px
 * and 35px down the same form — so a label sometimes sat closer to the field
 * ABOVE it than to its own, which is the one thing a label must never do,
 * because proximity is what pairs them. The wrapper owns the rhythm instead.
 * Scoped to `.ww-field`, so anything not wrapped is untouched. */
.ww-field {
  margin-bottom: var(--ww-space-3);
}

/* The control sits in its own block, so the gap is a margin and nothing else.
 *
 * Reported 2026-08-31 as "forms are way too big" — the enquiry form was 713px.
 * Two separate causes, and neither was the spacing values in this file.
 *
 * **1. An inline formatting context.** CF7 wraps each control in an INLINE
 * span, and the controls are inline-block, inside a block `<label>`. So every
 * label-to-control gap was really a line box, resolved against a 25.6px strut
 * and the control's own baseline — which is why identical markup measured a
 * 5px gap on the name field and 24px on the email field. The comment above
 * describes the same effect from the other side and blamed the controls for
 * disagreeing about height; they did not. The formatting context did.
 *
 * Making the wrapper and the control blocks removes the line box, so the only
 * thing between a label and its field is the margin declared above, and every
 * row is the same shape. `width: 100%` because a block-level input still
 * honours its `size="40"` attribute otherwise.
 *
 * **2. Two hand-pasted spacers that out-specified this file**, both removed at
 * source rather than fought here:
 *
 *   - `popups.css` set `margin-bottom: 20px` on
 *     `input.wpcf7-form-control.wpcf7-text.wpcf7-validates-as-required` —
 *     (0,3,1), which silently beat this file's old zeroing rule at (0,2,2). So
 *     only the two REQUIRED text fields were 20px taller than the rest.
 *   - `cust.css` set `MARGIN-TOP: 20PX` (sic) on the five-class email
 *     selector — (0,5,1), and applying to exactly one field on the site.
 *
 * Both are the shape CLAUDE.md records for `span.close-popup` and the gallery
 * arrows: a rule that looks correct, passes review, and does nothing — except
 * here it was the *winning* rule that was wrong, so the losing one read as
 * sloppy spacing rather than as a cascade bug. **Escalating specificity here
 * would have hidden them.** `margin-block: 0` stays as the single declaration
 * that owns the control's vertical margin. */
.ww-field span.wpcf7-form-control-wrap {
  display: block;
}

.ww-field span.wpcf7-form-control-wrap input.wpcf7-form-control,
.ww-field span.wpcf7-form-control-wrap textarea.wpcf7-form-control {
  display: block;
  width: 100%;
  margin-block: 0;
  padding-bottom: var(--ww-space-2);
  font-size: 1rem;
  line-height: 1.5;
}

/* Controls sized for a form, not for prose.
 *
 * They inherited the page's body scale — 18.9px text on a 30.2px line — which
 * made every field 40px tall before its 2px rule. A form is a dense control
 * surface; it does not want paragraph leading.
 *
 * **16px is a floor, not a preference.** Mobile Safari zooms the viewport when
 * a focused control has a font smaller than 16px, and does not zoom back out
 * afterwards — so a 15px input costs the buyer their place on the page. The
 * compaction comes out of the leading and the padding instead.
 *
 * `line-height` is unitless so the phone field, which intl-tel-input wraps and
 * re-parents, resolves it against its own size rather than inheriting a
 * computed px value from an ancestor.
 *
 * `rows="3"` on the comment field resolved against the old 28px leading, so the
 * textarea kept its height once the line-height came down; the min-height is
 * what actually shortens it. */
.ww-field span.wpcf7-form-control-wrap textarea.wpcf7-form-control {
  min-height: 4.5rem;
}

/* The submit was 62px of padding-driven height at the page's body size. It stays
 * well above the 24px WCAG 2.5.8 asks of a pointer target — 52px measured —
 * and keeps its full width.
 *
 * `input.wpcf7-form-control.wpcf7-submit.has-spinner` is (0,3,1) and CF7 ships
 * it, so a `.contact-page-block-form_item .wpcf7-submit` rule at (0,2,0) loses
 * — the first attempt here did, and the button stayed 62px while the CSS read
 * correctly. Naming `form` and the two CF7 classes takes this to (0,3,2). This
 * one IS fought on specificity rather than fixed at source, because the rule it
 * beats is a legitimate button style, not a stray spacer. */
.contact-page-block-form_item form input.wpcf7-form-control.wpcf7-submit,
.popup form input.wpcf7-form-control.wpcf7-submit {
  padding: var(--ww-space-3) var(--ww-space-5);
  font-size: 1rem;
  line-height: 1.5;
}

/* The consent line's own spacing is tightened in `cust.css`, where the rule
 * that owns it lives (`label.policy-label`, (0,1,1)). A `.policy-label` rule
 * here would be (0,1,0) and lose — which is what the first attempt did. */