/* Form controls — inputs and the buttons beside them.
 *
 * A text input carried the same eight colour utilities at every site: a ground,
 * a border, a text colour, a placeholder, a focus ring, a focus border, and
 * dark-mode twins for most of them. That is a component, not eight decisions,
 * and it was copied into every form in the product.
 *
 * The focus ring is the clearest case. Four utilities always travelled
 * together — the ring and the border, each with a dark-mode duplicate that set
 * the SAME colour — because a utility cannot say "this colour, in both
 * schemes". One rule here says it once.
 *
 * Layout stays in the markup: width, padding and radius are per-site choices
 * and name nothing worth naming. Only what the control looks like moves here.
 */

/* Text inputs, selects, textareas ------------------------------------------ */

.field-input {
    display: block;
    width: 100%;
    padding: 0.625rem; /* p-2.5 */
    border-width: 1px;
    border-style: solid;
    border-radius: 0.5rem; /* rounded-lg; the design system asks for 6-8px */
    font-size: var(--fs-base); /* text-sm */
    line-height: 1.25rem;
    background-color: var(--bg-page);
    border-color: var(--border-medium);
    color: var(--fg-1);
}

/* The markup keeps Tailwind's `focus:ring-*` sizing utilities for the ring
 * geometry; only the colour belongs to the design system. Tailwind's ring reads
 * this variable, so setting it replaces the shade without changing the shape.
 */
.field-input:focus {
    border-color: var(--focus-ring);
    --tw-ring-color: var(--focus-ring);
}

/* Buttons ------------------------------------------------------------------ */

/* Field group -------------------------------------------------------------
 * The wrapper and label around a control. Both existed only as utilities
 * written at each site — `space-y-2` on the wrapper (30 uses) and a five-class
 * blob on the label (14 uses) — while the macro emitted an unstyled `.field`
 * and a smaller, lighter label, which is one reason adopting it would have
 * restyled every form it touched.
 *
 * These reproduce what the live markup renders, so a macro-rendered field and
 * a hand-rolled one are identical and the migration is a no-op.
 */

/* Equivalent to Tailwind's space-y-2: the gap between label and control.
 *
 * Deliberately NOT `.field`. That class already exists in this tree as the
 * Semantic-UI-style wrapper used by the key, collector and tag modals, whose
 * labels get their spacing from `.ui.form .field label { margin-bottom }` in
 * section-improvements.css. Styling `.field` here added a second 8px to every
 * one of those groups — measured, not assumed: the label is display:inline
 * there, so nothing collapses the two margins together.
 */
.form-field > * + * {
    margin-top: 0.5rem;
}

.field-label {
    display: block;
    font-size: var(--fs-base); /* text-sm */
    line-height: 1.25rem;
    font-weight: 500; /* font-medium */
    color: var(--fg-1);
}

/* Element variants ----------------------------------------------------------
 * A select and a textarea are the same control as a text input, with two
 * differences worth naming: a select needs room for the chevron the browser
 * draws, and a textarea needs a floor height and a sane resize axis.
 */
/* Filter rows -------------------------------------------------------------
 * .field-input is width:100% because a stacked form field fills its column.
 * A control in a filter row does not: as a bare flex child, width:100% makes
 * every select claim the whole row and wrap onto its own line. The search box
 * beside them already opts into flex-1, so only the fixed-width controls need
 * to say so.
 */
.field-input--auto {
    width: auto;
}

/* A field with a glyph sitting inside its left edge. The offset was written as
 * an inline padding-left at each of the three search boxes. */
.field-input--with-icon {
    padding-left: 2.5rem;
}

select.field-input {
    padding-right: 2rem;
    cursor: pointer;
}

textarea.field-input {
    min-height: 5rem;
    resize: vertical;
}

/* States --------------------------------------------------------------------
 * Disabled reads as inert rather than merely faint: a greyed control the user
 * can still focus is worse than one that clearly cannot be typed into.
 *
 * The invalid state keys off aria-invalid rather than a class, so the thing
 * that tells a screen reader the field is wrong is the same thing that colours
 * it — they cannot drift apart. Nothing in the tree marks validation up yet;
 * this is here so that when it does, the appearance already exists.
 */
.field-input:disabled,
.field-input[readonly] {
    background-color: var(--bg-page);
    color: var(--fg-5);
    cursor: not-allowed;
}

.field-input[aria-invalid="true"] {
    border-color: var(--danger-fg);
}

.field-input[aria-invalid="true"]:focus {
    border-color: var(--danger-fg);
    --tw-ring-color: var(--danger-fg);
}

/* Supporting text -----------------------------------------------------------
 * Hint sits under a control and explains it; error replaces the hint when the
 * field is wrong. Both are one step down in size from the label.
 */
.field-hint {
    display: block;
    font-size: var(--fs-sm);
    line-height: 1rem;
    color: var(--fg-4);
}

.field-error {
    display: block;
    font-size: var(--fs-sm);
    line-height: 1rem;
    color: var(--danger-fg);
}

/* Checkbox and radio --------------------------------------------------------
 * accent-color paints the native control, so the box keeps the platform's own
 * focus, keyboard and high-contrast behaviour instead of a div pretending to
 * be a checkbox.
 */
.field-check {
    width: 1rem;
    height: 1rem;
    accent-color: var(--color-brand-green);
    cursor: pointer;
}

.field-check:disabled {
    cursor: not-allowed;
    opacity: 0.6;
}

/* On a dark ground ----------------------------------------------------------
 * The auth pages sit on a dark surface, where the light field is unreadable.
 * This is the same control, inverted — deliberately without the blur and the
 * centred text the old auth input carried, which are decoration rather than
 * design-system decisions.
 */
.field-input--on-dark {
    background-color: color-mix(in srgb, var(--fg-on-dark) 6%, transparent);
    border-color: var(--fg-3);
    color: var(--fg-on-dark);
}

.field-input--on-dark::placeholder {
    color: var(--fg-5);
}

.field-label--on-dark {
    color: var(--fg-on-dark);
}

/* No dark-mode block here, deliberately. @media (prefers-color-scheme: dark)
   is not opt-in: it fires from the viewer's OS, so on a dark desktop it
   repainted every form control dark-grey with white text while every other surface stayed light. The same
   mistake was already made and documented in table-header.css, whose block was
   deleted for this reason — real dark mode means a full second palette and a
   deliberate toggle, not per-component overrides. */

/* A checkbox whose choice weakens a policy, so it wears the warning tone
   rather than the brand green .field-check gives every other box. It was
   accent-amber-600 at three call sites — Tailwind's ramp overriding the
   component's own accent-color, which is the component losing an argument
   with the markup three times over. */
.field-check--warning {
    accent-color: var(--status-warning-fg);
}