/* --------------------------------------------------- */
/*                    SHARED PAGE BASE                  */
/* --------------------------------------------------- */
/* The small handful of truly page-agnostic base rules the homepage
   (styles/styles.css) and the tasks page (tasks/styles/general.css) used to
   each keep their own separate, hand-copied version of — every time one
   needed a fix, someone had to remember to paste it into the other file
   too, which is exactly how the h2 rule below ended up missing entirely on
   the tasks page for a while. Anything here is either byte-identical
   between the two pages already, or was folded into one shared rule
   because the only difference was an accidental drift (the font-weight
   list below). Each page's own base stylesheet still owns everything that
   ONLY makes sense there — its own :root color palette, `body`'s own
   background/layout, and the couple of properties (see general.css's own
   *:not(dialog) follow-up) that are deliberately different per page. */

/* The part of the universal reset that's identical on both pages — each
   page's own base stylesheet still carries its own *:not(dialog) rule for
   whatever it adds ON TOP of this (currently just the tasks page's own
   filter: contrast(1), general.css — see that rule's own comment for why).
   Kept as its own full selector here (not just a handful of shared
   declarations pasted into two different rules) so there's exactly one
   place that ever needs to change margin/padding/font-family/box-sizing
   for literally everything on either page. Has to come BEFORE the h2 rule
   below: :not(dialog) and a plain h2 tie in specificity (both a single
   type selector), so whichever comes later in this same file would
   otherwise win regardless of which one actually looks more specific —
   put after h2 once during an earlier reorganization, which silently
   cancelled h2's own padding back to 0 on every page until caught. */
*:not(dialog) {
  margin: 0;
  padding: 0;
  font-family: "Fira Code";
  box-sizing: border-box;
}

@font-face {
  font-family: "Fira Code";
  /* Relative to THIS file's own location (shared/styles/), unlike the two
     page-specific copies this replaces, which each needed their own
     ../ vs ../../ depending on how deep their own file lived. */
  src: url("webfonts/FiraCode-Light.woff2") format("woff2");
  /* A single static weight (this file only actually contains the Light
     cut) — the tasks page's own old copy of this rule listed
     "300, 400, 500" instead, which isn't valid syntax for a single
     @font-face's font-weight in the first place (that comma-list shape is
     only for a variable font's supported RANGE, declared as e.g. "300
     500" — space-separated, no comma). Harmless in practice (browsers
     just ignore the malformed value and fall back to loading the face for
     every weight anyway), but wrong regardless — fixed here rather than
     carried over. */
  font-weight: 300;
  font-style: normal;
  /* Default (font-display: auto/block) gives this ~100KB woff2 a short but
     real invisible-text window on a cold/slow load before falling back -
     this selector applies near page-wide (below), so that blank window
     isn't confined to one corner of the page. swap paints immediately in
     the fallback font instead, then swaps to Fira Code the instant it
     arrives - a visible font swap for a moment, but never blank text. */
  font-display: swap;
}

/* FontAwesome renders every glyph via a ::before sized smaller than its
   <i> parent and sitting flush against the BOTTOM of it, which reads as
   "every icon sits a few px too low next to its label" regardless of how
   a given button centers the <i> itself (flexbox or absolute
   positioning) — turning <i> into a flex container centers the ::before
   WITHIN it instead, composing cleanly with whichever outer technique is
   already in use. The `i` type selector (not just the class) is required
   to reliably beat FontAwesome's own same-specificity base rule
   regardless of <link> load order. */
