﻿/*
    Application css variables, common class definition, transitions, and body style
*/

:root {
    --commonTextColor: #545c5e;
    --mainBackgroundColor: #e2e2e2;
    --mainColor: #1b2931;
    --mainColorLighter: #475562;
    --mainColorLightest: #5e737e;
    /* Same hue as --mainColor, only used where the color has to work as plain foreground text
       on a page background instead of as a solid fill (.text-mainColor, .btn-outline-mainColor)
       — unchanged in light mode. */
    --mainColorOnDark: var(--mainColor);
    /* Bootstrap's own "this pill/tab is selected" token — wiring it to --mainColor here means
       our own bespoke "you are here" pills (.select-tab-menu, .pill-tabs .nav-link.active,
       which aren't literally .nav-pills markup) can reference this one shared variable instead
       of duplicating var(--mainColor) in three different places. This alone does NOT reach
       real Bootstrap .nav-pills elements, though — see the ".nav-pills" rule further down for
       why that needs its own declaration. */
    --bs-nav-pills-link-active-bg: var(--mainColor);
    --navPillsColor: #255480;
    --cardsBackgroundColorDarker: #fff;
    --cardsBackgroundColorLighter: #fff;
    --ic-calendar-bordas: #cee2f2;
    --ic-primary: #727cf5;
    --ic-primary-rgb: 114,124,245;
    --ic-primary-bg-subtle: #f1f2fe;
    --ic-success: #28a745;
    --ic-success-rgb: 40,167,69;
    --ic-success-bg-subtle: #e7faf5;
    --ic-info: #39afd1;
    --ic-info-rgb: 57, 175, 209;
    --ic-info-bg-subtle: #ebf7fa;
    --ic-warning: #ffc35a;
    --ic-warning-rgb: 255,195,90;
    --ic-warning-bg-subtle: #fff9ef;
    --ic-main-purple: #727CF5;
    --ic-danger: #eb4b4b;
    --ic-danger-bg-subtle: #ffeff2;
    --ic-secondary-color: var(--commonTextColor);
    --ic-white: #fff;
    --ic-lightGreen: #28a745;
    /* Neutral text/surface scale for platform-wide components (stat cards, pill tabs, etc.) —
       add here, never hardcode a one-off gray in a component file, so a future theme/dark-mode
       pass only has to touch this one block. */
    --ic-text-strong: #0f172a;
    --ic-text-default: #1e293b;
    --ic-text-emphasis: #334155;
    --ic-text-muted: #64748b;
    --ic-text-subtle: #94a3b8;
    --ic-shadow-color-rgb: 15, 23, 42;
    --ic-track-color-rgb: 148, 163, 184;
    --ic-border-subtle: rgba(var(--ic-shadow-color-rgb), 0.06);
    --ic-surface-hover: rgba(var(--ic-shadow-color-rgb), 0.05);
    --ic-surface-muted: rgba(var(--ic-shadow-color-rgb), 0.08);
    --ic-brd-rad-sm: 0.25rem;
    --it-font-size-base: 0.9rem;
    --it-font-size-sm: 0.8rem;
    --it-font-size-lg: 1rem;
    --it-font-size-xl: 1.125rem;
    --theme-transition: all 0.3s cubic-bezier(0.4, 0, 0.2, 1);
}

/* Dark mode — flips only the neutral text/surface scale used by our custom components
   (stat cards, pill tabs, etc.). Brand/theme colors (--mainColor and friends, swappable
   via the color theme picker, plus --navPillsColor) are deliberately left untouched here:
   dark mode and theme color are independent settings. Toggled via body[data-bs-theme],
   same attribute Bootstrap's own components already read — see darkMode.js.

   Palette is Tailwind's gray scale — the same one Flowbite's admin dashboard (a well-known,
   widely-used dark-mode reference) actually ships, verified by inspecting its live computed
   styles rather than guessing: page/sidebar bg gray-800 #1f2937, card bg gray-700 #374151,
   hover/border gray-600 #4b5563, heading text white, body text gray-200–300, muted text
   gray-400–500. True neutral gray rather than a tinted one — plain, standard, well-tested,
   without touching the tenant's own accent color.

   Exception: --ic-text-muted/--ic-text-subtle sit one step lighter than that scale. They're
   used for real small text (stat-card captions/legends at ~0.75rem, the theme picker's section
   labels), not only for disabled states, and gray-500 #6b7280 measured ~2.1:1 against the
   #374151 card surface — reported as "texto cinza escuro ilegível". #b0b7c3/#9ca3af give
   ~5.1:1/~4.1:1 on cards and keep the default > emphasis > muted > subtle ordering. */
