/* ============================================================================
   VATSE — fundação de leitura e toque
   ============================================================================

   Carregada DEPOIS das folhas de cada vertical, em todo layout (públicas dos 22
   tenants, painel do dono e admin). Ela não redesenha nada: corrige o que
   impedia usar o produto no celular.

   Os quatro defeitos que originaram este arquivo, medidos em 390px de largura:

   1. TEXTO ILEGÍVEL. A escala foi desenhada em rem com valores muito baixos
      (0.5–0.8rem). Com raiz de 16px, a mediana do texto de corpo ficava entre
      9,8px e 13,4px, e o mínimo em 7,8px. Aqui a raiz sobe em telas pequenas,
      então texto E espaçamento crescem juntos e a proporção do desenho é
      preservada.

   2. ZOOM SOZINHO AO TOCAR NUM CAMPO. O iOS dá zoom em qualquer campo com
      fonte menor que 16px. Todos estavam menores.

   3. O SCROLL VAZAVA. Rolar dentro do menu lateral movia a página de fundo,
      porque faltava conter o encadeamento de rolagem.

   4. CONTROLES ILEGÍVEIS NO MODO ESCURO. Sem `color-scheme` declarado, o
      Safari em modo escuro pinta campos e selects com fundo escuro sobre uma
      página clara, e o texto some.
   ========================================================================= */

/* ---- 1. Escala de leitura --------------------------------------------- */

/* A raiz cresce conforme a tela encolhe. Parece invertido e não é: no celular
   a distância do olho é menor, mas a área é muito menor, e o desenho foi feito
   com uma escala que só se sustenta em monitor. */
/* O `!important` aqui é deliberado e é o único do bloco de escala. Várias
   páginas declaram a própria raiz depois desta folha (o construtor monta HTML
   completo, com `<style>` próprio), e sem ele o piso valeria em umas telas e
   não em outras — que é pior do que não ter piso, porque parece resolvido. */
/* A base é 17,5px e não os 16px do navegador. O piso do projeto é 0,80rem, e
   sobre 16px isso dá 12,8px: abaixo do que se pede para ler. Sobre 17,5px dá
   exatamente 14px. Foi essa a queixa original, e ela veio do monitor, antes
   ainda de o telefone entrar na conversa. */
html { font-size: 17.5px !important; }

@media (max-width: 430px) {
    html { font-size: 18px !important; }
}

/* ---- 2. Campos: nunca menos de 16px em telas de toque ------------------ */

/* Regra do iOS, não preferência de gosto: abaixo de 16px o Safari aplica zoom
   ao focar, a página desalinha e o visitante precisa fechar o teclado e
   reposicionar tudo à mão. */
@media (max-width: 900px) {
    input,
    select,
    textarea,
    .sc-input,
    .adm-input,
    [contenteditable="true"] {
        font-size: max(16px, 1rem) !important;
    }

    /* Alvo de toque: o mínimo que uma pessoa acerta sem ampliar. */
    button,
    .btn,
    [role="button"],
    input[type="submit"],
    input[type="button"],
    a.sc-btn,
    a.btn {
        min-height: 44px;
    }
}

/* ---- 3. Rolagem contida ----------------------------------------------- */

/* Sem isto, chegar ao fim de uma lista rolável repassa o movimento para a
   página de trás: o menu "gira a página inteira", que foi como o defeito
   apareceu para quem usou. */
:where(
    .admin-sidebar-nav,
    #admin-sidebar,
    .sc-chat-panel,
    .sc-chat-body,
    .vatse-chat-body,
    [data-scroll-contain]
) {
    overscroll-behavior: contain;
    -webkit-overflow-scrolling: touch;
}

/* O menu lateral aberto no celular precisa rolar sozinho, inteiro. */
@media (max-width: 900px) {
    #admin-sidebar {
        max-height: 100dvh;
        overflow-y: auto;
        overscroll-behavior: contain;
    }
}

/* Enquanto um painel sobreposto está aberto, o fundo não se move. A classe é
   posta pelo JS, e a posição fixa preserva a rolagem de onde a pessoa estava. */
body.vatse-scroll-travado {
    position: fixed;
    width: 100%;
    overflow: hidden;
}

/* ---- 4. Modo escuro do sistema ---------------------------------------- */

/* `color-scheme` diz ao navegador com que paleta pintar o que ELE desenha:
   campo, select, barra de rolagem, seletor de data. Sem a declaração, o Safari
   em modo escuro pinta esses controles de escuro dentro de uma página clara, e
   o texto digitado fica preto sobre preto. */
/* Nenhuma página do projeto tem desenho que responda a `prefers-color-scheme`:
   cada uma é clara ou escura por decisão própria, declarada em `data-mode`.
   Então o esquema não é uma preferência a consultar, é um fato a declarar, e
   declará-lo é o que impede o Safari de pintar controle escuro em página clara.
   O padrão é claro porque é o que a maioria das telas é; quem se declara
   escura corrige a si mesma. */
:root {
    color-scheme: light;
}

:root:is([data-mode="dark"], [data-theme="dark"]),
:root:has(> body[data-mode="dark"]),
:root:has(> body.dark-mode) {
    color-scheme: dark;
}

/* Rede de segurança para o campo de formulário: mesmo que uma página futura
   esqueça de se declarar, o texto digitado continua legível porque a cor vem
   do par de sistema (Field/FieldText), que combina entre si por definição. */
@media (prefers-color-scheme: dark) {
    :where(input, select, textarea):not([data-tema-proprio]) {
        background-color: Field;
        color: FieldText;
    }
}

/* ---- 5. Nada some fora da tela ---------------------------------------- */

@media (max-width: 900px) {
    /* `clip` e nao `hidden`. Os dois cortam o que vaza na horizontal, mas
       `hidden` transforma o corpo em contêiner de rolagem, e todo cabeçalho
       `sticky` para de grudar: no celular o botão do menu sumia ao rolar e a
       pessoa tinha de voltar ao topo da página para chegar no menu. `clip`
       corta sem criar contêiner, e o `sticky` continua valendo.
       Sem suporte a `clip`, é melhor uma barra de rolagem horizontal do que um
       cabeçalho que foge: por isso não há alternativa com `hidden`. */
    @supports (overflow-x: clip) {
        html, body { max-width: 100%; overflow-x: clip; }
    }

    :where(table) { display: block; overflow-x: auto; -webkit-overflow-scrolling: touch; }

    /* Onde a página já resolveu isso, ela manda. A região dela é rotulada e
       alcançável pelo teclado; a tabela virada em bloco não é nenhum dos dois.
       Duplicar os dois roladores ainda faz o de fora parar de rolar. */
    :where([role="region"], [data-agenda-day-scroll], [class*="overflow-x"]) :where(table) {
        display: table;
        overflow-x: visible;
    }
}

/* ------------------------------------------------------------------
   Legenda de grafico
   O ApexCharts escreve font-size no atributo style em tempo de execucao,
   entao nao ha folha do projeto para corrigir: so um seletor com peso
   maior alcanca. A legenda e texto de INTERFACE (a pessoa le para saber
   qual serie e qual), diferente do rotulo de eixo dentro do SVG, que
   segue a convencao da area e fica como esta.
   ------------------------------------------------------------------ */
.apexcharts-legend-text,
.apexcharts-legend-series span,
.apexcharts-legend-series {
    font-size: max(14px, 0.8rem) !important;
}

/* `small` vale 0,8 do elemento em volta: encadeado dentro de um rotulo
   ja reduzido, chega a 11px. O piso e absoluto para nao depender disso. */
small {
    font-size: max(14px, 0.8rem);
}
