/* THE DATE CONTROL FAMILY — prev / value / next, and the date field itself.

   IT LIVES HERE RATHER THAN IN app.css FOR THE REASON static/dropdown.css
   does: templates/scheduling/crew_sheet.html is a DOCUMENT, not an app page.
   It is one self-contained file with its own @page rules and its own
   hand-written toolbar, and it deliberately loads no app.css — app.css paints
   a dark application over the whole viewport and a crew sheet has to print
   onto white paper. Its toolbar is also where the owner reported this
   (2026-09-04): [◀] [date] [▶] read as three unrelated controls, with the
   arrows rounded and 2px shorter than the box between them. Fixing it there
   and in the modals separately would be two date controls to keep in
   agreement, which is how they stop agreeing.

   EVERY COLOUR IS A TOKEN WITH A FALLBACK. On an app page the tokens come
   from app.css's :root and follow the light/dark theme; in the document
   nothing defines them, so each falls back to the dark palette's own value —
   which is right, because that toolbar is the same near-black the app is. The
   fallbacks are copies and are pinned to app.css by test
   (tests/test_date_controls.py) so they cannot drift silently.

   THE NUMERIC STEPPER IS IN HERE TOO, and that is deliberate rather than
   scope creep. − [ 6 ] + and ◀ [Wed 23 Sep] ▶ are the same control with a
   different value in the middle, they share the .stepper class already, and
   in every modal they sit side by side in one .frow2 row. Styling only the
   date half would have put two different-looking groups a gap apart.

   WHAT IS NOT IN HERE: the board's ◉ Today, which scrolls the grid rather
   than changing a date, and the calendar's Today, which is a jump rather than
   a step. Both stay .btn sm — a step group is prev/value/next, and hanging a
   fourth unrelated thing off it would make the group mean less. */

/* ---- the group ---------------------------------------------------------
   ONE BORDER ROUND THE WHOLE THING, which is the entire fix. Each of the
   three parts used to carry its own — .stepbtn had a full border, the input
   had top and bottom only, and the crew sheet's arrows had a 3px radius that
   nothing else in this square-cornered app has — so a control that is one
   idea was drawn as three. The parts are transparent now and the group holds
   the edge, so it lights up as a unit on focus. */