body[data-bs-theme="dark"] {
    color-scheme: dark;

    /* .bg-light on <body> (kept for light mode) is a Bootstrap utility, and those always
       carry !important — so overriding it here needs !important too, or this rule silently
       loses despite having higher specificity. */
    background-color: var(--bs-body-bg) !important;
    color: var(--bs-body-color) !important;

    /* Bootstrap's own dark tokens — every native component (.card, .table, .dropdown-menu,
       .form-control, .btn-outline-*, .modal, ...) is built from these, so recoloring them
       here carries the same palette into anything we haven't hand-styled ourselves. */
    --bs-body-bg: #1f2937;
    --bs-body-bg-rgb: 31, 41, 55;
    --bs-body-color: #e5e7eb;
    --bs-body-color-rgb: 229, 231, 235;
    --bs-emphasis-color: #ffffff;
    --bs-emphasis-color-rgb: 255, 255, 255;
    --bs-secondary-color: rgba(229, 231, 235, 0.75);
    --bs-secondary-color-rgb: 229, 231, 235;
    --bs-secondary-bg: #374151;
    --bs-secondary-bg-rgb: 55, 65, 81;
    --bs-tertiary-color: rgba(229, 231, 235, 0.5);
    --bs-tertiary-color-rgb: 229, 231, 235;
    --bs-tertiary-bg: #283141;
    --bs-tertiary-bg-rgb: 40, 49, 65;
    --bs-border-color: #4b5563;
    --bs-border-color-translucent: rgba(255, 255, 255, 0.12);

    --commonTextColor: #d1d5db;
    /* --mainColor itself stays the tenant's chosen hex in both modes (it's a solid fill with
       white text almost everywhere — navbar, pills, badges, pagination, selected table rows —
       and that already reads fine regardless of page darkness). Only the couple of spots that
       use it as plain foreground text on the page itself (.text-mainColor,
       .btn-outline-mainColor) need a lightened variant, because the darkest theme colors
       (Cinza in particular) drop under 3:1 against a dark page otherwise. */
    --mainColorOnDark: color-mix(in srgb, var(--mainColor) 40%, white 60%);
    --mainBackgroundColor: #4b5563;
    --mainBackgroundColorRGB: 75, 85, 99;
    --cardsBackgroundColorDarker: #374151;
    --cardsBackgroundColorLighter: #374151;
    --ic-text-strong: #ffffff;
    --ic-text-default: #e5e7eb;
    --ic-text-emphasis: #d1d5db;
    --ic-text-muted: #b0b7c3;
    --ic-text-subtle: #9ca3af;
    --ic-shadow-color-rgb: 0, 0, 0;
    --ic-track-color-rgb: 107, 114, 128;
    --ic-border-subtle: rgba(107, 114, 128, 0.4);
    --ic-surface-hover: rgba(107, 114, 128, 0.18);
    --ic-surface-muted: rgba(107, 114, 128, 0.28);

    /* .badge-ic-*-lighten and friends: a fixed pale hex (meant for a white page) reads as a
       bright, out-of-place patch on a dark one — a transparent tint of the same badge color
       works on any surface behind it, light or dark. */
    --ic-primary-bg-subtle: color-mix(in srgb, var(--ic-primary) 18%, transparent);
    --ic-success-bg-subtle: color-mix(in srgb, var(--ic-success) 18%, transparent);
    --ic-info-bg-subtle: color-mix(in srgb, var(--ic-info) 18%, transparent);
    --ic-warning-bg-subtle: color-mix(in srgb, var(--ic-warning) 18%, transparent);
    --ic-danger-bg-subtle: color-mix(in srgb, var(--ic-danger) 18%, transparent);

    /* bootstrap-year-calendar's own custom properties (lib/bootstrap-year-calendar-1.1.0).
       IMPORTANT, verified live (getComputedStyle on the actual generated markup) rather than
       assumed: a custom property declared as var(--bs-body-bg, #fff) at :root does NOT
       re-resolve per element. Its var() substitution happens once, at :root, using --bs-body-bg
       AS SEEN AT :root — which we never override (only body[data-bs-theme=dark] is) — so the
       RESULT (a plain #fff) is what inherits down, not a live reference. Overriding
       --bs-body-bg on body has no effect on it. Confirmed the bug this way: on a real day cell,
       --bs-body-bg correctly read #1f2937, but --calendar-bg (var(--bs-body-bg, #fff) at
       :root) still read #fff, and the cell rendered white. Every --calendar-* property below
       that wraps a --bs-* token whose value actually differs between modes has this same bug
       and needs re-declaring here — where --bs-body-bg etc. already hold their dark values in
       THIS SAME rule — so the substitution happens at body instead of :root.
       --calendar-primary/-secondary/-success/-warning/-danger/-info are NOT included: Bootstrap
       never redefines --bs-primary/-secondary/-success/-warning/-danger/-info between
       [data-bs-theme=light] and [data-bs-theme=dark] (only their *-text-emphasis/-bg-subtle/
       -border-subtle variants differ), so those five have nothing to fix — same frozen
       mechanism, but frozen at a value that was never going to change anyway.
       --calendar-bg-active/--calendar-text-muted/--calendar-text-light/--calendar-border-light/
       --calendar-today-border/--calendar-today-bg are defined by the library but never actually
       consumed by its own CSS (checked every rule in the file) — still given dark values below
       for completeness, in case a future custom-day-renderer or override starts using them. */
    --calendar-bg: var(--bs-body-bg);
    --calendar-bg-subtle: var(--bs-secondary-bg);
    --calendar-bg-hover: var(--bs-tertiary-bg);
    --calendar-bg-active: var(--ic-surface-hover);
    --calendar-text: var(--bs-body-color);
    --calendar-text-secondary: var(--bs-secondary-color);
    --calendar-text-muted: var(--ic-text-subtle);
    --calendar-border: var(--bs-border-color);
    --calendar-border-subtle: rgba(255, 255, 255, 0.1);
    --calendar-border-light: var(--ic-border-subtle);
    --calendar-weekend-bg: var(--ic-surface-muted);
    --calendar-weekend-text: var(--ic-text-emphasis);
    --calendar-today-bg: color-mix(in srgb, var(--ic-warning) 18%, transparent);
}