i.fa-solid,
i.fa-regular,
i.fa-brands,
i.fas,
i.far,
i.fab {
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Fira Code ships ligatures for repeated/composite punctuation (".." and
   "..." merge into one narrower glyph, among others) — editable text
   controls apparently shape/rasterize that merged glyph differently (and
   worse) than plain read-only text does, to the point "..." can visibly
   read as only two dots while actually typing it, even though the
   read-only render of that exact same string looks correct. Disabled only
   on the controls you actually type into, so every character you type
   keeps showing as itself, while read-only views (task descriptions, code
   blocks, ...) keep the full ligature set. */
input,
textarea,
select {
  font-variant-ligatures: none;
  font-feature-settings: "liga" 0, "calt" 0;
}

/* Every checkbox on either page renders as a plain native control (accent-color
   alone for the checked fill, no appearance: none/custom box) - fine on its
   own, but both pages' own html now hints color-scheme: dark for the
   BROWSER's native UI (index.html's inline <head> style/--ui-color-scheme,
   styles.css - scrollbars, the native date/color pickers, etc.), which also
   makes an unstyled checkbox's own UNCHECKED inner square switch to whatever
   dark fill the browser substitutes for white in its dark native-control
   palette - confirmed as a real, reported regression (checkboxes used to be
   white before color-scheme was ever set anywhere). Pinned back to light
   here, checkbox-only (not undoing color-scheme: dark anywhere else, which
   is deliberately still wanted for scrollbars/date-pickers/etc.) - a
   descendant's own color-scheme always wins over what it inherits, so this
   is a real, permanent override, not just first-paint's own temporary hint. */
input[type="checkbox"] {
  color-scheme: light;
}

/* The generic "header bar" look for every <h2> on either page — currently
   both pages' own Settings-style dialogs/panels and every .confirm-dialog-
   title (shared/styles/backup.css). Missing entirely on the tasks page
   until this file existed, which is what silently left its own confirm
   dialogs (upload/tag-delete/task-delete) with a plain, unstyled browser-
   default title instead of this gradient-backed bar. */
h2 {
  position: relative;
  text-align: center;
  min-height: 42px;
  width: 100%;
  padding: 5px 10px;
  user-select: none;
  background: linear-gradient(
    to top,
    var(--secondary-color) 0%,
    var(--main-theme) 0%,
    var(--main-theme-darker) 80%
  );
  border-bottom: 1px solid
    color-mix(in srgb, var(--secondary-color) 40%, transparent);
  border-radius: 10px;
  font-size: 18px;
  color: var(--font-color-clear);
  box-shadow: 0px 8px 12px rgba(0, 0, 0, 0.5);

  display: flex;
  align-items: center;
  justify-content: center;
}
/* An <h2> swapped in-place for an inline-rename (e.g. renameContainer,
   updateContainers.js) — transparent so the parent h2's own gradient
   background still shows through underneath it. */
h2 > input {
  width: 100%;
  border: none;
  outline: none;
  cursor: var(--cursor-text, text);
  color: var(--font-color-clear);
  background: transparent;
  font-size: 18px;
  font-weight: bold;
  text-align: center;
  border-radius: 10px;
}

/* Just the thumb — each page's own base stylesheet keeps its own
   ::-webkit-scrollbar/::-webkit-scrollbar-track (they genuinely differ:
   different width/height, and the tasks page's track is a gradient where
   the homepage's is a flat color), but the thumb itself has always been
   identical on both. */
::-webkit-scrollbar-thumb {
  background: var(--font-color);
  border-radius: 8px;
  /* Same draggable-control treatment as the range-slider thumb
     (input[type="range"]::-webkit-slider-thumb, styles.css/
     readTaskPanel.css) — spec-correct and harmless either way, but
     confirmed NOT currently honored by Chromium/WebKit's own native
     scrollbar hit-testing (hovering/dragging the real thumb still shows
     the OS's own arrow regardless, RS mode active or not) — native
     scrollbar cursor is apparently not something this rule can actually
     control today. Left in rather than removed in case that ever changes,
     or on an engine that does respect it. Only a genuinely custom
     (non-native, JS-positioned) scrollbar thumb could show a real custom
     cursor here. */
  cursor: var(--cursor-pointer, pointer);
}
::-webkit-scrollbar-thumb:hover {
  background: var(--secondary-color);
}