/* -------------------------------------------------------
                 FOCUS-VISIBLE (PROJECT-WIDE)
   ------------------------------------------------------- */
/* Replaces the browser's own default focus outline everywhere on both the
   homepage and the tasks page with one consistent treatment — border and
   text tinted --highlight, plus a small scale-up — so keyboard focus is
   always obvious no matter what element it lands on or how that element
   is otherwise styled. :focus-visible (not :focus) so a mouse click never
   triggers this, only actual keyboard navigation.

   !important is deliberate, not a shortcut: many elements across both
   pages already carry their own more specific color rules (the tasks
   page's #effort tier colors, category-colored chips, priority accents,
   ...) that would otherwise outrank this by plain specificity — focus
   should still win over all of them while the element actually has it.

   [tabindex]:focus-visible excludes dialog specifically — .icon-manager-dialog
   carries tabindex="-1" purely to be a valid PROGRAMMATIC focus target (the
   browser's own "no focusable descendant" showModal() fallback, or a click
   landing on non-interactive content inside one — see the bare `dialog`
   rule below for the full reasoning), never to be treated as a real
   keyboard-navigable control — without this exclusion, that tabindex alone
   made this rule's own !important outline win right back over
   dialog:focus-visible below (higher specificity: an attribute selector +
   pseudo-class beats a type selector + pseudo-class, regardless of
   !important on both sides) — confirmed as the actual reason
   .icon-manager-dialog kept showing an outline even after that rule was
   added. */
button:focus-visible,
input:focus-visible,
textarea:focus-visible,
select:focus-visible,
a:focus-visible,
[tabindex]:focus-visible:not(dialog) {
  outline: 2px solid var(--highlight) !important;
  border-color: var(--highlight) !important;
}
/* #createTaskSymbol and #description are the two exceptions to "focus color
   always wins" below — re-declares the same selector list with each
   excluded from its own matching clause and no color rule of its own,
   rather than setting some replacement value (color: inherit/unset would
   resolve to the wrapper's own static color, not what's actually meant to
   show through in either case). Keyboard focus still shows on both via the
   shared outline (and border-color) above — this only opts them out of the
   color override specifically.
   #createTaskSymbol's own color IS the current task's category color (set
   inline via JS: paintWithPickedColor/checkCategory/takeOverColor/editTask,
   tasks.js), more useful to keep visible while Tabbing through the form
   than a generic highlight tint would be.
   #description's own text is deliberately fully transparent all the time
   now (editTask.css) — the syntax-highlight overlay sitting behind it
   (#description-highlight, descriptionEditor.js) is what actually reads as
   "the text" at every other moment, but this rule's !important was
   overriding that transparency the instant the field gained keyboard
   focus, painting the real (until-now-invisible) text solid --highlight
   right on top of it and hiding the highlighted layer underneath entirely
   — confirmed as the actual cause of "focusing the textarea, its text
   turns yellow and the highlighting disappears". */
button:focus-visible,
input:focus-visible,
textarea:focus-visible:not(#description),
select:focus-visible,
a:focus-visible,
[tabindex]:focus-visible:not(#createTaskSymbol):not(dialog) {
  color: var(--highlight) !important;
}
/* .phone-edit-preview-tab.active (tasks/styles/editTask.css) is a plain
   two-button toggle whose OWN active/selected look (a solid --secondary-
   color fill, editTask.css) already unambiguously shows which tab is
   selected - same idea as .settings-tab-btn.active/.link-stats-tab.active
   elsewhere (styles.css), which never actually hit this conflict in
   practice (mouse clicks on desktop don't trigger :focus-visible the way a
   touch tap on phone reliably does). Both rules above still fire on this
   button once tapped (:not() exclusions there risk not matching on every
   engine, so this is a separate, plain override instead, guaranteed to win
   on specificity - 2 classes + :focus(-visible) outranks the bare
   button:focus-visible above - and !important to also beat that rule's own
   !important, not just its specificity). Confirmed (real device testing)
   that the tapped tab kept the wrong look for exactly as long as it held
   real focus, reverting the instant focus moved elsewhere - i.e. genuinely
   tied to focus itself, not a one-off :active tap flash - but which of
   :focus/:focus-visible actually matches varies by engine (mobile Safari's
   own :focus-visible heuristic is known to differ from Chromium's), so
   this covers both explicitly rather than gambling on just one. Restores
   the exact look the active tab already had before being tapped: no
   outline (drawn square regardless of this button's own 8px border-radius,
   reading as a stray "shadow" poking out past its rounded corners -
   confirmed as the actual reported bug), its own border color back, and
   its own text color back instead of --highlight. */
.phone-edit-preview-tab.active:focus,
.phone-edit-preview-tab.active:focus-visible {
  outline: none !important;
  border-color: var(--secondary-color) !important;
  color: var(--font-color-clear) !important;
}
/* .phone-overview-kanban-tab.active (tasks/styles/editTask.css) - the same
   two-button toggle shape, same solid-fill "active" look, same real-device-
   confirmed conflict as .phone-edit-preview-tab.active just above (that
   rule's own comment has the full reasoning) - tapping the Kanban/Overview
   toggle hit the exact same bug, just never covered here since this toggle
   was added after that fix already existed.
   background-color is also re-asserted here, unlike the twin rule above -
   confirmed (real device) as genuinely needed for THIS toggle specifically,
   losing its active fill (reverting to the plain inactive background) for
   as long as it holds focus, even with everything else above already
   fixed. */
.phone-overview-kanban-tab.active:focus,
.phone-overview-kanban-tab.active:focus-visible {
  outline: none !important;
  border-color: var(--secondary-color) !important;
  color: var(--font-color-clear) !important;
  background-color: var(--secondary-color) !important;
}

/* A native <dialog> element accepts focus itself in two real cases: a click
   landing on non-interactive content inside one (its own header text, a
   plain message div, empty padding - none of that is focusable on its own,
   so the browser walks up to the nearest focusable ancestor, which a
   modally-open <dialog> counts as even with no tabindex of its own), and
   per spec, showModal() itself falling back to focusing the dialog when it
   happens to have no focusable descendant at all (e.g. the Template
   Manager with zero saved templates). Neither is a mouse click that stays
   a mouse click forever, either - the browser's own :focus-visible
   heuristic can retroactively decide an already-(click-)focused element
   should start showing as focus-visible the moment real keyboard input
   arrives (e.g. pressing T right after clicking somewhere inert inside an
   open Settings dialog) - confirmed as the actual reported repro. Dialogs
   are containers, never controls, so they should never show a focus ring
   themselves either way - suppressed unconditionally, project-wide, for
   every dialog in the app (not just the one-off .icon-manager-dialog fix,
   styles.css, which predates this and can stay - it also covers its own
   grid/icon-cell children, a different concern from this bare-dialog one). */
dialog:focus,
dialog:focus-visible {
  outline: none;
}