/* =============================================================================
   choice.css — checkboxes and radios, single and grouped.

   Separate from forms.css for the same reason select.css and date.css are: that
   file describes the field frame and the text-entry controls, and these are a
   different kind of control with their own states. The frame's two new LAYOUT
   modifiers (--inline, --grouped) stay in forms.css, because the frame owns them.

   THE APPEARANCE IS THE NATIVE CONTROL, RECOLOURED — not a hidden input with a
   drawn box beside it. That is the usual approach and it costs more than it looks:
   the drawn box has to reimplement focus, disabled, hover and the check glyph, and
   it loses `indeterminate` outright, which is the one state HTML can express only
   as a JS property. `accent-color` gets all of that for one declaration, keeps the
   platform's own focus ring and hit target, and needs no JavaScript at all — which
   matters here, because these controls are static SSR and must be fully usable
   before (and without) any script.

   Semantic tokens only — DesignTokenTests enforces it.
   ========================================================================== */

/* -- the control ------------------------------------------------------------ */

.hrc-choice__input {
  /* Fixed square. A checkbox that inherits the field height would be a 40px box. */
  inline-size: var(--hrc-choice-size);
  block-size: var(--hrc-choice-size);

  /* Stops the box shrinking when the label beside it wraps to several lines. */
  flex: none;

  /* Recolours the check/dot and the filled background in both themes. The token is
     semantic, so a theme rebinding --hrc-accent recolours these with everything
     else and no rule here has to know which theme is active. */
  accent-color: var(--hrc-accent);

  cursor: pointer;
}

.hrc-choice__input:disabled {
  cursor: not-allowed;
  /* The platform already greys a disabled control; this dims the whole pairing so
     the label goes with it rather than staying full-contrast beside a grey box. */
  opacity: 0.55;
}

.hrc-choice__input:focus-visible {
  outline: var(--hrc-focus-ring);
  outline-offset: var(--hrc-focus-offset);
}

/* -- the label beside it ---------------------------------------------------- */

.hrc-choice__label {
  font-size: var(--hrc-density-text);
  color: var(--hrc-ink);
  line-height: var(--hrc-leading-tight);
  cursor: pointer;
  min-inline-size: 0;
}

.hrc-choice__input:disabled + .hrc-choice__label {
  color: var(--hrc-ink-subtle);
  cursor: not-allowed;
}

/* -- one option ------------------------------------------------------------- */

.hrc-choice {
  display: flex;
  align-items: baseline;
  gap: var(--hrc-space-xs);
  min-inline-size: 0;
}

/* -- a group of them -------------------------------------------------------- */

.hrc-choice-group {
  display: flex;
  flex-direction: column;
  gap: var(--hrc-space-xs);
  min-inline-size: 0;
}

/* -- invalid ----------------------------------------------------------------
   A text field shows a failure as a red BORDER; a native checkbox has no border
   to colour, so the ring goes outside it. It is only ever the second signal:
   the field's error message says what is wrong in words, because colour may
   never carry meaning on its own (WCAG 1.4.1).

   :not(:focus-visible) so the error ring never fights the focus ring — a focused
   invalid control shows focus, which is the more urgent of the two. */

.hrc-field--invalid .hrc-choice__input:not(:focus-visible) {
  outline: 2px solid var(--hrc-crit);
  outline-offset: var(--hrc-focus-offset);
}

/* MID-CORRECTION — the same third state every other control has. Neutral, never
   green: the server has not spoken since the failure, so the only honest claim is
   "changed since the error". forms.js sets the class by comparing the group's
   current answer with the one that failed. */
.hrc-field--correcting .hrc-choice__input:not(:focus-visible) {
  outline-color: var(--hrc-border-strong);
}