/* Bootstrap's .bg-white/.bg-light/.text-dark utilities are static — they never flip with
   data-bs-theme — but the app uses them everywhere as "the card surface" and "strong
   heading text". Route them through the same neutral tokens here instead of hunting down
   every class="... bg-white ..."/"... text-dark ..." usage across the app one file at a time.
   All three of Bootstrap's own rules use !important, so ours must too or it silently loses —
   that's what caused the invisible/washed-out headers and navbar: the text color flipped
   (.text-dark did have !important) but the background behind it never did. */
body[data-bs-theme="dark"] .bg-white {
    background-color: var(--cardsBackgroundColorDarker) !important;
}

body[data-bs-theme="dark"] .bg-light {
    /* rgba + --bs-bg-opacity (not a flat background-color) so bg-opacity-* combos —
       e.g. the app-wide loading-indicator's "bg-light bg-opacity-75" — keep working. */
    background-color: rgba(var(--mainBackgroundColorRGB), var(--bs-bg-opacity, 1)) !important;
}

body[data-bs-theme="dark"] .text-dark {
    color: var(--ic-text-strong) !important;
}

/* ...except where .text-dark sits on one of Bootstrap's fixed light fills (the yellow/cyan
   "badge bg-warning text-dark" pills in O Meu Horário etc.): .bg-warning/.bg-info never flip
   with the theme, so the rule above turned their label white-on-yellow. Keep the dark label
   there, as in light mode. */
body[data-bs-theme="dark"] .bg-warning.text-dark,
body[data-bs-theme="dark"] .bg-info.text-dark {
    color: #212529 !important;
}

/* .text-secondary/.text-primary/.text-success/.text-danger are Bootstrap's fixed "named
   palette" colors (rgba(var(--bs-secondary-rgb)) etc.) — Bootstrap never redefines them for
   dark mode, it expects .text-body-secondary/.text-*-emphasis instead. The app uses them all
   over (~130 .text-secondary for secondary labels/icons, ~680 .text-primary, ...), and on the
   #374151 card surface they measured ~2.2:1 — .text-secondary's #6c757d is the "cinza escuro"
   that reads as nearly invisible. Route them to the same dark-aware tokens Bootstrap already
   computes, same approach as the .btn-outline-* fix below. .text-warning/.text-info are light
   enough already and are left alone. */
body[data-bs-theme="dark"] .text-secondary {
    color: var(--bs-secondary-color) !important;
}

body[data-bs-theme="dark"] .text-primary {
    color: var(--bs-primary-text-emphasis) !important;
}

body[data-bs-theme="dark"] .text-success {
    color: var(--bs-success-text-emphasis) !important;
}

body[data-bs-theme="dark"] .text-danger {
    color: var(--bs-danger-text-emphasis) !important;
}

/* Bootstrap's own --bs-card-bg defaults to var(--bs-body-bg) — i.e. a plain .card with no
   extra class has NO built-in separation from the page at all. That's invisible in light mode
   too, but masked there because .bg-light on <body> already differs from the card's white
   default; in dark mode both --bs-body-bg and the (untouched) card default became the exact
   same #1f2937, so every plain-.card view (e.g. Departamentos, Entidades) reduced to "a shadow
   and nothing else". Give cards the same lighter surface --cardsBackgroundColorDarker already
   uses for .bg-white, so the page/card distinction Flowbite's own reference actually has
   (gray-800 page, gray-700 card) applies to every card. Scoped to ".card" itself, not just
   "body[data-bs-theme=dark]" — Bootstrap's own .card rule sets --bs-card-bg directly on the
   card element, and a local declaration on an element always beats one merely inherited from
   an ancestor like <body>, no matter how that ancestor's rule is written. */
body[data-bs-theme="dark"] .card {
    --bs-card-bg: var(--cardsBackgroundColorDarker);
}

/* Same trap, the other way round: .list-group paints every row with --bs-list-group-bg, which
   Bootstrap defaults to var(--bs-body-bg). In light mode that's the same white as the card around
   it, so a .list-group-flush (the edge-to-edge list meant to sit INSIDE a card/modal/offcanvas —
   Dashboard "Top Colaboradores", Formações widgets, Funcionários, ...) reads as one surface. In
   dark mode body-bg is the page color (#1f2937), darker than the card (#374151), so every row
   showed up as a filled dark band inside the card. Transparent lets the rows take whatever
   surface they sit on, which is what they did in light mode. */
body[data-bs-theme="dark"] .list-group-flush {
    --bs-list-group-bg: transparent;
}

/* .table-light is a Bootstrap "always light" table variant by design (Bootstrap's own
   dark theme deliberately leaves it alone) — but the app uses it everywhere as the
   default <thead> styling, not as a deliberate fixed-light choice, so it needs the
   same neutral-token treatment as everything else here. */
body[data-bs-theme="dark"] .table-light {
    --bs-table-color: var(--ic-text-strong);
    --bs-table-bg: var(--mainBackgroundColor);
    --bs-table-border-color: var(--ic-border-subtle);
    --bs-table-striped-bg: var(--ic-surface-muted);
    --bs-table-striped-color: var(--ic-text-strong);
    --bs-table-active-bg: var(--ic-surface-hover);
    --bs-table-active-color: var(--ic-text-strong);
    --bs-table-hover-bg: var(--ic-surface-hover);
    --bs-table-hover-color: var(--ic-text-strong);
}

