/* NEW TIME override: dim the inputs it supersedes, highlight the active source */
td.input-cell.src-inactive{background:repeating-linear-gradient(135deg,transparent,transparent 5px,var(--hatch) 5px,var(--hatch) 10px)}
td.input-cell.src-inactive input{color:var(--muted);text-decoration:line-through;opacity:.55}
td.input-cell.src-active{background:var(--liftbg);box-shadow:inset 0 0 0 1px var(--accent)}
td.input-cell.src-active input{color:var(--lifttext);font-weight:700}
td.calc{background:var(--ro);color:var(--rotext)}
td.rmk{text-align:left;min-width:100px}
td.rmk input{text-align:left;width:100%}
/* ATC nav-log ladder: waypoint cells (name/description/coord) are offset half a row from
   the leg cells, so each waypoint owns its own cell straddling two legs. */
/* Waypoint cells take NO tint of their own. They used to carry --panel2 to mark them as a
   different kind of object, but the stagger and the cell borders already say that, and the
   extra shade meant the staggered column ran a half-step off every band beside it. Now an
   unbanded waypoint matches an unbanded leg cell and a banded one matches a banded leg
   cell, so a leg and its destination read as one block. */
#navSections .navTable td.wpcell{vertical-align:middle}
#navSections .navTable td.wpcell input{width:100%;text-align:center}
#navSections .navTable td.navnum{font-weight:700;color:var(--muted)}
#navSections .navTable td{vertical-align:middle}
/* A banded waypoint — the "TO" cell of a banded leg — carries that leg's shade, so the
   zebra runs unbroken from the leg row down through the stagger beneath it (see
   wpBanded()). This must OUTRANK the flat .wpcell tint above on specificity (2,2,1 beats
   2,1,1) rather than on source order: the two ladders declare their .wpcell rules in
   different places, and an order-dependent rule silently banded one table and not the
   other. Everything meaningful still outranks THIS in turn — .depcell.dep-set matches at
   the same weight but is declared later, and the hover highlight is !important — so a
   landed waypoint and a lit leg both keep their colour. */
#navSections .navTable td.wpcell.navband,#fuelSections .fuelTable td.wpcell.navband{background:var(--navband)}
/* RMK carries a free-text note and is the widest thing a pilot types on either ladder.
   Giving it room is the difference between reading a remark and scrolling one. The rule
   is a min-width, not a fixed width, so a narrow phone can still shrink it — see the
   phone override further down, which relaxes it rather than fighting it. */
/* :not(.wpcell) matters — FROM/TO, DESCRIPTION and COORD also carry .rmk for their
   left-aligned text, and widening those too would push the numbers off a narrow screen.
   Only the remark column itself, on either ladder, gets the extra room. */
#navSections .navTable th.rmkcol,#navSections .navTable td.rmk:not(.wpcell),
#fuelSections .fuelTable th.rmkcol,#fuelSections .fuelTable td.rmk:not(.wpcell){min-width:170px}
/* On a phone both ladders already scroll sideways, so a wide RMK costs sideways travel
   on every other column too. Fall back to the old 100px there: the note is still legible,
   and the numbers stay reachable with less scrolling. */
@media(max-width:640px){
  #navSections .navTable th.rmkcol,#navSections .navTable td.rmk:not(.wpcell),
  #fuelSections .fuelTable th.rmkcol,#fuelSections .fuelTable td.rmk:not(.wpcell){min-width:100px}
}
/* Centre every input in the Navigation Log, and the RMK / FROM-TO inputs on the OFP page. */
#navSections .navTable td.input-cell input{text-align:center}
#fuelSections .fuelTable td.rmk input{text-align:center}
/* ONE type size across the whole Navigation Log. The global `input,select` rule is 14px
   while `table` is 13px, so the cells the pilot TYPES (FROM/TO, DESCRIPTION, COORD)
   rendered a size larger than the cells we CALCULATE (ARR, MIN, NM) — a size difference
   that reads as importance and isn't. font:inherit pulls the table's own 13px. It must
   stay ABOVE the .nav-hl rules below, which re-bold the highlighted leg. */
