/* css/field.css — forms: fields, inputs, the file input, errors, the derivation line, a form above a table.
   One of the files src/index.html links in order; see tokens.css for why. */

/* ==========================================================================
   Forms
   ==========================================================================
   EVERY field border uses --rule-strong (3.3:1). --rule would be 1.4:1 and
   would fail WCAG 1.4.11 on a control that carries meaning.
   ========================================================================== */
fieldset{border:0;padding:0;margin:0 0 var(--gap)}
legend{padding:0;margin-bottom:.4rem;font-weight:700;font-size:1rem}

.field{margin-bottom:25px}
.field > label,.field > .field-label,.field-label-row > label{
  display:block;font-weight:600;font-size:1.0625rem;margin-bottom:.3rem;
}
/* The label and its "?" on one line. margin-bottom moves to the row so the two
   do not disagree about the gap under them. */
/* Row-gap only. The column gap before the "?" is the button's own margin — see
   .hint-toggle — so that the button spaces itself in every parent, not just the
   two that are flex rows. The row gap stays: this row wraps. */
.field-label-row{display:flex;align-items:baseline;gap:.4rem 0;flex-wrap:wrap}
.field-label-row > label{margin-bottom:0}
.field-label-row + .hint-panel,legend + .hint-panel{margin-bottom:.35rem}
.field .help{margin-bottom:10px}

/* input[type=search] IS IN THIS LIST BECAUSE IT WAS NOT. Every table's search box
   is one, and being absent from the shared rule left it with the user-agent's own
   styling: 21px tall against a 24px minimum tap target (WCAG 2.5.8), a different
   border from every other field on the screen, and none of the intrinsic-width
   fix below. Found by the Part 0 screenshot pass, which measures; the UI suite
   cannot, because jsdom has no layout. */
input[type=text],input[type=email],input[type=password],input[type=date],
input[type=search],
input[type=number],input[type=file],select,textarea{
  width:100%;font-family:inherit;font-size:1rem;color:var(--ink);
  background:var(--field);
  border:1.5px solid var(--rule-strong);
  border-radius:var(--r-sm);
  padding:.55rem .65rem;
  box-shadow:var(--inset);
  /* ---- THE MOBILE OVERFLOW FIX -----------------------------------------
     `width:100%` is not enough on its own and never was. A control has an
     INTRINSIC minimum width — for a date input that is the widest the browser's
     own dd/mm/yyyy spinner can be, which on iOS is wider than a 390px phone's
     content column once the card padding is taken off. `width:100%` resolves
     against the container, `min-width:auto` then overrides it, and the input
     sticks out past the card. Everything downstream of that is the symptom
     people actually report: the page scrolls sideways, the topbar goes with it.

     max-width:100% caps it and min-width:0 lets it be capped. Both are needed:
     min-width:0 alone allows shrinking below intrinsic, max-width:100% alone is
     still overridden by min-width:auto on a flex item.

     -webkit-appearance:none is the third: iOS gives date and number inputs a
     platform width that ignores the box entirely until the native appearance is
     switched off. It changes nothing on any other engine. */
  max-width:100%;
  min-width:0;
  -webkit-appearance:none;
  appearance:none;
  /* THE FLOOR — CIT-10. appearance:none also removes the height iOS Safari gave
     a date input, and an empty date input has no text of its own: 19px of box
     where every neighbour is ~39px. 2.5rem is what the other fields already
     compute to, so nothing moves; nothing can collapse below it. */
  min-height:2.5rem;
}
input[type=number],input[type=date]{font-family:var(--data)}
/* A flex or grid item defaults to min-width:auto and therefore refuses to shrink
   below its content. Every container that holds a control or a long unbroken
   string — a file folder number, an email address, a district id — needs this or
   the control's intrinsic width becomes the container's floor. */
.field,.row > *,.stack > *,.actions > *,.card-head > *,.grow,
.dl dd,.dl dt,.notice-body,.choice span,.req-text{min-width:0}
/* An email address or an id with no spaces in it is one long word, and a long
   word in a narrow column overflows rather than wrapping. */
