/* theme.css — dark palette for the Zavtek Portal.
   ─────────────────────────────────────────────────────────────────────────────
   Every page already declares the SAME token names in its own :root (--bg,
   --surface, --surface2, --border, --accent, --text, --muted, --dim, --green,
   --warning, --danger, --ok, --on-accent). So dark mode is one override block,
   not nine restyles, and tuning a colour later is one edit here.

   `:root[data-theme="dark"]` beats a bare `:root` on specificity, so this wins
   regardless of whether the page's inline <style> comes before or after the
   <link> — no load-order fragility.

   Built as a real dark palette rather than an inversion: a warm near-black that
   matches the light theme's warm greys, surfaces that step UP toward the viewer
   (the light theme steps down), and a lifted accent so blue stays legible on a
   dark field instead of vibrating against it. */

:root[data-theme="dark"] {
  --bg:        #16151a;   /* page — warm near-black, not pure #000 */
  --surface:   #1e1d23;   /* cards sit above the page */
  --surface2:  #26252c;   /* headers/wells sit above cards */
  --border:    #3a3841;

  --text:      #eceaf2;   /* soft white — pure #fff glares on dark */
  --muted:     #9c99a6;
  --dim:       #b8b5c0;

  --accent:    #5aa2f0;   /* lifted from #0b6bcb; the light-mode blue is too dark here */
  --on-accent: #10131a;   /* dark text on the lighter accent keeps contrast */

  --green:     #4ec97a;
  --ok:        #4ec97a;
  --warning:   #e0a83a;
  --danger:    #f0666f;

  /* index.html declares four tokens no other page does — 88 usages across that
     file. Without these they'd keep their light values and paint near-white text
     and hover rows onto a dark page. */
  --text-muted: #9c99a6;
  --text-dim:   #b8b5c0;
  --row-hover:  #2a2d38;   /* was #eef3fa — a blue-tinted WHITE row */
  --tag-bg:     #262b36;   /* was #e6eef8 */
}

/* Native controls (date pickers, selects, scrollbars) follow along — without this
   a dark page renders a blinding white calendar popup. */
:root[data-theme="dark"] { color-scheme: dark; }

/* A handful of places hardcode a light surface instead of using the token.
   Mapped here rather than editing nine files. */
:root[data-theme="dark"] [style*="#f4f2ec"],
:root[data-theme="dark"] [style*="#F4F2EC"] { background: var(--surface2) !important; }

/* battery_report: the SELECTED file row is hardcoded #eef3fa — a near-white block
   on a dark page, and it's the row a tech is actively looking at. */
:root[data-theme="dark"] .file-item.selected{ background: var(--surface2); color: var(--accent); }

/* The PDF preview iframe stays WHITE on purpose. A report renders on white paper,
   and tinting the preview would misrepresent the output. */
:root[data-theme="dark"] .pdf-modal iframe{ background: #fff; }

/* ── Translucent white bars ──────────────────────────────────────────────────
   The sticky chrome — nav, toolbars, and the service report's fixed action and
   progress bars — is painted with rgba(255,255,255,.92) rather than a token, so
   it stayed WHITE on a dark page. Same translucency, dark base, so the blur
   behind them still works.

   These were missed by the first audit because that scan only looked for HEX
   values; an rgba() white is the same mistake wearing a different notation. */
:root[data-theme="dark"] .topnav,
:root[data-theme="dark"] .toolbar,
:root[data-theme="dark"] .action-bar,
:root[data-theme="dark"] .progress-bar{ background: rgba(30,29,35,.94); }

/* Table row rules on BATNET's results table are a hardcoded light grey. */
:root[data-theme="dark"] #resultsTable tbody tr{ border-bottom-color: var(--border); }

/* Day row hover is a hardcoded #eef3fa — a near-white flash on the row a tech is
   pointing at, which is the worst place for it. Inherited from the old
   time-entries shell, so it affects My Tickets too.
   (Earlier scans excluded every :hover rule on the assumption they were all
   coloured-button hovers. Row hovers are the exception that assumption missed.) */
:root[data-theme="dark"] .day-head:hover{ background: var(--surface); }

/* NOT overridden on purpose: rgba(255,255,255,.1/.15/.18) inside #app-header,
   .nav-btn and .reconnect-prompt. Those are white overlays ON TOP of an already
   coloured (blue / red) surface — they read correctly in dark mode, and forcing
   them dark would flatten the element they're meant to lift. */

/* Toggle button — lives in the portal nav. */
.theme-toggle{
  appearance:none;background:var(--surface2);border:1px solid var(--border);
  color:var(--text);font-family:inherit;font-size:14px;line-height:1;
  width:34px;height:34px;border-radius:8px;cursor:pointer;
  display:inline-flex;align-items:center;justify-content:center;
  transition:border-color .15s,color .15s;
}
.theme-toggle:hover{border-color:var(--accent);color:var(--accent);}
.theme-toggle:focus-visible{outline:2px solid var(--accent);outline-offset:2px;}

/* ── iPhone safe area ────────────────────────────────────────────────────────
   Every page sets viewport-fit=cover, which extends the layout UNDER the status
   bar. index.html compensates with env(safe-area-inset-top); the sub-pages never
   did, so on an iPhone in portrait the clock and battery icons sit on top of the
   "Back to Portal" button and it can't be tapped.

   Scoped three ways so it cannot affect anything else:
     @supports — only browsers that HAVE safe-area insets
     env(...)  — resolves to 0px everywhere except a notched device, so on a
                 desktop or a non-notched phone this adds literally nothing
     max()     — never shrinks the bar below its designed height

   db_viewer uses a bare <nav> with no class; everything else uses .topnav. */
@supports (padding-top: env(safe-area-inset-top)) {
  /* Every page sets *{box-sizing:border-box}, so the declared height INCLUDES
     padding — the inset has to be added to the height too, or the padding would
     squash the bar's contents instead of moving them down.
     Heights are matched per page rather than assumed: .topnav is 56px on the
     seven pages that use it, db_viewer's bare <nav> is 54px. */
  /* `body .topnav`, not `.topnav`. Every sub-page declares `padding: 0 20px` on
     .topnav — a SHORTHAND, which resets padding-top to 0 — and because this
     stylesheet is linked in <head> BEFORE each page's inline <style>, the page
     won at equal specificity and the rule below did nothing.
     Adding `body` makes it (0,1,1) vs the page's (0,1,0), so it wins on
     specificity instead of relying on source order. */
  body .topnav {
    padding-top: env(safe-area-inset-top);
    height: calc(56px + env(safe-area-inset-top));
  }
  body > nav {
    padding-top: env(safe-area-inset-top);
    height: calc(54px + env(safe-area-inset-top));
  }
}