#navSections .navTable td.input-cell input{font:inherit;font-size:13px;line-height:1.2}
/* ---- DEP column (departure time out of each waypoint) ----
   iOS Safari refuses to size a native <input type="time"> from our CSS and gives it an
   intrinsic width built around its own picker chrome, which is wider than the column the
   auto-layout table hands it — so the value overflowed and was clipped by the ARR border
   ("15:00" lost its last digit on the iPad). Stripping the native appearance and the
   shadow-DOM buttons, then allowing the field to shrink (min-width:0), lets the value sit
   inside its own cell. min-width on the column keeps a floor under it. */
#navSections .navTable th.depcol{min-width:78px}
#navSections .navTable td.depcell{position:relative;min-width:78px}
/* ===== A CLOCK FIELD IN A NARROW BOX =====
   WebKit gives <input type="time"> an intrinsic width that includes its picker glyph, clear
   button and spin buttons, and REFUSES to go below it. `width:100%` and `min-width:0` do not
   help: in any container narrower than that intrinsic width it is the INPUT that overflows,
   so it either spills over its neighbour or, where the container clips, hides behind it. The
   glyph also sits to the right of the value, which pushes the digits off-centre.
   Stripping the native chrome is what lets the field shrink. `.clockfield` marks every place
   that needs it — the ATC nav log's DEP column, the duty log's times, and the start-time
   windows in the limits modal. It was written three times before it was written once, and
   each rediscovery cost an operator bug report. Anything that puts a time input in a table
   cell or a cramped grid wants this class. */
.clockfield{-webkit-appearance:none;appearance:none;font:inherit;min-width:0;text-align:center}
.clockfield::-webkit-date-and-time-value{text-align:center;margin:0;padding:0}
.clockfield::-webkit-calendar-picker-indicator,
.clockfield::-webkit-clear-button,
.clockfield::-webkit-inner-spin-button{
  display:none!important;-webkit-appearance:none;appearance:none;margin:0;width:0}
#navSections .navTable td.depcell input[type="time"]{
  font-size:13px;line-height:1.2;width:100%;padding:6px 2px;position:relative;z-index:1}
/* ---- Rolling-clock indicator ----
   The arrival clock ROLLS THROUGH a waypoint unless a departure time is entered there —
   the pilot overflew it rather than landing. That is correct behaviour but invisible: an
   empty box looks like an omission, not a decision. The DEP column is an unbroken strip of
   waypoint cells (each spans two half-rows and nothing else shares the column), so a
   full-height dashed line in every empty cell chains into ONE continuous dashed line
   running down the log. A departure time cuts that line with a solid accent block. The
   line is the running clock; the break is the landing. Nothing to memorise. */
#navSections .navTable td.depcell.dep-none::before{content:'';position:absolute;left:50%;top:0;bottom:0;
  margin-left:-1px;border-left:2px dashed var(--muted);opacity:.55;pointer-events:none}
#navSections .navTable td.depcell.dep-none input[type="time"]{color:var(--muted);opacity:.5}
#navSections .navTable td.depcell.dep-set{background:var(--liftbg);box-shadow:inset 0 0 0 1px var(--accent)}
#navSections .navTable td.depcell.dep-set input[type="time"]{color:var(--lifttext);font-weight:700}
/* Legend under the nav log — the two DEP states drawn exactly as they appear in the table. */
.navlegend{display:flex;flex-wrap:wrap;gap:6px 20px;margin-top:8px;padding:0 2px;
  font-size:11px;color:var(--muted)}
.navlegend span{display:inline-flex;align-items:center;gap:7px}
.navlegend i{display:inline-block;width:16px;height:15px;border:1px solid var(--line);
  border-radius:2px;position:relative;flex:0 0 auto}
.navlegend i.key-roll::before{content:'';position:absolute;left:50%;top:0;bottom:0;
  margin-left:-1px;border-left:2px dashed var(--muted);opacity:.7}
