/* --------------------------------------------------- */
/*                       TOOLTIP                        */
/* --------------------------------------------------- */
/* Shared by every hover hint created via createTooltip() (scripts/
   tooltip.js) — loaded by both the homepage and the tasks page so every
   tooltip on either looks and behaves the same, instead of each page
   growing its own bespoke tooltip CSS. Variants below only control where
   they're anchored/positioned. */
.app-tooltip {
  position: absolute;
  background-color: var(--main-theme-darker);
  /* --main-theme-darker stays dark-ish in both themes, but --font-color-clear
     flips to a dark color in light mode (meant for light backgrounds) —
     same fixed light color as .settings-button, since this background never
     gets light enough for theme-aware text to read well against it. */
  color: #efefef;
  padding: 4px 8px;
  border-radius: 4px;
  border: 2px solid var(--secondary-color);
  /* width: max-content sizes the box to the text's own natural (unwrapped)
     width first — without it, a fixed-positioned tooltip with no explicit
     width of its own falls back to shrink-to-fit sizing based on its
     containing block (the viewport, often much wider than the text itself
     actually needs, or vice versa), which could force a wrap at nearly
     every word regardless of max-width below. max-width still clamps it
     (triggering an actual wrap) once the content itself is wider than
     that. */
  width: max-content;
  max-width: 250px;
  white-space: normal;
  /* white-space:normal only ever wraps at an existing break opportunity
     (a space/hyphen) — content with none at all within max-width's reach
     (a long URL, e.g. changelog.js's link badge) would otherwise just keep
     running past this box's own right edge instead of actually wrapping.
     Only ever kicks in for content like that; a normal few-words hint never
     needs a mid-word break to begin with. */
  overflow-wrap: break-word;
  font-size: 12px;
  opacity: 0;
  pointer-events: none;
  transition: opacity 0.2s;
  z-index: 9999;
}
.app-tooltip.visible {
  opacity: 1;
}
/* All three below: position:fixed + inline top/left (computed from the
   trigger's own getBoundingClientRect() at show-time, positionAnchoredTooltip
   in tooltip.js) instead of the plain CSS anchor offsets (bottom/right/left
   percentages against `trigger` as containing block) these used to have —
   those trapped the tooltip inside whatever stacking context trigger's own
   ancestors establish, so no z-index on the tooltip itself, however high,
   could escape a losing ancestor stacking context (e.g. an open
   .create-section.floating-editor, z-index:110, editTask.css, sitting in a
   higher one). See tooltip.js's own top-of-file comment on createTooltip for
   the full reasoning — same fix the floating-* variants below already had. */
.app-tooltip-top {
  position: fixed;
  transform: translate(-100%, -100%);
}
.app-tooltip-center {
  position: fixed;
  transform: translate(-60%, -50%);
}
.app-tooltip-above {
  position: fixed;
  transform: translateX(-50%) translateY(-100%);
}
/* Positioned via inline top/left (computed from the trigger's
   getBoundingClientRect() at show-time) instead of anchored offsets, for
   triggers inside an overflow:hidden/scroll ancestor. */
.app-tooltip-floating-above,
.app-tooltip-floating-below,
.app-tooltip-floating-right,
.app-tooltip-floating-left {
  position: fixed;
  z-index: 9999;
}
.app-tooltip-floating-above {
  transform: translateX(-50%) translateY(-100%);
}
/* Only ever reached by flipping away from floating-above when there's no
   room above the trigger (see resolveFloatingPosition, tooltip.js) — not
   meant to be requested directly, though nothing stops it. */
.app-tooltip-floating-below {
  transform: translateX(-50%);
}
.app-tooltip-floating-right {
  transform: translateY(-50%);
}
.app-tooltip-floating-left {
  transform: translate(-100%, -50%);
}
/* Shifts an anchored tooltip right by half its own width — for triggers
   whose right edge would otherwise crowd the tooltip against something.
   transform isn't additive across separate class rules (whichever rule
   wins cascades/specificity just replaces the whole property, it doesn't
   combine with another class's own transform) - only ever combined with
   .app-tooltip-top in practice (scripts/updateLinks.js), so that specific
   pairing gets its own explicit, higher-specificity combined transform
   below instead of relying on this rule alone to compose with it. */
.tooltip-shift-right {
  transform: translateX(50%);
}
.app-tooltip-top.tooltip-shift-right {
  /* Same as .app-tooltip-top's own translate(-100%,-100%), just shifted
     50% further right (net -50% instead of -100% on the X axis) - the Y
     axis (-100%, flush above the trigger) is unchanged. */
  transform: translate(-50%, -100%);
}