/* ===================================================================== PADRÃO VISUAL PCNET · TEMA ESCURO DO PARQUE Generalizado de lansentinelbackups/public/lsb-tema-escuro.css, que foi onde estes valores nasceram e foram MEDIDOS: 22 pares de contraste, 22 aprovados. Nenhum valor aqui é palpite, e a margem mais apertada é --pk-danger contra o card (3.33:1, mínimo 3.0 para alvo gráfico): clarear o vermelho reprova o branco dentro do botão, escurecer some contra o fundo. Não encoste nele sem refazer a medição. Quatro propriedades o mantêm seguro de espalhar por 15 plugins: 1. É OPT-IN POR CLIQUE. Não há `prefers-color-scheme` em lugar nenhum — aquele bloco impõe o escuro a quem nunca pediu, e é BLOQUEIO no auditor da skill (scripts/auditar_css.py:329). O claro é o padrão. 2. NÃO REDEFINE UM ÚNICO COMPONENTE. Só valores de --pk-*. É a prova de que o contrato de tokens funciona: pcnet-componentes.css e o CSS de cada plugin não sabem que este arquivo existe, e não precisam saber. 3. É REVERSÍVEL EM UM `mv`. O setup.php registra por is_file(); renomear para .off desliga o tema escuro em TODO o parque na hora, sem editar PHP e sem reiniciar o Apache. 4. SÓ É CARREGADO QUANDO A PREFERÊNCIA JÁ É ESCURA. O PHP lê o cookie antes de imprimir o (PluginPcnetuiTema::escuroNestaRequest). Para quem fica no claro isto é ZERO byte, e para quem escolheu o escuro não há lampejo branco: o CSS chega ANTES do primeiro paint. --------------------------------------------------------------------- POR QUE `!important` EM TODA DECLARAÇÃO — e é o orçamento inteiro do arquivo, 42 delas, justificadas de uma vez aqui: O portalpcnet registra o skin em TODA sessão helpdesk, sem gate de URL (setup.php, plugin_portalpcnet_should_skin_native), e declara os tokens em `html:root:has(> body:not(.central))` — especificidade (0,2,2). Um seletor de atributo como o nosso vale (0,1,1) e PERDE. Medido: sem !important, 42 de 42 tokens são anulados e o botão de tema não muda nada para o cliente. Foi o que aconteceu com o tema do lansentinelbackups, que nunca funcionou em helpdesk e ninguém notou. `!important` é a semântica exata do que se quer aqui: a escolha EXPLÍCITA da pessoa vence toda outra fonte de token. E é a única forma de vencer (0,2,2) sem inventar um seletor mais frágil. Alternativa registrada para depois, quando houver validação no navegador: uma linha em portalpcnet/setup.php pulando o registro de skin/pcnet-tokens.css em página de plugin. Aí este arquivo perde os !important. Não se faz agora porque mexe na home de 1.512 pessoas. --------------------------------------------------------------------- AS CORES CHEIAS NÃO MUDAM DE TEMA. --pk-green (#8CC63F), --pk-danger, --pk-warning e --pk-info são exatamente os mesmos do claro. Não é economia: foi medido que os quatro atendem às duas restrições ao mesmo tempo — texto legível dentro do preenchimento e preenchimento visível contra o card escuro. Manter o mesmo verde é também o que faz a tela continuar parecendo do mesmo produto que o portalpcnet, que não tem tema escuro nenhum. O que muda é o que está POR BAIXO: superfícies, tinta, os fundos "-soft" e os degraus de verde que servem a texto e ícone — no claro eles escurecem, no escuro eles clareiam. ===================================================================== */ /* O seletor é `:not([...="claro"])` e não `[...="escuro"]` de propósito. O CSS chega no antes de o JS carimbar o atributo (JS de plugin é servido no RODAPÉ — templates/layout/parts/page_footer.html.twig:33). Com `[="escuro"]` haveria um frame claro até o carimbo. Com `:not()`, o arquivo já vale no primeiro paint, e clicar em "claro" o desliga na hora, sem recarregar. */ html[data-pcnet-tema="escuro"] { /* --- MARCA ------------------------------------------------------- */ /* O verde cheio e o texto sobre ele são os MESMOS do claro. */ --pk-green: #8CC63F !important; --pk-on-green: #143a05 !important; /* 6.27:1 sobre o verde */ /* No claro estes escurecem para render sobre o branco; no escuro clareiam pela mesma razão, invertida. */ --pk-green-hover: #9ad14e !important; /* 7.09:1 com --pk-on-green */ --pk-green-dark: #9ed04f !important; /* ÍCONE e traço — 8.87:1 no card */ --pk-green-ink: #a9d95f !important; /* TEXTO verde — 9.78:1 no card */ --pk-green-soft: #1e2a16 !important; /* fundo de chip: verde rebaixado */ --pk-green-line: #33481f !important; /* Faixa de luz do título. NÃO é o mesmo valor do claro: lá o brilho é mais claro que a tinta; aqui a tinta (--pk-ink #eaf2e8) já é quase branca e clarear não produz reflexo — o brilho tem de ser CROMÁTICO. O verde cheio da marca contra a tinta clara lê como luz colorida passando. */ --pk-on-dark: #ffffff !important; /* --- SUPERFÍCIES -------------------------------------------------- */ /* MUSGO ESCURO — verde dessaturado, da família da logo. Até 2026-08-24 aqui havia ardósia de viés AZUL (#141821 = R20 G24 B33, azul como canal forte), com a justificativa de que fundo colorido faria o verde da marca sumir. O dono abriu os plugins e a primeira coisa que viu foi "um fundo azul" numa identidade verde — a justificativa estava certa no princípio e errada na conclusão: o que apaga o verde é fundo SATURADO, não fundo com viés. A saída é viés sem saturação: #111a13 é R17 G26 B19 — o verde é o canal forte, mas está a 9 pontos do vermelho, longe do verde-quase-preto (#0d1a0d) que seis plugins usavam. Medido contra esta paleta, o verde da marca sobre o card dá 7.59:1 (era 7.85:1 na ardósia): a perda é de 0.26 num valor que precisa de 3.0. E DOIS PARES MELHORARAM, porque o par tinta/fundo ficou mais afastado: a tinta fraca sobre o card ia de 4.43:1 — ABAIXO do mínimo de 4.5 — para 4.77:1, e sobre o fundo de 4.90:1 para 5.46:1. A separação card/fundo sobe de 1.11 para 1.14 e a da borda de 1.36 para 1.51. */ --pk-bg: #111a13 !important; --pk-surface: #1a271d !important; --pk-surface-2: #223125 !important; --pk-border: #2f4634 !important; --pk-border-hover: #3f5a44 !important; /* A hairline verde continua sendo a assinatura, com mais alfa: a 12% ela simplesmente não existe sobre um card escuro. */ --pk-hairline: rgba(140, 198, 63, .16) !important; --pk-hairline-hover: rgba(140, 198, 63, .34) !important; /* --- TINTA -------------------------------------------------------- */ /* Branco puro sobre escuro vibra e cansa. A tinta é levemente esverdeada e dessaturada — acompanha o fundo, como a antiga acompanhava a ardósia: baixa o brilho percebido sem perder contraste (13.58:1 no card). */ --pk-ink: #eaf2e8 !important; --pk-ink-2: #aec3ae !important; /* 8.30:1 no card (era 7.60:1) */ /* A tinta fraca é calibrada contra --pk-surface-2, e NÃO contra o fundo da página: o card elevado é a superfície mais CLARA em que ela pode cair, e vários cards deste parque a usam sobre um gradiente que termina nela. #7f947f dava 5.46:1 no fundo mas 4.20:1 no card elevado — foi assim que "Hoje" e "90 dias atrás" do Firewall ficaram abaixo do mínimo sem que a conta feita contra o fundo denunciasse. #8ba18b passa nas três: 6.41 no fundo, 5.60 no card, 4.93 no card elevado. */ --pk-ink-3: #8ba18b !important; /* Tinta do cabeçalho de coluna (pcnetui-forma.css, família tabela). No claro é a Tinta Fraca, como no portal; no escuro ela NÃO serve, porque vários plugins pintam o cabeçalho com o verde da marca translúcido por cima da superfície rebaixada, e ali a fraca dá 4,22:1 (medido na configuração do Inventário em 2026-09-25: Endpoint/Método/Auth/Função a 4,21). A média dá 6,25 no mesmo fundo e 5,42 até num verde de 15%. */ --pk-thead-ink: var(--pk-ink-2) !important; /* --- SEMÂNTICAS ---------------------------------------------------- */ /* As cheias inalteradas; -soft, -line e -ink invertidos. */ --pk-info: #2e7dd1 !important; --pk-info-soft: #152435 !important; --pk-info-line: #28405c !important; --pk-info-ink: #7cb8f0 !important; --pk-warning: #d97706 !important; --pk-warning-soft: #2a2213 !important; --pk-warning-line: #4c3d1c !important; --pk-warning-ink: #e8b45c !important; --pk-danger: #dc2626 !important; --pk-danger-soft: #2d1719 !important; --pk-danger-line: #53272a !important; --pk-danger-ink: #f08a8d !important; /* --- ELEVAÇÃO ------------------------------------------------------ */ /* Sombra no escuro é quase invisível: o que separa um card do fundo passa a ser a BORDA, e a sombra vira só profundidade. Por isso os valores ficam mais opacos e mais pretos que os do claro (rgba(16,24,40,.05..12)), onde eles apenas sumiriam. */ --pk-shadow-sm: 0 1px 2px rgba(0, 0, 0, .40), 0 1px 3px rgba(0, 0, 0, .30) !important; --pk-shadow-md: 0 2px 6px rgba(0, 0, 0, .42), 0 8px 20px rgba(0, 0, 0, .38) !important; --pk-shadow-lg: 0 10px 34px rgba(0, 0, 0, .55) !important; --pk-shadow-rest: 0 16px 34px rgba(0, 0, 0, .55) !important; --pk-shadow-float: 0 20px 40px rgba(0, 0, 0, .62) !important; /* O brilho verde do botão rende MAIS no escuro; baixa-se o alfa para não virar halo. */ --pk-shadow-green: 0 2px 6px rgba(140, 198, 63, .26) !important; --pk-shadow-green-hover: 0 6px 16px rgba(140, 198, 63, .34) !important; /* Realce de linha sob o cursor: 8% de verde não aparece sobre #1a271d. */ --pk-green-wash: rgba(140, 198, 63, .13) !important; --pk-hover-bg: rgba(140, 198, 63, .13) !important; /* --- VIDRO --------------------------------------------------------- */ /* 🔴 A SOMBRA INTERNA TEM DE VIRAR NO ESCURO, e não virava. `--pk-glass-inset` é o único relevo do parque e ficou de fora desta folha até 2026-09-01: no claro é brilho branco a 40% em cima-à-esquerda e sombra preta a 10% embaixo-à-direita, que é como a luz cai. Sobre o card escuro (`#1a271d`) esse branco a 40% é a coisa mais clara da peça e a preta a 10% some — o relevo lê INVERTIDO, como se o ladrilho fosse afundado por cima. No escuro o brilho é sutil (branco a 7%) e quem marca é a sombra (preta a 38%): a luz continua vindo de cima-à-esquerda, com os pesos trocados. */ --pk-glass-inset: inset 6px 6px 14px rgba(255, 255, 255, .07), inset -6px -6px 14px rgba(0, 0, 0, .38) !important; --pk-glass: rgba(26, 39, 29, .72) !important; --pk-glass-2: rgba(26, 39, 29, .85) !important; --pk-glass-bar: rgba(17, 26, 19, .84) !important; /* A força do TOM do cartão (pcnetui-forma.css, bloco CARD): 12% aqui contra 8% no claro. Medido com as cores cheias da casa sobre o vidro musgo: a 12% o pior caso é a Tinta Fraca sobre o verde da marca, 4,60:1; a 18% ela cairia a 4,03:1. No escuro o tom precisa de mais força para aparecer. */ --pk-card-tom-forca: 12% !important; --pk-kpi-tom-forca: 12% !important; /* @param · cartão de número: no escuro fica a da família (14% é só do claro) */ --pk-shadow-grade: 0 4px 12px rgba(0, 0, 0, .40) !important; --pk-shadow-grade-float: 0 10px 22px rgba(0, 0, 0, .50) !important; /* --- SETA DO , a barra de rolagem. Não há CSS que alcance o calendário do navegador por fora; só o color-scheme resolve. Declarado na CAIXA DO PLUGIN e não no : no documento inteiro ele mudaria também os controles das telas do GLPI, e plugin não mexe na estrutura do host. */ html[data-pcnet-tema="escuro"] .pk-app, html[data-pcnet-tema="escuro"] [data-pcnet-escopo] { color-scheme: dark; } /* ===================================================================== 🔴 A CAIXA DO PLUGIN PINTA O PRÓPRIO FUNDO — e sem isto o tema escuro NÃO FUNCIONA, por mais que os tokens acima mudem. O que acontecia até 2026-08-21: sete das caixas do parque não declaravam fundo nenhum, e por isso deixavam aparecer o fundo do GLPI, que é sempre claro (#f5f7fb, vindo de css_glpi.min.css). No tema claro isso funciona POR ACASO — fundo claro do host, tinta escura do plugin. Ligado o escuro, a tinta vira --pk-ink (quase branca) e o fundo continua o do host: texto quase branco sobre fundo quase branco. Medido no navegador, contando textos abaixo do contraste legível: flowpcnet estoque.php 127 textos invisíveis flowpcnet dashboard.php 44 frotapcnet registrar.php 7 krimbo report.php 6 lansentineldevices 4 1,1:1 de contraste, onde o mínimo legível é 4,5:1. Nenhum erro, nenhum log — e o meu QA aprovava, porque media se o TOKEN mudava em vez de olhar a tela. POR QUE AQUI E NÃO EM CADA PLUGIN: escrita sete vezes, seria sete lugares para divergir, e o plugin seguinte nasceria com o mesmo buraco. Aqui é um lugar só, e quem declarar `.pk-app` na caixa já entra certo. POR QUE SÓ NO ESCURO: no claro o fundo do host (#f5f7fb) e o nosso (--pk-bg, #eef1f6) são quase iguais mas não idênticos; pintar por cima criaria uma diferença de tom sem necessidade nenhuma. Mexe-se só no que está quebrado. ISTO NÃO CONTRADIZ o bloco final deste arquivo. Continua valendo que o plugin não repinta o chrome do GLPI: `main#page`, `.navbar` e o resto da moldura seguem intocados. O que se pinta aqui é a caixa DO PLUGIN — que é justamente o que a fronteira acordada manda ele pintar. O !important tem a mesma razão dos tokens acima (a folha do host é registrada ANTES da do consumidor, então empate de especificidade o host perde por ordem) e mais uma: `.crm-app` declara `background: none`, que sem força continuaria vencendo. ===================================================================== */ html[data-pcnet-tema="escuro"] .pk-app { background: var(--pk-bg) !important; color: var(--pk-ink) !important; } /* COMPONENTES DO BOOTSTRAP DENTRO DA CAIXA DO PLUGIN. Várias telas usam `.alert`, `.card` e `.table` do Tabler para conteúdo — não para a moldura. Esses componentes trazem fundo CLARO fixo do Bootstrap, e dentro da caixa escura o texto herda --pk-ink (quase branco): "Nenhum resultado encontrado" ficava a 1,13:1 no crmpcnet. ⚠️ Isto NÃO é repintar o chrome do GLPI, e a diferença está no seletor: só alcança o que está DENTRO de `.pk-app`, que é a caixa do plugin. `main#page`, `.navbar` e a moldura do host seguem intocados, como diz o bloco no fim deste arquivo. */ html[data-pcnet-tema="escuro"] .pk-app .alert, html[data-pcnet-tema="escuro"] .pk-app .list-group-item, /* A PAGINAÇÃO e a barra de busca do GLPI também aparecem dentro da caixa do plugin (search-limit, tab_bg_1/2, table-striped). Trazem fundo claro fixo do core, e no escuro o texto some — medido em "linhas / página" a 1,14:1. */ html[data-pcnet-tema="escuro"] .pk-app .search-limit, html[data-pcnet-tema="escuro"] .pk-app .tab_bg_1, html[data-pcnet-tema="escuro"] .pk-app .tab_bg_2, html[data-pcnet-tema="escuro"] .pk-app .table > :not(caption) > * > * { background-color: var(--pk-surface) !important; border-color: var(--pk-border) !important; color: var(--pk-ink) !important; } /* O `.card` do Tabler, separado do grupo acima em 2026-09-24: é CARTÃO, e o dono decidiu vidro do portal em todo cartão (pcnetui-forma.css, bloco CARD). A razão do `!important` continua — o fundo claro fixo do Bootstrap —, só o material muda: vidro musgo (.72) e fio verde, no lugar da superfície opaca e da borda neutra, e aceita o mesmo `--pk-card-tom` da camada. A tinta segue a mesma. */ html[data-pcnet-tema="escuro"] .pk-app .card { background-color: color-mix(in srgb, var(--pk-card-tom, var(--pk-glass)) var(--pk-card-tom-forca, 8%), var(--pk-glass)) !important; border-color: color-mix(in srgb, var(--pk-card-tom, var(--pk-hairline)) 35%, var(--pk-hairline)) !important; color: var(--pk-ink) !important; } @media (hover: hover) { html[data-pcnet-tema="escuro"] .pk-app .card:hover { background-color: color-mix(in srgb, var(--pk-card-tom, var(--pk-glass-2)) var(--pk-card-tom-forca, 8%), var(--pk-glass-2)) !important; border-color: color-mix(in srgb, var(--pk-card-tom, var(--pk-hairline-hover)) 45%, var(--pk-hairline-hover)) !important; } } /* ===================================================================== NADA ABAIXO, E ISSO É DECISÃO. Não se repinta o chrome do GLPI (main#page, .navbar, .page-header, aside.navbar-vertical). Funcionaria — a tela ficaria escura de ponta a ponta — mas seria o plugin mudando a aparência de markup que não é dele, e é exatamente o `background: … !important` que o lansentineldevices faz hoje e que este projeto veio remover. A moldura do host fica como o host a entrega, e o escuro vale só dentro da caixa do plugin. O contraste na fronteira é o preço consciente disso, e foi aceito explicitamente. Se um dia a decisão mudar, o caminho certo NÃO é acrescentar um bloco aqui: é o modo skin do padrão visual (references/glpi.md §5), que isola a tradução dos tokens do core num arquivo próprio, com checklist de upgrade. ===================================================================== */