/* .btn-outline-* (used everywhere for row actions — Comunicados download/delete, Aprovações
   actions, DataTables toolbars): Bootstrap hardcodes each variant's base semantic color
   (#0d6efd, #dc3545, #198754, #6c757d...) directly as --bs-btn-color, not routed through any
   theme-aware variable. Those colors are tuned for contrast against white; against our now-
   dark card surface (~L 0.2) several measured under 2:1 contrast — .btn-outline-danger's red
   was ~1.6:1, essentially unreadable. Bootstrap's own dark theme already computes a lighter
   "-text-emphasis" variant of every semantic color for exactly this situation (used by
   .text-primary-emphasis etc.) but doesn't wire it into outline buttons — wiring it in here
   instead of inventing new colors keeps these consistent with the rest of Bootstrap's dark
   palette. Hover/active fill with that lighter color needs a dark (not white) label to stay
   readable once filled. */
body[data-bs-theme="dark"] .btn-outline-primary,
body[data-bs-theme="dark"] .btn-outline-secondary,
body[data-bs-theme="dark"] .btn-outline-success,
body[data-bs-theme="dark"] .btn-outline-danger,
body[data-bs-theme="dark"] .btn-outline-warning,
body[data-bs-theme="dark"] .btn-outline-info,
body[data-bs-theme="dark"] .btn-outline-dark {
    --bs-btn-hover-color: #1f2937;
    --bs-btn-active-color: #1f2937;
}

body[data-bs-theme="dark"] .btn-outline-primary {
    --bs-btn-color: var(--bs-primary-text-emphasis);
    --bs-btn-border-color: var(--bs-primary-text-emphasis);
    --bs-btn-hover-bg: var(--bs-primary-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-primary-text-emphasis);
    --bs-btn-active-bg: var(--bs-primary-text-emphasis);
    --bs-btn-active-border-color: var(--bs-primary-text-emphasis);
}

body[data-bs-theme="dark"] .btn-outline-secondary {
    --bs-btn-color: var(--bs-secondary-text-emphasis);
    --bs-btn-border-color: var(--bs-secondary-text-emphasis);
    --bs-btn-hover-bg: var(--bs-secondary-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-secondary-text-emphasis);
    --bs-btn-active-bg: var(--bs-secondary-text-emphasis);
    --bs-btn-active-border-color: var(--bs-secondary-text-emphasis);
}

body[data-bs-theme="dark"] .btn-outline-success {
    --bs-btn-color: var(--bs-success-text-emphasis);
    --bs-btn-border-color: var(--bs-success-text-emphasis);
    --bs-btn-hover-bg: var(--bs-success-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-success-text-emphasis);
    --bs-btn-active-bg: var(--bs-success-text-emphasis);
    --bs-btn-active-border-color: var(--bs-success-text-emphasis);
}

body[data-bs-theme="dark"] .btn-outline-danger {
    --bs-btn-color: var(--bs-danger-text-emphasis);
    --bs-btn-border-color: var(--bs-danger-text-emphasis);
    --bs-btn-hover-bg: var(--bs-danger-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-danger-text-emphasis);
    --bs-btn-active-bg: var(--bs-danger-text-emphasis);
    --bs-btn-active-border-color: var(--bs-danger-text-emphasis);
}

body[data-bs-theme="dark"] .btn-outline-warning {
    --bs-btn-color: var(--bs-warning-text-emphasis);
    --bs-btn-border-color: var(--bs-warning-text-emphasis);
    --bs-btn-hover-bg: var(--bs-warning-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-warning-text-emphasis);
    --bs-btn-active-bg: var(--bs-warning-text-emphasis);
    --bs-btn-active-border-color: var(--bs-warning-text-emphasis);
}

body[data-bs-theme="dark"] .btn-outline-info {
    --bs-btn-color: var(--bs-info-text-emphasis);
    --bs-btn-border-color: var(--bs-info-text-emphasis);
    --bs-btn-hover-bg: var(--bs-info-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-info-text-emphasis);
    --bs-btn-active-bg: var(--bs-info-text-emphasis);
    --bs-btn-active-border-color: var(--bs-info-text-emphasis);
}

/* .btn-outline-dark hardcodes near-black (#212529) as its color/border — invisible against a
   dark card. Same --bs-*-text-emphasis fix as the others (Bootstrap already computes a light
   #dee2e6 for --bs-dark-text-emphasis in dark mode). .btn-outline-light is NOT included here:
   its base color is already #f8f9fa (near white), which reads fine on a dark card as-is. */
body[data-bs-theme="dark"] .btn-outline-dark {
    --bs-btn-color: var(--bs-dark-text-emphasis);
    --bs-btn-border-color: var(--bs-dark-text-emphasis);
    --bs-btn-hover-bg: var(--bs-dark-text-emphasis);
    --bs-btn-hover-border-color: var(--bs-dark-text-emphasis);
    --bs-btn-active-bg: var(--bs-dark-text-emphasis);
    --bs-btn-active-border-color: var(--bs-dark-text-emphasis);
}

/* .btn-light stays Bootstrap's fixed "named palette" white (#f8f9fa) even in dark mode by
   design (same category as --bs-warning etc.) — but a solid white box with black text reads as
   a glaring, out-of-place patch next to everything else on a dark page. Recast it as a subtle
   neutral button using the same surface tokens as the rest of the dark palette, with light text
   instead of Bootstrap's default black (a dark background needs light text). */