.dl dd,.notice-body,.timeline .detail,td,.help,.policy{overflow-wrap:anywhere}
textarea{min-height:5.5rem;resize:vertical;line-height:1.5}
select{appearance:none;background-image:none;padding-right:.65rem}

/* USWDS: an input's width is a hint about its content — CIT-15. Maxima only:
   the width:100% above still fits them into a narrow card or a phone. */
input[type=number]{max-width:12ch}
input[type=date]{max-width:22ch}
select{max-width:56ch}
input[type=text]{max-width:60ch}
textarea{max-width:72ch}

/* Certificate upload: A VISIBLE FILE INPUT, ALWAYS. Never drag-only
   (WCAG 2.1.1, and a hard rule in the brand spec). There is no drop zone in
   this product at all — not as an enhancement, because the enhancement is
   invariably what gets styled and the input is what gets hidden. */
input[type=file]{
  padding:.45rem;cursor:pointer;background:var(--field);
  /* THE APPEARANCE RESET ABOVE IS UNDONE HERE, deliberately. `appearance:none`
     on a file input removes the "Choose file" button in WebKit, and a file input
     with no visible button is the drag-only control this product forbids outright
     (WCAG 2.1.1, and a hard rule in the brand spec). The overflow fix does not
     need it here anyway — a file input has no intrinsic spinner width. */
  -webkit-appearance:auto;appearance:auto;
}
input[type=file]::file-selector-button{
  font-family:inherit;font-weight:600;font-size:.875rem;
  border:1.5px solid var(--rule-strong);border-radius:var(--r-sm);
  background:var(--paper);color:var(--ink);padding:.35rem .6rem;margin-right:.6rem;cursor:pointer;
}

/* Checkbox / radio groups — mandatory areas, credit units, capabilities. */
.choices{display:flex;flex-direction:column;gap:.4rem}
.choices--inline{flex-direction:row;flex-wrap:wrap;gap:.5rem 1.1rem}


/* Invalid field: red border AND a text message naming the field and the fix.
   Color alone would fail 1.4.1; the message is required by 3.3.1. */
[aria-invalid="true"]{border-color:var(--rejected);border-width:2px}
.field-error{
  display:flex;gap:.4rem;align-items:flex-start;
  margin-top:.35rem;color:var(--rejected);font-size:.875rem;font-weight:600;
}
.field-error .glyph{font-family:var(--data);flex:0 0 auto}

/* The derived-hours line under the credits field: never a number without its
   working. */
.derivation{
  margin-top:.45rem;padding:.5rem .65rem;
  border:1.5px solid var(--rule-strong);border-radius:var(--r-sm);
  background:var(--paper);
}
.derivation .figure{font-family:var(--data);font-weight:600;font-size:1.0625rem}
.derivation .working{display:block;font-family:var(--data);font-size:.75rem;color:var(--ink-soft);margin-top:.15rem}
.derivation--missing{border-color:var(--pending);color:var(--pending)}

/* ==========================================================================
   A form that opens ABOVE a table, inside the same card
   ==========================================================================
   "Start a batch" on the filing desk. Its submit button was landing about six
   pixels above the table's own search box, so "Open this batch" and "Search"
   read as one strip of controls — and they have nothing to do with each other:
   one opens a filing, the other looks through rows. A person aiming for one hit
   the other.

   A RULE RATHER THAN MORE AIR, because the toolbar directly below already ends
   in one and two bands of whitespace with a boundary between them is what the
   rest of this stylesheet uses to say "these are separate things". --rule-strong
   here rather than --rule: this line carries meaning (WCAG 1.4.11 is about
   controls, but the reasoning is the same — a boundary nobody can see is not a
   boundary).
   ========================================================================== */
.form-above-table{
  padding-bottom:var(--gap-lg);
  margin-bottom:var(--gap-lg);
  border-bottom:1px solid var(--rule-strong);
}
/* .actions already carries a top margin; a second one at the foot of the form
   would put the rule twice as far from the button as the button is from the
   field, which reads as the rule belonging to the table rather than to the form. */
.form-above-table .actions{margin-bottom:0}