.stepper {
  display: inline-flex; align-items: stretch;
  background: var(--panel-2, #171c26);
  border: 1px solid var(--line, #232a38);
  font-family: var(--sans, Inter, "Segoe UI", system-ui, -apple-system, sans-serif);
}
.stepper:hover { border-color: var(--line-2, #2c3547); }
/* focus-WITHIN, not :focus — tabbing to either arrow or into the date box has
   to light the same edge, because what has focus is the control, not a third
   of it. Same gold-on-open the dropdown's button uses. */
.stepper:focus-within { border-color: var(--gold-deep, #a87a24); }

/* ---- the arrows, and − / + ---------------------------------------------
   Quiet by default: --text-faint is the caption tier, so the value beside
   them is the thing the eye lands on. That is the brief — "the date should
   remain the visual focus, not the arrow buttons".

   Sized in one place for <button> and <a> alike. The modals step a date in
   JavaScript so theirs are buttons; the crew sheet and the calendar step by
   navigating, so theirs are links and must not pick up the underline and
   gold that .toolbar a and the app's link colour would otherwise give them. */
.stepbtn {
  display: flex; align-items: center; justify-content: center;
  min-width: 22px; padding: 0 6px;
  background: none; border: 0; margin: 0;
  color: var(--text-faint, #7b8593);
  font: inherit; font-size: 12.5px; line-height: 1;
  text-decoration: none; cursor: pointer;
}
.stepbtn:hover {
  background: var(--raised, #1d2330);
  color: var(--text, #e8e6e1);
}
/* KEYBOARD USERS GET A VISIBLE MARK. The group's edge going gold says the
   control has focus but not which end of it, and these are two different
   actions. :focus-visible rather than :focus so a mouse click does not leave
   an arrow lit behind it. */
.stepbtn:focus-visible {
  outline: none;
  background: var(--raised, #1d2330);
  color: var(--gold-ink, #e3a93b);
}
/* ◀ and ▶ are solid triangles and read far heavier than − and + at the same
   size, so the date variant sets them smaller to arrive at the same weight.
   Not a seventh type size: these are glyph mass, not text. */
.stepper.dstep .stepbtn { font-size: 10px; }

/* ---- the value ---------------------------------------------------------
   .stepval had NO RULE OF ITS OWN anywhere in the app until now — it was a
   bare <span> between two bordered buttons, which is the "loose date text"
   in the report. It and an <input> are the same slot and are styled as one,
   so a group reads identically whether its value is typed or computed. */
/* SCOPED to .stepper rather than left bare, and not for tidiness: the crew
   sheet's own toolbar carries a `.toolbar input` rule of its own, and a bare
   `.stepval` would lose the tie to it whichever file loaded last. Two classes
   beat a class and an element, so this wins wherever it is loaded. */
.stepper .stepval,
.stepper input {
  flex: 1 1 auto; min-width: 0; width: auto;
  background: none; border: 0; margin: 0;
  padding: 4px 8px;
  color: var(--text, #e8e6e1);
  font: inherit; font-size: 12.5px;
  text-align: center;
  /* dates and counts are columns of digits; proportional figures make a
     stepped value shuffle sideways as the numbers change */
  font-variant-numeric: tabular-nums;
}
/* app.css pins input[type="number"] to 74px and input[type="date"] inherits
   the root input width — both at the same specificity as .stepper input, and
   this file loads FIRST so the tie would go to app.css. Spelled out rather
   than reordered: inside a group the value fills the group.

   A NUMBER NEEDS A REAL WIDTH, not auto: an <input type="number"> with no
   width falls back to its `size`, which is twenty characters, and the Weeks
   and Days groups would each be as wide as a sentence.

   AND IT MUST NOT KEEP THE OS SPINNER. The group already carries − and +, so
   Chrome's own up/down arrows are a second set of the same control drawn in
   the browser's style inside ours — the "chunky OS-looking" half of the
   report. The board's Weeks box had these switched off by a rule of its own
   (.weeksval); the modals' Days boxes never did, and showed both. */
.stepper input[type="date"] { width: auto; }
.stepper input[type="number"] {
  width: 56px;
  appearance: textfield; -moz-appearance: textfield;
}
.stepper input[type="number"]::-webkit-outer-spin-button,
.stepper input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none; margin: 0;
}
/* The group already shows focus on its own EDGE (:focus-within above), so a
   second border lighting up inside it is the fragmentation this is undoing.
   The crew sheet's toolbar has a `.toolbar input:focus` rule of its own that
   turns the box gold, and it ties with `.stepper input:focus` — so the value
   is named by its class as well, which wins outright rather than by load
   order. Focus stays visible either way: it is on the group. */
.stepper .stepval:focus,
.stepper input:focus { outline: none; border-color: transparent; }
/* HOLD THE WIDTH STEADY. "Wed 3 Sep" and "Thu 24 Sep" differ by two
   characters, so without a floor the whole group — and anything after it in
   the row — twitches sideways on every press of an arrow. */
.stepper.dstep .stepval { min-width: 104px; }

/* ---- a date on its own, with no arrows ---------------------------------
   Exports' Date, the noticeboard's "until", the calendar event's Date, a
   production's start date. These are FIELDS rather than navigation, so they
   keep the native picker — replacing four working date inputs with a
   JavaScript calendar would be a much larger promise than the one being made
   here — but the chrome the browser draws inside them is toned to sit with
   the caret every <select> in the app now draws.

   OPACITY RATHER THAN A FILTER, and that is what makes it theme-safe: the
   glyph is already drawn light-on-dark or dark-on-light by color-scheme, so
   fading it works in both, where a hard-coded colour would only ever suit
   one. */
input[type="date"] { font-variant-numeric: tabular-nums; }
input[type="date"]::-webkit-calendar-picker-indicator {
  opacity: .45; cursor: pointer;
}
input[type="date"]:hover::-webkit-calendar-picker-indicator { opacity: .85; }
input[type="date"]:focus::-webkit-calendar-picker-indicator { opacity: 1; }