body[data-bs-theme="dark"] .btn-light {
    --bs-btn-color: var(--ic-text-default);
    --bs-btn-bg: var(--bs-tertiary-bg);
    --bs-btn-border-color: var(--bs-border-color);
    --bs-btn-hover-color: var(--ic-text-strong);
    --bs-btn-hover-bg: var(--bs-secondary-bg);
    --bs-btn-hover-border-color: var(--bs-border-color);
    --bs-btn-active-color: var(--ic-text-strong);
    --bs-btn-active-bg: var(--bs-secondary-bg);
    --bs-btn-active-border-color: var(--bs-border-color);
}

/* ServicosEscalasAvancadas/Index.cshtml's "Gerir Serviço" modal (#manageServiceModal) — its
   icon badges and service-name chip use Bootstrap's .bg-opacity-10 (a 10% tint of a fixed
   semantic color). That 10% barely registers once blended onto the dark surface .btn-light
   itself now uses (right above), so each badge nearly disappears into its own button's
   background. Bump the opacity in dark mode so they stay visibly distinct — same reasoning as
   the --ic-*-bg-subtle badges earlier in this file, just for Bootstrap's own opacity utility
   instead of our custom one. Scoped to this one modal rather than every .bg-opacity-10 in the
   app, since that utility is used for many unrelated things elsewhere. */
body[data-bs-theme="dark"] #manageServiceModal .bg-opacity-10 {
    --bs-bg-opacity: .22;
}

/* .select-tab-menu (the active top-level nav pill, e.g. "Gestão") uses a light-mode-only
   trick: a faint tint of --mainColor as background with --mainColor itself as text. That
   only works because some theme colors (Cinza in particular) are dark to begin with — on a
   white page a dark color reads fine as text, but once the page
   itself goes dark, a color-mix lighten strong enough to keep Cinza legible over-lightens
   Indigo/Ciano/Ambar into pastel mush, and one that keeps them vivid leaves Cinza nearly
   invisible — no single mix ratio works for both ends of that range. Flip to the same
   solid-fill-plus-white-text treatment already used for .rail-item.active and
   .pill-tabs .nav-link.active elsewhere in the app: white-on-saturated-color contrast holds
   regardless of how dark or light the underlying theme color is. */
body[data-bs-theme="dark"] .select-tab-menu,
body[data-bs-theme="dark"] .select-tab-menu-parent {
    background-color: var(--bs-nav-pills-link-active-bg) !important;
    color: #fff !important;
    border-color: var(--bs-nav-pills-link-active-bg) !important;
}

/* Same problem, same fix, for the Aprovações pending-count pill in the page header. */
body[data-bs-theme="dark"] .aprov-total-pill {
    color: #fff;
    background: var(--bs-nav-pills-link-active-bg);
}

/* .text-mainColor (entity name + date on both dashboards) and .btn-outline-mainColor (a
   brand-colored outline button) are the two spots that use --mainColor as plain foreground
   text/border on the page itself rather than as a solid fill — route them to the lightened
   --mainColorOnDark instead. The date under the entity name also stacks .opacity-75 on top,
   which halves an already-marginal color's contrast again — ease that off in dark mode instead
   of fighting it with an even stronger color-mix. */
body[data-bs-theme="dark"] .text-mainColor {
    color: var(--mainColorOnDark) !important;
}

body[data-bs-theme="dark"] .text-mainColor.opacity-75 {
    opacity: 0.9;
}

body[data-bs-theme="dark"] .btn-outline-mainColor {
    border-color: var(--mainColorOnDark);
    color: var(--mainColorOnDark);
}

    body[data-bs-theme="dark"] .btn-outline-mainColor:hover {
        background-color: var(--mainColorOnDark);
        border-color: var(--mainColorOnDark);
        color: #1f2937;
    }

/* .dropdown-item.active/:active (a genuinely selected item — the current theme swatch,
   language, etc.) uses --mainColor directly as its soft-tinted-pill text color — same "reads
   fine on a white menu, vanishes on a dark one" problem as .text-mainColor, worst for the
   darker theme colors against the dropdown's own dark background. Route text/border to the
   lightened --mainColorOnDark; the tint ratios stay the same as light mode. Plain :hover isn't
   included here — it uses Bootstrap's own default, which is already dark-mode aware. */
body[data-bs-theme="dark"] .dropdown-item.active,
body[data-bs-theme="dark"] .dropdown-item:active {
    background-color: color-mix(in srgb, var(--mainColorOnDark) 10%, transparent) !important;
    color: var(--mainColorOnDark) !important;
    border-color: color-mix(in srgb, var(--mainColorOnDark) 25%, transparent) !important;
}

/* Same plain-text-on-dark-page problem, same fix, for the active tab in .nav-tabs (Bootstrap's
   own active-tab background is --bs-body-bg, i.e. the page itself, in both modes). */
body[data-bs-theme="dark"] .nav-tabs .nav-link.active {
    color: var(--mainColorOnDark);
    border-bottom-color: var(--mainColorOnDark);
}

/* Remaining spots that use --mainColor as plain text on the page (every theme color measures
   ~1.7–2.6:1 against the dark card): .color-main (footer), the non-active pagination links
   under every DataTable. The active page keeps its solid fill + white text. */
body[data-bs-theme="dark"] .color-main {
    color: var(--mainColorOnDark) !important;
}

