/* ========================================================================== Construmarket Theme - dark-mode.css A real, deliberately-designed dark theme for every surface this plugin itself repaints in corporate.css/helpdesk.css - not a generic invert filter. Hooks into GLPI 11's OWN dark-mode toggle (confirmed live: GLPI stamps `data-glpi-theme-dark="1"` on the moment a user switches to dark mode from their own preferences, the same attribute its own compiled CSS and bundled dark asset variants - e.g. lib/flatpickr/themes/dark.min.css - key off) instead of inventing a second, competing dark-mode switch of its own. Every rule below is scoped under that one attribute selector, so a light-mode session is never touched by this file at all. Palette choice: dark-mode surfaces reuse the SAME navy family already proven on the sidebar/hero/footer in corporate.css/helpdesk.css (the --cm-navy-N / --cm-yellow-N tokens defined there), not new invented colors - dark mode reads as "the same brand, inverted", not a bolted-on generic dark theme, and per the request this never touches the actual branding (logo, palette, layout), only how existing colors map to light vs. dark surfaces. Why explicit per-selector overrides instead of just redefining --cm-white/--cm-ink at the root: both tokens are genuinely dual-purpose in the base files - most uses are "light card surface" / "dark text on a light surface" (needs to flip here), but a real minority are "text that must stay literally white/dark regardless of theme" (the sidebar, hero and footer's own white text on their own permanently-dark brand backgrounds, and dark text sitting on the gold accent pill/banner, which stays light-on-gold in both modes). Blanket-redefining either token would silently break those. --cm-gray-bg, --cm-text, --cm-primary-light and the --cm-*-soft status tints, by contrast, are ALL single-purpose in both files (verified by grep before writing this - only ever "light surface tint" / "muted text on a light surface") so those four are safely redefined once at the root and cascade automatically into every rule that already consumes them - no duplication needed, and impossible to miss a spot. ========================================================================== */ html[data-glpi-theme-dark="1"] { /* -- Safe-to-redefine base tokens (see file header) -- Values below are the exact 2026 palette-spec dark-mode hexes (body/content, texto secundario) rather than color-mix() derivations - that spec gives explicit dark-mode colors, not "a darker version of the light one", so they're taken literally here the same way corporate-vars.css takes the light-mode base colors literally. --cm-primary itself is untouched (no override needed): it's already #1F5EAD from corporate-vars.css, which the palette spec lists as this exact token's dark-mode "item activo" value too. */ --cm-gray-bg: #070D17; --cm-text: #A8B4C5; --cm-primary-light: color-mix(in srgb, var(--cm-primary) 24%, transparent); /* Exact hexes from the app-wide dark-mode palette spec, not the light-mode status colors (--cm-success #2F9E5B etc. defined once in corporate.css and shared by both modes by default) - redefined here, dark-mode-only, so light mode's own values are untouched. */ --cm-success: #22C55E; --cm-warning: #F59E0B; --cm-danger: #EF4444; --cm-success-soft: color-mix(in srgb, var(--cm-success) 22%, transparent); --cm-warning-soft: color-mix(in srgb, var(--cm-warning) 22%, transparent); --cm-danger-soft: color-mix(in srgb, var(--cm-danger) 22%, transparent); /* -- New dark-only tokens, used by the explicit overrides below -- */ --cm-dark-surface: #0B1422; --cm-dark-surface-alt: #101B2B; --cm-dark-border: #20324A; --cm-dark-text: #F8FAFC; --cm-dark-text-muted: #A8B4C5; --cm-dark-text-faint: #64748B; --cm-dark-shadow: 0 12px 32px rgba(0, 0, 0, .45); /* History: the literal palette-spec hex (#123A73) first read as a loud, high-contrast bar against near-black rows and was twice softened (80/20, then 92/8 color-mix tints). A later design pass restored the full #123A73 deliberately, once the ROWS themselves were re-tuned to a closer navy scale (see the .table tbody rules below) - against that subtler background the same header hex now reads as "clear header identity", not "loud accent". The actual applied value lives as a direct hex on the .table thead th rule itself further down (it needs to beat corporate.css's own var(--cm-table-header-bg)-based light-mode rule by cascade order, which a variable redefinition alone doesn't reliably do here) - this token is kept in sync for any other rule that wants the same color by reference. */ --cm-table-header-bg: #123A73; /* -- Tabler variable bridge, same pattern corporate.css already uses for --tblr-primary/--tblr-link-color -- Explicit selectors below (body/.page/.page-wrapper/.content/table rows...) only reach the templates this theme has actually seen and targeted by class name. Reported live: the Setup > Plugins/Marketplace screen renders on a template this theme never covered and stayed plain black regardless - a different screen would surface the same gap tomorrow. Every page in GLPI 11 is built on Tabler, and Tabler itself paints "page/card background" from ITS OWN css variables, not a hardcoded color - redefining that variable once here means any Tabler surface this theme hasn't explicitly styled still inherits the navy family automatically instead of Tabler's own near-black dark default, closing this gap structurally instead of one selector at a time. */ --tblr-body-bg: var(--cm-gray-bg); --tblr-bg-surface: var(--cm-dark-surface); --tblr-bg-surface-secondary: var(--cm-dark-surface-alt); --tblr-card-bg: var(--cm-dark-surface); /* Same bridge, for GLPI's own native status colors (badges like "Activo/Pendiente/Inactivo", the Sí/No active-state dot, anything else built on Tabler's semantic success/warning/danger rather than this theme's own --cm-success/warning/danger) - without this, only this theme's OWN badges (.cm-tl-badge-*) would pick up the new hexes, and every GLPI-native status indicator would keep using Tabler's stock dark-mode green/amber/red regardless. */ --tblr-success: var(--cm-success); --tblr-success-rgb: 34, 197, 94; --tblr-warning: var(--cm-warning); --tblr-warning-rgb: 245, 158, 11; --tblr-danger: var(--cm-danger); --tblr-danger-rgb: 239, 68, 68; } /* Sidebar - corporate.css's .navbar-vertical gradient is NOT theme-aware on its own (same navy-700/900/950 tokens regardless of light/dark mode, since those two "modes" are actually two independent things: the sidebar was always a dark navy surface even in an otherwise-light session). The 2026 palette spec calls for a visibly different, deeper set of stops once the REST of the app also goes dark - same gradient shape/role as the light-mode one (a lighter top stop fading through a dominant tone into the darkest bottom stop), just retuned to the spec's own dark hexes instead of light-mode's computed navy scale. */ html[data-glpi-theme-dark="1"] .navbar-vertical { background: linear-gradient(180deg, #123A73 0%, #0D2855 58%, #070D17 100%) !important; } /* ---- Base text -------------------------------------------------------- */ /* Page background: GLPI's own native dark mode paints this near-pure-black by default - left untouched until now, which is why the app's own page background never matched the navy family used everywhere else this theme paints (sidebar, cards, table rows). --cm-gray-bg (#070D17) was tried first, but reported live as still reading as plain black on a real monitor - at that luminance the human eye can't tell it apart from true black, defeating the point. --cm-dark-surface-alt is noticeably lighter/bluer while staying just as "dark mode", so the navy family actually reads as navy here instead of black. .page/.page-wrapper/.content are GLPI's own Tabler layout wrappers - covered defensively since whichever one actually paints the visible background varies by page template. html itself is included too - on a page whose real content is shorter than the viewport (an empty list's "No results found", the Marketplace/ Plugins screen), body only paints as tall as its own content unless something forces it to stretch; the empty space below/around it falls through to 's own background instead, which was never touched here and defaulted back to GLPI's native near-black. Reported live as two visibly different "blacks" depending on which page had how much content - this closes that gap so every page, short or tall, shows the exact same navy. */ /* .container-fluid deliberately NOT included here - the horizontal header's own .header-container carries that same Bootstrap utility class alongside its gradient background (see the header rules further down), and a flat background-color here would paint a solid navy rectangle over part of that gradient. main/#page are page-layout roots, not a reused utility class, so they're safe to cover broadly. */ /* --cm-dark-surface-alt (#101B2B) was tried here first, one step lighter than pure --cm-gray-bg, specifically to read as "clearly not black" on its own. A later, more complete design pass gave an exact full-app hex table instead ("Fondo aplicación: #070D17") - that table's own internal contrast (app bg darkest, table container/cards one step up, header/accents brighter still) is what carries the "not flat black" read now, not the app background needing to be lightened in isolation - so this reverts to matching that spec's own literal value. */ html[data-glpi-theme-dark="1"], html[data-glpi-theme-dark="1"] body, html[data-glpi-theme-dark="1"] .page, html[data-glpi-theme-dark="1"] .page-wrapper, html[data-glpi-theme-dark="1"] .content, html[data-glpi-theme-dark="1"] main, html[data-glpi-theme-dark="1"] #page { background-color: var(--cm-gray-bg); } html[data-glpi-theme-dark="1"] body { color: var(--cm-dark-text-muted); } /* Links (table cell logins/emails, everywhere corporate.css's plain `a { color: var(--cm-primary); }` applies) - --cm-primary itself (#1F5EAD) is untouched in dark mode (it's also the spec's own "item activo" dark value), but at body-text size against these navy backgrounds it reads noticeably more muted than on a white page. --cm-primary-vivid (#3478D1, already defined in corporate.css) is the brighter blue the palette spec calls out specifically for links. */ html[data-glpi-theme-dark="1"] a { color: var(--cm-primary-vivid); } html[data-glpi-theme-dark="1"] h1, html[data-glpi-theme-dark="1"] h2, html[data-glpi-theme-dark="1"] h3, html[data-glpi-theme-dark="1"] .card-title { color: var(--cm-dark-text); } html[data-glpi-theme-dark="1"] .form-label { color: var(--cm-dark-text-muted); } /* ---- Cards / modals / dropdowns --------------------------------------- */ html[data-glpi-theme-dark="1"] .card { /* Flat, matching the light-mode .card change in corporate.css - see that rule's own note. background-color was missing entirely here - every .card (a plain Tabler component used all over GLPI, not just this theme's own widgets) silently fell through to Tabler's own near-black dark default. Reported live on the Setup > Plugins/ Marketplace screen, whose big panel is exactly one of these - almost certainly true of any other plain-.card screen this theme hasn't specifically visited yet too, same root cause. */ background-color: var(--cm-dark-surface); border-color: var(--cm-dark-border); box-shadow: none; } /* A card nested inside another card (the Marketplace's own plugin tiles inside its outer listing panel, same pattern as any future "cards inside a card" screen) steps one shade lighter, so the two levels still read as distinct surfaces instead of one flat block. */ html[data-glpi-theme-dark="1"] .card .card { background-color: var(--cm-dark-surface-alt); } html[data-glpi-theme-dark="1"] .card-header { /* Tab-strip/header band ("Installed | Discover" on the Marketplace screen, any other .card-header) - distinct hex from the palette spec, one step toward the sidebar's own blue rather than a plain surface tint. */ background-color: #0F2748; border-bottom-color: var(--cm-dark-border); } /* .card-footer - same missing-background gap as .card itself: the pagination/"rows per page" row at the bottom of every table lives here, and without this it fell through to Tabler's own near-black default, standing out as a stray black block against the rest of the now-navy card (reported live on the Entities list). Matches .card's own surface so header/body/footer all read as one continuous panel. */ html[data-glpi-theme-dark="1"] .card-footer { background-color: var(--cm-dark-surface); border-top-color: var(--cm-dark-border); } /* The horizontal header's collapsible top-nav (Bootstrap's own .navbar-collapse, id="navbar-menu" - see corporate.css's long note on the real header markup) sits as an empty middle stretch between the breadcrumb and the search box on wide screens where there's nothing to show in it. Reported live as a solid black rectangle sitting on top of the header's own blue gradient - Tabler evidently paints a dark background on this component by default, fully opaque, so the gradient underneath never had a chance to show through. Forced transparent so the parent header's gradient is the only thing painting that space, exactly as intended. */ html[data-glpi-theme-dark="1"] header:has(.navbar-brand) .navbar-collapse, html[data-glpi-theme-dark="1"] header:has(.navbar-brand) #navbar-menu { background: transparent !important; } html[data-glpi-theme-dark="1"] .modal-footer { background: var(--cm-dark-surface-alt); } html[data-glpi-theme-dark="1"] .dropdown-menu { border: 1px solid var(--cm-dark-border); box-shadow: var(--cm-dark-shadow); } html[data-glpi-theme-dark="1"] .dropdown-item:hover, html[data-glpi-theme-dark="1"] .dropdown-item:focus { color: var(--cm-dark-text); } /* ---- Tables ------------------------------------------------------------ */ /* Third iteration on the header color specifically - #123A73 (the literal palette-spec hex) was first tried plain, reported as too loud/dominant next to near-black rows and softened to an 8% tint instead. Now that the rows themselves sit on a much closer navy scale (this whole block below), the same #123A73 reads as a clear, deliberate header band instead of a jarring one - restored per an explicit follow-up design pass: "mantendría el header azul #123A73, porque crea una identidad visual muy clara para todas las tablas del sistema". */ /* Reported live as showing a left-to-right gradient (brighter under the first column, darker toward the last) instead of one flat color - Tabler's own default .table header styling paints a subtle glossy highlight via background-image, separate from background-color; since this rule only ever set the `background` shorthand (which should reset background-image to none, but evidently isn't winning that specific sub-property against Tabler's own rule), that highlight was still showing through on top of the flat navy underneath. Explicit background-image:none + !important on both closes that gap regardless of which of Tabler's rules is actually responsible. */ html[data-glpi-theme-dark="1"] .table thead th, html[data-glpi-theme-dark="1"] table.table thead th { background-color: #123A73 !important; background-image: none !important; border-bottom-color: color-mix(in srgb, var(--cm-primary) 35%, transparent); } /* Full re-tune per an explicit follow-up design pass, moving away from the previous "near-black odd row" toward subtler navy-on-navy alternation - odd/even/hover/selected all get their own distinct step instead of reusing --cm-gray-bg/--cm-dark-surface-alt (which read as too high-contrast against each other, "como una tabla tradicional" per the request - close, low-contrast steps are what makes the table feel like one cohesive navy surface instead of black-bars-in-a-table). */ html[data-glpi-theme-dark="1"] .table tbody td, html[data-glpi-theme-dark="1"] table.table tbody td { background-color: #0E1726; } html[data-glpi-theme-dark="1"] .table tbody tr:nth-child(even) td, html[data-glpi-theme-dark="1"] table.table tbody tr:nth-child(even) td { background-color: var(--cm-dark-surface); } html[data-glpi-theme-dark="1"] .table tbody tr:hover td, html[data-glpi-theme-dark="1"] table.table tbody tr:hover td { background-color: #15243A !important; } /* Checkbox-selected row - :has() (already used elsewhere in this theme, e.g. header:has(.navbar-brand)) picks the row up directly from its own checkbox state, no dependency on whichever class GLPI's JS may or may not add for "selected". Full brand-blue + white text/links, same "unmistakably selected" treatment as the mockup, reserved for this one state only - not spent on ordinary rows. */ html[data-glpi-theme-dark="1"] .table tbody tr:has(input:checked) td, html[data-glpi-theme-dark="1"] table.table tbody tr:has(input:checked) td { background-color: var(--cm-primary) !important; color: #FFFFFF; } html[data-glpi-theme-dark="1"] .table tbody tr:has(input:checked) td a, html[data-glpi-theme-dark="1"] table.table tbody tr:has(input:checked) td a { color: #FFFFFF; } html[data-glpi-theme-dark="1"] .table tbody td, html[data-glpi-theme-dark="1"] table.table tbody td { border-bottom-color: var(--cm-dark-border); } html[data-glpi-theme-dark="1"] .pagination .page-item.disabled .page-link { color: var(--cm-dark-text-faint); } html[data-glpi-theme-dark="1"] .tickets-banner .nav-tabs .nav-link:not(.active) { background: var(--cm-dark-surface); color: var(--cm-dark-text-muted); } html[data-glpi-theme-dark="1"] .tickets-banner .tab-content, html[data-glpi-theme-dark="1"] .tickets-banner .table-responsive { background: var(--cm-dark-surface); border-color: var(--cm-dark-border); } /* ---- Forms / inputs ----------------------------------------------------- */ html[data-glpi-theme-dark="1"] .form-control, html[data-glpi-theme-dark="1"] .form-select { background-color: var(--cm-dark-surface); color: var(--cm-dark-text); } html[data-glpi-theme-dark="1"] .form-control::placeholder { color: var(--cm-dark-text-faint); } html[data-glpi-theme-dark="1"] .form-control:hover, html[data-glpi-theme-dark="1"] .form-select:hover { border-color: color-mix(in srgb, var(--cm-primary) 45%, transparent); } html[data-glpi-theme-dark="1"] .form-control:focus, html[data-glpi-theme-dark="1"] .form-select:focus { background-color: var(--cm-dark-surface-alt); color: var(--cm-dark-text); } html[data-glpi-theme-dark="1"] .form-control:disabled, html[data-glpi-theme-dark="1"] .form-select:disabled { background-color: var(--cm-dark-surface); color: var(--cm-dark-text-faint); } html[data-glpi-theme-dark="1"] .input-group-text { background-color: var(--cm-dark-surface-alt); color: var(--cm-dark-text-muted); } html[data-glpi-theme-dark="1"] .dropzone, html[data-glpi-theme-dark="1"] .filepond--panel-root { background: var(--cm-dark-surface) !important; } html[data-glpi-theme-dark="1"] .tox .tox-toolbar, html[data-glpi-theme-dark="1"] .tox .tox-toolbar__primary, html[data-glpi-theme-dark="1"] .tox .tox-toolbar-overlord { background: var(--cm-dark-surface-alt) !important; } html[data-glpi-theme-dark="1"] .tox.tox-tinymce { border-color: var(--cm-dark-border) !important; } /* Tom-Select / Select2 / Choices.js / native