.navlegend i.key-set{background:var(--liftbg);border-color:var(--accent)}
/* Fixed, equal half-row height so the waypoint column staggers exactly midway; the two
   leftover corner half-cells are greyed out (hatched) rather than resized. 17px keeps the
   ladder tight — raising it only pads dead space around the inputs, which are
   content-height and vertically centred, so it buys legibility rather than tap area. */
/* Both ladders — ATC's nav log and the OFP fuel plan — are built the same way, so the
   half-row height, the hatched corner fills and the leg banding are shared rules. */
#navSections .navTable tbody tr,#fuelSections .fuelTable tbody tr{height:17px}
#navSections .navTable td.navfill,#fuelSections .fuelTable td.navfill{background:repeating-linear-gradient(135deg,transparent,transparent 5px,var(--hatch) 5px,var(--hatch) 10px)}
/* Leg banding. The generic tbody tr:nth-child(even) stripe cannot work in this layout:
   every cell spans two half-rows, so "even rows" resolves to *every* leg row and *no*
   waypoint row — uniform tint, zero alternation. Neutralise it here and band the legs
   explicitly by parity instead, so leg 1 and leg 2 never share a shade. */
#navSections .navTable tbody tr,#fuelSections .fuelTable tbody tr{background:none}
#navSections .navTable td.navband,#fuelSections .fuelTable td.navband{background:var(--navband)}
#navSections .navTable td.navband.calc,#fuelSections .fuelTable td.navband.calc{background:var(--navbandro)}
/* OFP waypoint cells: same treatment as the ATC ladder, so the FROM/TO column reads as
   the same object on both tabs. No tint of their own — see the note on the ATC rule. */
#fuelSections .fuelTable td.wpcell{vertical-align:middle}
#fuelSections .fuelTable td.wpcell input{width:100%;text-align:center}
#fuelSections .fuelTable td{vertical-align:middle}
/* Hover or tap a leg to light up the leg and the two waypoints it runs between —
   the same idea as the FDT rolling-window highlight. */
#navSections .navTable td.nav-hl,#navSections .navTable td.nav-hl-pin{background:var(--liftbg)!important;color:var(--lifttext)}
#navSections .navTable td.nav-hl input,#navSections .navTable td.nav-hl-pin input{color:var(--lifttext);font-weight:700}
#navSections .navTable td.navnum.nav-hl,#navSections .navTable td.navnum.nav-hl-pin{color:var(--accent);font-weight:800;
  box-shadow:inset 3px 0 0 var(--accent)}
#navSections .navTable td.wpcell.nav-hl,#navSections .navTable td.wpcell.nav-hl-pin{box-shadow:inset 0 0 0 1px var(--accent)}
#navSections .navTable tr td[data-navleg]{cursor:pointer}
td.lift{background:var(--liftbg);font-weight:700;font-size:14px;color:var(--lifttext)}
td.lift.ext{color:var(--extlifttext)}
td.lift.perf{color:var(--perflifttext)}
/* HESLO 4 (Quick Reference only). It is derived from PERFORMANCE, which is exactly why it
   needs a colour of its own — sharing the green made the two columns read as one figure
   printed twice, and the whole point of the column is that it is 10% below the other. */
td.lift.heslo{color:var(--heslolifttext)}
/* INT has no rule: internal structural is the plain `lift` colour, on this table and on the
   leg ladder both, so the two panels agree on what the column means. */
.neg{background:var(--badbg)!important;color:var(--negtext)!important;font-weight:800}
/* ===== Quick Reference =====
   Entry (3 columns) and answer (4 columns) as two separate tables rather than one wide
   one: nine columns across cannot be read one-handed on a phone, which is where this
   panel gets used. On a desktop they sit side by side; below 860px they stack, so the
   phone case gets full width per table without either ever scrolling sideways.
   Both use table-layout:fixed so columns divide the available width instead of being
   pushed wide by their contents. Cell padding and font sizes are inherited from the
   app's own table rules — this panel should look like the rest of the tool, not like a
   bigger, louder version of it. */