body[data-bs-theme="dark"] .pagination .page-item:not(.active):not(.disabled) .page-link {
    color: var(--mainColorOnDark);
}

    /* Light-mode hover fills with --mainColorLightest (the theme color +70 brightness) — a
       light-ish tint that the lightened text above would disappear into. Neutral hover instead,
       same as .dropdown-item/.nav-tabs. */
    body[data-bs-theme="dark"] .pagination .page-item:not(.active):not(.disabled) .page-link:hover {
        background-color: var(--ic-surface-hover);
    }

/* .navbar.bg-mainColor-gradient is the top brand bar (logo, theme/user menus) — a big,
   saturated gradient slab that reads as a glowing colored stripe against a dark page.
   Enterprise dark dashboards (Flowbite included) keep the header on the SAME neutral surface
   as the page, separated only by a shadow, not a color block. Scoped to the compound
   ".navbar.bg-mainColor-gradient" selector specifically (not the bare ".bg-mainColor-gradient")
   so modal headers, card headers and the calendar view's form-control, which share that same
   class for an intentional branded accent, are untouched — they keep the gradient in both
   modes. */
body[data-bs-theme="dark"] .navbar.bg-mainColor-gradient {
    background: var(--bs-body-bg) !important;
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.35);
}

/* .stat-card--dark's accent is --bs-dark, a fixed near-black that Bootstrap never flips for
   dark mode (same "named palette color" category as --bs-light/--bs-warning) — on a light
   card that's a deliberately high-contrast dark icon, but on a now-dark card it's a dark
   icon in a barely-different dark circle on a dark card: three near-identical darks stacked,
   nothing legible. Point its accent at a light token instead, just in dark mode. */
body[data-bs-theme="dark"] .stat-card--dark {
    --card-accent-1: var(--ic-text-strong);
}

/* Fancytree (wwwroot/lib/fancytree-master, skin-win8/ui.fancytree.css) — used for every
   department/entity/terminal tree in the app (Departamentos, Entidades, Acessos, Feriados,
   Funcionários, ...), always with the library's own default "fancytree-plain" class (Fancytree
   adds it to every tree unconditionally, see jquery.fancytree.js's $.ui.fancytree.info
   bootstrap). DON'T edit ui.fancytree.css directly — it's auto-generated from the library's own
   LESS templates and says so at the top of the file — everything needed lives here instead. */

/* Node titles hardcode color: black — invisible on a dark tree. */
body[data-bs-theme="dark"] span.fancytree-title {
    color: var(--ic-text-default);
}

/* Hover uses a pale blue fill (#eff9fe/#70c0e7) — reads as a glaring light patch on a dark
   tree. Same neutral hover already used for .dropdown-item/.nav-tabs elsewhere. */
body[data-bs-theme="dark"] .fancytree-plain span.fancytree-node:hover span.fancytree-title {
    background-color: var(--ic-surface-hover);
    border-color: var(--ic-border-subtle);
}

/* Active/selected uses a near-white fill (#f7f7f7/#dedede) — same problem, worse (it's the
   persistent "this is the current node" state, not just a transient hover). Tinted with the
   tenant's brand color instead, same language as .dropdown-item.active/.select-tab-menu. */
body[data-bs-theme="dark"] .fancytree-plain span.fancytree-active span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-plain span.fancytree-selected span.fancytree-title {
    background-color: color-mix(in srgb, var(--mainColor) 20%, transparent);
    border-color: color-mix(in srgb, var(--mainColor) 45%, transparent);
    color: var(--mainColorOnDark);
}

/* A disabled tree dims to a flat "silver" background — barely different from black/near-black
   at 50% opacity, and not part of the neutral scale used everywhere else. */
body[data-bs-theme="dark"] .ui-fancytree-disabled ul.fancytree-container {
    background-color: var(--ic-surface-muted);
}

/* 'filter' extension (the only fancytree extension this app actually uses — every tree init
   passes extensions:["filter"]): dimmed/non-matching titles use a fixed light gray, matching
   titles use a fixed black — both need the same dark-mode-aware neutral text tokens as the
   base title above. */
body[data-bs-theme="dark"] .fancytree-ext-filter-dimm span.fancytree-node span.fancytree-title {
    color: var(--ic-text-subtle);
}

body[data-bs-theme="dark"] .fancytree-ext-filter-dimm tr.fancytree-submatch span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-dimm span.fancytree-node.fancytree-submatch span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-dimm tr.fancytree-match span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-dimm span.fancytree-node.fancytree-match span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-hide tr.fancytree-match span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-hide span.fancytree-node.fancytree-match span.fancytree-title {
    color: var(--ic-text-strong);
}

body[data-bs-theme="dark"] .fancytree-ext-filter-hide tr.fancytree-submatch span.fancytree-title,
body[data-bs-theme="dark"] .fancytree-ext-filter-hide span.fancytree-node.fancytree-submatch span.fancytree-title {
    color: var(--ic-text-subtle);
}

/* bootstrap-year-calendar (lib/bootstrap-year-calendar-1.1.0), continued — the header
   (.calendar-header, .year-title, .prev/.next, the nav arrows) needs no fix: it's added by the
   plugin's own JS with a .bg-white class, which already flips to the dark card surface via the
   existing .bg-white override above, and its hardcoded white text/icons read correctly against
   that. These are the remaining spots that bypass the --calendar-* custom properties entirely
   and use a literal hex directly in the rule, so nothing set on those properties (above) could
   ever reach them regardless of the :root-freezing issue. */

/* Right-click day context menu ("add absence", "mark holiday", ...) is a hardcoded white
   popup — same "glaring white box on a dark page" problem as .btn-light/dropdown-menu earlier. */
