/* Skirret — Tema "Pedra Bruta": COMPONENTES do produto =================================================== Todas as cores vivem em variáveis CSS (custom properties), nunca em valores fixos espalhados pelas regras abaixo. Isso é proposital: um Tema publicado (`docs/37` §5) sobrescreve tokens e a interface inteira se adapta, sem tocar em nenhum componente individual. **O bloco `:root` NÃO mora mais aqui** — saiu para `tokens.css` em 26/08/2026 (Prompt #201, R11 do `docs/59`). Este arquivo traz os COMPONENTES DO PRODUTO: as telas autenticadas, com tema, escala de fonte e densidade. O site público tem os seus em `landing.css`, e os dois consomem os MESMOS tokens. A separação é de contexto, não de estilo: o visitante não está autenticado, não tem tema nem preferência, e a cadeia de herança de quatro níveis do `docs/37` é peso morto para ele. Ver `docs/Brand_Guidelines_Skirret.md` para o simbolismo de cada cor. */ /* BASE TIPOGRÁFICA: 20px, não 16px (Prompt #147 — decisão de Wagner de 17/08/2026). O zoom de 125% era o tamanho em que Wagner validava todas as telas, e passou a ser o padrão. A conta é direta: 16px × 125% = **20px**. Com a base em 20px, a escala de 100% renderiza exatamente o que hoje se obtém em 125%. O QUE NÃO SE FEZ, e o motivo. A saída fácil seria renomear o rótulo — fazer o controle exibir "100%" enquanto aplica o fator 125. Isso quebraria a semântica de tudo o que depende do número: o valor gravado em `Usuario.escala_fonte` deixaria de significar o que diz, e a próxima pessoa a ler `--sk-escala-fonte: 100` no DOM concluiria que está no tamanho de fábrica. Aqui a escala continua sendo multiplicação sobre a base; **só a base cresceu**. POR QUE O ESPAÇAMENTO EM px NÃO FOI CONVERTIDO JUNTO. Padding, gap, margin e bordas continuam em px de propósito. A referência visual é o 125% de HOJE, onde esses mesmos px já convivem com texto de 20px — a base nova reproduz aquele rendering pixel por pixel. Converter o espaçamento para `rem` agora mudaria justamente o que foi validado. Bordas de 0,5–1px, então, nunca escalam: uma linha de 1,25px é uma linha borrada. EMENDA DO PROMPT #177 — a base virou TOKEN. O `20px` fixo saiu daqui e virou `--sk-base-fonte`, parametrizável por Tema na MASTER-08. O mecanismo já era este desde o #147; o que mudou foi a constante virar variável. **O fallback `20px` fica de propósito:** um Tema antigo que não traga o token continua renderizando exatamente como hoje, em vez de colapsar para o `font-size` do navegador. E a composição é de UM eixo só: o Tema dá a base, o usuário multiplica por cima dela. Os dois nunca se multiplicam entre si — `docs/37` §8.1 registra o que foi recusado e por quê. */ html { font-size: calc(var(--sk-base-fonte, 20px) * var(--sk-escala-fonte) / 100); } * { box-sizing: border-box; } /* Cabeçalho/rodapé fixos, rolagem só em .sk-main (docs/14, Prompt #60) — flexbox em coluna, com só o miolo (.sk-main) rolável, é o único jeito de garantir as duas exigências ao mesmo tempo: cabeçalho/rodapé nunca se movem (nem "sticky", que só gruda ao rolar — aqui eles não fazem parte de nenhuma área rolável pra começo de conversa) E o rodapé permanece no fim da viewport mesmo com conteúdo mais curto que a tela (um `position: sticky`/`fixed` isolado não resolveria esse segundo caso sem o mesmo truque de flex/grid por baixo). Revertido em @media print, abaixo — um `.sk-artigo-para-imprimir` mais alto que 100vh não pode ficar cortado pelo `overflow: hidden` daqui. */ body { background: var(--sk-bg); color: var(--sk-fg); font-family: var(--sk-font-body); font-size: 0.875rem; line-height: 1.6; margin: 0; padding: 0; display: flex; flex-direction: column; height: 100vh; overflow: hidden; } a { color: var(--sk-gold); text-decoration: none; } a:hover { text-decoration: underline; } h1, h2, h3 { font-family: var(--sk-font-display); font-weight: 500; margin: 0 0 0.5em; } /* Componentes nativos do navegador (` (Prompt #111) — o chevron entra nele, nunca no input, para não competir com o texto digitado. `padding-right` no input abre espaço para o glifo não sobrepor o fim do texto. */ .sk-combobox input { padding-right: var(--e6); } .sk-combobox::after { content: "▾"; position: absolute; right: 11px; top: 50%; transform: translateY(-50%); font-size: 0.7rem; color: var(--sk-muted); pointer-events: none; } /* Seleção de Widgets (LOJA-12/LOJA-13, SelecaoWidgetsForm, campo "widgets") — Django renderiza CheckboxSelectMultiple como sem nenhum alinhamento; mesmo tratamento de .sk-field-checkbox acima, mas por id (form.as_p não passa por nenhuma classe própria do app). Mesmo id nas duas telas, então o mesmo fix corrige as duas de uma vez. */ #id_widgets label { display: flex; align-items: center; gap: var(--e2); } /* .sk-card form input (acima) dá width:100% a QUALQUER , sem excluir checkbox (diferente de .sk-field input[type="checkbox"], que já tem essa exclusão) — dentro do label em flex acima, isso infla a "flex-basis" do checkbox pro tamanho da linha toda (item de flex fica enorme, mesmo o desenho nativo do checkbox continuando pequeno), empurrando o texto do nome do widget pra fora do alinhamento. */ #id_widgets input[type="checkbox"] { width: auto; flex: none; } /* LISTA DE CAIXAS DE MARCACAO, no sistema inteiro (docs/14 Principio 50, emenda de 24/09/2026 - Prompt #459, Wagner na validacao local do #457: "os controles nas posicoes adequadas - a esquerda do texto"). O CheckboxSelectMultiple do Django desenha - a caixa DENTRO do rotulo. As regras de rotulo de formulario acima (Principio 29/43) fazem todo