body[data-bs-theme="dark"] .calendar-context-menu,
body[data-bs-theme="dark"] .calendar-context-menu .submenu {
    background-color: var(--cardsBackgroundColorDarker);
    border-color: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .calendar-context-menu .item:hover {
    background: var(--ic-surface-hover);
}

/* Day-cell and week-number dividers are a fixed light gray (#dddddd/#eee) — invisible against
   a dark page. */
body[data-bs-theme="dark"] .calendar table.month tr td .day-content {
    border-right-color: var(--ic-border-subtle);
    border-left-color: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .calendar table.month td.week-number {
    border-right-color: var(--ic-border-subtle);
}

/* Disabled dates and the "next/previous year" labels use very light grays (#dddddd/#aaaaaa)
   meant to read as faded on a white page — on a dark one they'd be brighter than the normal
   text around them, the opposite of "de-emphasized". */
body[data-bs-theme="dark"] .calendar table.month tr td.disabled,
body[data-bs-theme="dark"] .calendar table.month tr td.disabled:hover {
    color: var(--ic-text-subtle);
}

body[data-bs-theme="dark"] .calendar .year-neighbor {
    color: var(--ic-text-subtle);
}

body[data-bs-theme="dark"] .calendar .year-neighbor2 {
    color: var(--ic-text-muted);
}

/* TomSelect (lib/tom-select) — used for the searchable multi-select dropdowns in the Formações
   module (formadorForm.js, planoCreate.js, planoEditForm.js, sessaoFormacaoCreate.js; the Vista
   Mensal department filter that used to run through TomSelect has since been simplified back to
   a plain <select>). Its own CSS hardcodes several light-mode-only grays instead of routing
   through --bs-* tokens, same pattern as Fancytree/bootstrap-year-calendar — kept out of the
   vendor file for the same reason. Only the plugin actually loaded anywhere (remove_button) and
   the rules that are genuinely reachable are covered — every TomSelect init in this app passes
   create:false and none use async loading, optgroups, or the dropdown_input/optgroup_columns
   plugins, so their styling (.ts-dropdown .create/.spinner/.optgroup-header, the
   dropdown_input/optgroup_columns plugin rules) is dead code here and was left alone. */

/* Base text color for the control and its typed input/dropdown option list — hardcoded
   #343a40 (near-black). Without this, every selected value and every option in the list is
   invisible once the control's own background goes dark. */
body[data-bs-theme="dark"] .ts-control,
body[data-bs-theme="dark"] .ts-dropdown,
body[data-bs-theme="dark"] .ts-control input {
    color: var(--bs-body-color);
}

/* Multi-select "chip" for each selected value: a light gray pill (#efefef bg, #343a40 text,
   #dee2e6 border) that reads as a glaring light patch once the control itself goes dark. */
body[data-bs-theme="dark"] .ts-wrapper.multi .ts-control > div {
    background: var(--ic-surface-muted);
    color: var(--ic-text-default);
    border-color: var(--ic-border-subtle);
}

/* Disabled chips are hardcoded flat white — same problem, and it never dims at all since
   white-on-white was already the "disabled" look by design in light mode. */
body[data-bs-theme="dark"] .ts-wrapper.multi.disabled .ts-control > div,
body[data-bs-theme="dark"] .ts-wrapper.multi.disabled .ts-control > div.active {
    background: var(--ic-surface-muted);
    color: var(--ic-text-subtle);
    border-color: var(--ic-surface-muted);
}

/* remove_button plugin (the only TomSelect plugin actually loaded in this app): the divider
   between a chip's label and its "x", and that divider's disabled-state color (hardcoded
   white), both invisible against a dark chip. */
body[data-bs-theme="dark"] .ts-wrapper.plugin-remove_button:not(.rtl) .item .remove {
    border-left-color: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .ts-wrapper.plugin-remove_button.rtl .item .remove {
    border-right-color: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .ts-wrapper.plugin-remove_button:not(.rtl).disabled .item .remove {
    border-left-color: var(--ic-surface-muted);
}

body[data-bs-theme="dark"] .ts-wrapper.plugin-remove_button.rtl.disabled .item .remove {
    border-right-color: var(--ic-surface-muted);
}

/* Quill (lib/quill, "snow" theme — quill.snow.min.css) — the rich-text editor used for
   Entidades' "normativa" field and the RGPD consent-policy text (reusableComponents.js's
   initQuill()). Same reasoning as Fancytree/bootstrap-year-calendar/TomSelect: overridden here
   instead of the vendor file, and only for what this app's fixed toolbar config
   (header/bold/italic/underline/link/blockquote/code-block/lists — see initQuill()'s
   defaultOptions) actually renders. The font/size pickers and the color/background pickers are
   never added to any toolbar in this app, so their CSS (.ql-picker.ql-font, .ql-picker.ql-size,
   .ql-color-picker) is dead code here and left alone; .ql-code-block-container already ships
   its own fixed dark background (#23241f) regardless of page theme — a deliberate "code always
   looks like code" convention — so it's untouched too. .ql-editor/.ql-toolbar have no
   background or text color of their own in the vendor CSS, so they already inherit the
   correct dark-mode page/card background and text color for free; only the pieces below hardcode
   a color instead of inheriting one. */

/* Editor and toolbar borders. */
body[data-bs-theme="dark"] .ql-container.ql-snow,
body[data-bs-theme="dark"] .ql-toolbar.ql-snow {
    border-color: var(--ic-border-subtle);
}

/* Empty-editor placeholder text — hardcoded near-black, invisible against a dark editor. */
body[data-bs-theme="dark"] .ql-editor.ql-blank::before {
    color: var(--ic-text-subtle);
}

/* Toolbar button/icon color and the Header picker's label — hardcoded #444, unreadable against
   a toolbar that (having no background of its own) already inherits the dark page/card behind
   it. This is the single highest-impact fix: without it every toolbar icon is invisible. */
body[data-bs-theme="dark"] .ql-snow .ql-stroke,
body[data-bs-theme="dark"] .ql-snow .ql-stroke-miter {
    stroke: var(--ic-text-muted);
}

body[data-bs-theme="dark"] .ql-snow .ql-fill,
body[data-bs-theme="dark"] .ql-snow .ql-stroke.ql-fill {
    fill: var(--ic-text-muted);
}

body[data-bs-theme="dark"] .ql-snow .ql-picker {
    color: var(--ic-text-muted);
}

/* Header picker's dropdown panel (H1/H2/Normal) — hardcoded white, a glaring box once the
   toolbar itself is dark. */
body[data-bs-theme="dark"] .ql-snow .ql-picker-options {
    background-color: var(--cardsBackgroundColorDarker);
}

body[data-bs-theme="dark"] .ql-toolbar.ql-snow .ql-picker.ql-expanded .ql-picker-label,
body[data-bs-theme="dark"] .ql-toolbar.ql-snow .ql-picker.ql-expanded .ql-picker-options {
    border-color: var(--ic-border-subtle);
}

/* Link-insertion tooltip (the "link" toolbar button) — hardcoded white popup, same problem as
   the picker dropdown above. */
body[data-bs-theme="dark"] .ql-snow .ql-tooltip {
    background-color: var(--cardsBackgroundColorDarker);
    border-color: var(--ic-border-subtle);
    color: var(--ic-text-default);
}

body[data-bs-theme="dark"] .ql-snow .ql-tooltip input[type="text"] {
    border-color: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .ql-snow .ql-tooltip a.ql-action::after {
    border-right-color: var(--ic-border-subtle);
}

/* Blockquote accent border in the editor content (the "blockquote" toolbar button). */
body[data-bs-theme="dark"] .ql-snow .ql-editor blockquote {
    border-left-color: var(--ic-border-subtle);
}

/* Touch-device hover fallback for toolbar buttons — same #444 icon color as the base state
   above, needs the same token. */
@media (pointer: coarse) {
    body[data-bs-theme="dark"] .ql-snow .ql-toolbar button:hover:not(.ql-active) {
        color: var(--ic-text-muted);
    }

    body[data-bs-theme="dark"] .ql-snow .ql-toolbar button:hover:not(.ql-active) .ql-fill,
    body[data-bs-theme="dark"] .ql-snow .ql-toolbar button:hover:not(.ql-active) .ql-stroke.ql-fill {
        fill: var(--ic-text-muted);
    }

    body[data-bs-theme="dark"] .ql-snow .ql-toolbar button:hover:not(.ql-active) .ql-stroke,
    body[data-bs-theme="dark"] .ql-snow .ql-toolbar button:hover:not(.ql-active) .ql-stroke-miter {
        stroke: var(--ic-text-muted);
    }
}

/* ApexCharts (newLibs/apexcharts.min.js) — Dashboard SH/Colaborador, Resultados, Horários,
   Escalas Avançadas. Every chart is created with Apex's default light theme, whose foreColor
   (#373d3f) is written straight onto each legend label (inline style.color, hence !important)
   and axis label (SVG fill attribute), so legends such as the absence-code names under the
   Dashboard's bar charts render dark gray on the dark card. Overridden here once instead of
   passing theme.mode to each chart's options. Data labels inside bars/slices and the tooltip
   (still a white box with dark text) are left alone — they already contrast with their own
   background. */
body[data-bs-theme="dark"] .apexcharts-legend-text {
    color: var(--ic-text-default) !important;
}

body[data-bs-theme="dark"] .apexcharts-xaxis-label,
body[data-bs-theme="dark"] .apexcharts-yaxis-label,
body[data-bs-theme="dark"] .apexcharts-xaxis-group-label {
    fill: var(--ic-text-muted);
}

body[data-bs-theme="dark"] .apexcharts-xaxis-title-text,
body[data-bs-theme="dark"] .apexcharts-yaxis-title-text,
body[data-bs-theme="dark"] .apexcharts-title-text,
body[data-bs-theme="dark"] .apexcharts-subtitle-text {
    fill: var(--ic-text-emphasis);
}

/* Grid lines (#e7e7e7) and the Auditorias chart's striped rows (#f3f3f3 at 50%) are light
   fills meant for a white card — bright bands/lines on a dark one. */
body[data-bs-theme="dark"] .apexcharts-gridline {
    stroke: var(--ic-border-subtle);
}

body[data-bs-theme="dark"] .apexcharts-grid-row:not([fill="transparent"]) {
    fill: var(--ic-surface-hover);
}

/* Smooth theme transitions */
.navbar,
.card,
.btn,
.modal-header,
.badge,
.alert,
.progress-bar {
    transition: var(--theme-transition);
}
body {
    visibility: hidden; /*this visibility is toggled back when setThemeColor is finish*/
    font-size: var(--it-font-size-base);
}

