/* ============================================================================
   mobile-base.css — base mobile/Apple/Samsung comum a TODAS as páginas.
   Criado 2026-08-14 a partir dos achados do scripts/mobile-audit.mjs (WebKit +
   Chromium reais) e do gabarito já validado no sansara-site.

   Carregar DEPOIS dos CSS de página (styles-index / product-pages /
   service-pages): as regras de safe-area sobrescrevem `top`/`bottom` de mesma
   especificidade e precisam vencer na cascata.
   ========================================================================== */

/* ── Chrome do sistema em site dark ─────────────────────────────────────────
   Sem `color-scheme: dark` o Safari/Chrome renderiza <select>, date picker,
   barra de rolagem e o fundo do autofill em chrome CLARO, destoando da UI.
   Vale como CSS (não só meta) porque é o que o getComputedStyle enxerga. */
html {
  /* Flash cinza/azul ao tocar em link ou botão no iOS/Android. */
  -webkit-tap-highlight-color: transparent;

  /* Safari iOS infla a fonte em landscape sem isto. */
  -webkit-text-size-adjust: 100%;
  text-size-adjust: 100%;
}

/* ⚠️ NEM TODA página do site é escura. `admin.html`, `painel.html` e
   `market-pedido.html` têm body CLARO (`--light` #F4F6F9). Declarar
   `color-scheme: dark` nelas produz o defeito INVERSO — campo, scrollbar e
   autofill escuros sobre fundo claro. Por isso é opt-out: essas três páginas
   carregam `<html data-scheme="light">`. */
html:not([data-scheme="light"]) {
  color-scheme: dark;
}

/* ── Toque premium ──────────────────────────────────────────────────────────
   Remove o atraso histórico de ~300ms do double-tap-zoom. `manipulation`
   preserva pan/pinch de scroll — desliga só o double-tap sobre o elemento
   interativo. Samsung Internet 29 deriva do Blink 136, que ainda mantém o
   atraso. */
a,
button,
[role="button"],
summary,
label {
  touch-action: manipulation;
}

/* ── Anti-zoom forçado no iOS ───────────────────────────────────────────────
   Campo com font-size < 16px faz o Safari dar zoom ao focar — e ele NÃO
   desfaz o zoom ao sair do campo. Uma regra resolve o site inteiro sem
   precisar caçar cada declaração de formulário. */
@media (hover: none) and (pointer: coarse) {
  input,
  select,
  textarea {
    font-size: 16px;
  }
}

/* ── safe-area: o pagamento do viewport-fit=cover ───────────────────────────
   O site já declara `viewport-fit=cover`, ou seja, opta por desenhar por baixo
   do notch/Dynamic Island e do home indicator. Sem consumir os env() isso é
   PIOR que não ter cover: a navbar (top:16px) fica sob a Dynamic Island
   (~59px no iPhone 15 Pro) e o botão flutuante (bottom:28px) sob o home
   indicator (~34px). O .pchat-fab do index.html já fazia certo; aqui o padrão
   vira global. */
.navbar {
  top: calc(16px + env(safe-area-inset-top));
}

.whatsapp-float,
.pchat-fab {
  bottom: calc(28px + env(safe-area-inset-bottom));
  right: calc(28px + env(safe-area-inset-right));
}

/* Overlay de menu em `inset: 0` cobre a tela toda, inclusive as áreas
   inseguras. Só o inset puro — o overlay usa `justify-content: center`, então
   qualquer padding assimétrico desloca o menu inteiro fora do centro. */
.nav-links.open {
  padding-top: env(safe-area-inset-top);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
  padding-right: env(safe-area-inset-right);
}

/* ── Tap targets < 24px (WCAG 2.5.8 AA) ─────────────────────────────────────
   .manual-link renderiza 140×15px nas páginas de produto. Links em PROSA são
   isentos da regra, mas este é um link de download standalone numa lista —
   não é prosa. min-height + flex mantém o ícone alinhado. */
.manual-link {
  min-height: 24px;
  display: inline-flex;
  align-items: center;
}

/* ── Texto < 12px ───────────────────────────────────────────────────────────
   Badges e tags a 11px ficam ilegíveis no Galaxy Z Fold fechado (largura 344px)
   e abaixo do piso confortável de leitura mobile.
   O 11px do ticker do hero mora em `.hero-tag` (container) e é HERDADO pelo
   `.tag-label`; corrigir no container faz todo o conteúdo herdar 12px. */
.x-badge,
.hero-tag,
.tag-label,
.config-badge,
.ig-card .ig-video-badge {
  font-size: 12px;
}

/* ── Navbar com revenda logada: "Home" colava no logo ───────────────────────
   MEDIDO a 1440px logado (2026-08-14): logo 136 + links 822 + user 236 = 1194px
   de conteúdo contra 1136px úteis (navbar 1200 menos 64 de padding). Faltavam
   58px. Sem folga o `justify-content: space-between` não tem o que distribuir,
   os itens encostam (logo termina em x=289 e "Home" começa em x=289) e o bloco
   do usuário transborda ~26px à direita.

   ⚠️ O `margin: 0 auto` do .nav-links NÃO é o culpado — ele computa 0px
   justamente porque não há espaço livre. Mexer nas margens não resolve; o que
   resolve é reduzir a LARGURA do conteúdo abaixo dos 1136px.

   Tudo aqui é escopado a `:has(.nav-user-status.active)`: deslogado a navbar já
   tem 50px de folga e não deve mudar em nada. */

/* 1. Gap entre links 28→12px. São 9 intervalos, então libera 144px. */
.navbar:has(.nav-user-status.active) .nav-links {
  gap: 12px;
}

/* 2. Esconde o nome (~47px). É o item mais sacrificável do bloco: o avatar já
      traz as iniciais e o nome completo está no painel, a um clique. */
.navbar:has(.nav-user-status.active) .nav-user-name {
  display: none;
}

/* 3. Abaixo de 1280px o padding lateral cai de 32 para 20 (libera 24px). */
@media (max-width: 1280px) {
  .navbar:has(.nav-user-status.active) {
    padding: 0 20px;
  }
}

/* 4. Abaixo de 1150px NÃO CABE — são 10 links mais o bloco de usuário, e forçar
      só produziria o mesmo amontoado. Aqui o menu vira hamburguer, que já existe
      e funciona (verificado: abre em 1150/1100/1024/900/768/390). Sem o
      `:has()`, o hamburguer só entraria em 768px e a faixa 768-1150 ficava
      quebrada para quem está logado. */
@media (max-width: 1150px) {
  .navbar:has(.nav-user-status.active) .nav-links:not(.open) {
    display: none;
  }
  .navbar:has(.nav-user-status.active) .nav-hamburger {
    display: flex;
  }
  /* ⚠️ Ao antecipar o hamburguer para 1150px eu criei uma faixa 768-1150 em que
     o menu abria QUEBRADO — no iPad Pro logado saía uma tira de 969x58px. Pego
     pelo teste, não pela leitura do CSS.

     A causa NÃO é o overlay (ele já computava `position:fixed; inset:0`
     corretamente): é o CONTAINING BLOCK. A `.navbar` tem `transform`
     (translateX centralizador) + `backdrop-filter` (glass), e ambos fazem o
     `position: fixed` do filho se ancorar NA NAVBAR em vez de na viewport — daí
     a tira do tamanho da barra. Já documentado em variables.css:345 ("FIX menu
     mobile, audit 2026-08-06"), só que aquele bloco vive em
     `@media (max-width: 768px)` e não alcançava a faixa nova.

     Aqui a mesma neutralização, escopada a logado. Abaixo de 768px o bloco
     original continua valendo e o resultado é o mesmo. */
  .navbar:has(.nav-user-status.active):has(.nav-links.open) {
    transform: none !important;
    left: 0 !important;
    right: 0 !important;
    margin: 0 auto !important;
    -webkit-backdrop-filter: none !important;
    backdrop-filter: none !important;
  }
  .navbar:has(.nav-user-status.active) .nav-links.open {
    position: fixed !important;
    top: 0 !important;
    left: 0 !important;
    right: 0 !important;
    bottom: 0 !important;
    height: 100vh !important;
    height: 100dvh !important;
    width: auto !important;
    max-width: none !important;
    margin: 0 !important;
    background: rgba(10, 10, 15, 0.97) !important;
    -webkit-backdrop-filter: blur(20px);
    backdrop-filter: blur(20px);
    display: flex !important;
    flex-direction: column !important;
    align-items: center !important;
    justify-content: center !important;
    gap: 24px !important;
    overflow-y: auto !important;
    z-index: 1000 !important;
  }
  /* acima do overlay, senão não dá para fechar o menu */
  .navbar:has(.nav-user-status.active) .nav-hamburger {
    z-index: 1002 !important;
  }
}

/* `.hero-scroll span` (o "Explorar" do rodapé do hero) mora no <style> crítico
   inline do <head> a 10px. Como este arquivo é o último do <head>, a regra de
   mesma especificidade (0,1,1) vence na cascata. */
.hero-scroll span {
  font-size: 12px;
}

/* ── Hero: ícone da Xcene por cima do ticker configurável ───────────────────
   Reportado no Galaxy S24+. O `.hero-tag` (a faixa "AUTOMAÇÃO RESIDENCIAL
   INTELIGENTE") é `position: absolute` ancorado no `.hero-content`, e o
   `@media (max-width:768px)` do CSS de página redefine `.hero-content` para
   `padding: 0 20px` — o que ZERA o `padding-top: 140px` do desktop. Sem esse
   respiro o conteúdo sobe e o logo animado invade a faixa.
   Medido antes do fix: ticker terminava em y=165 e o logo começava em y=160
   (5px de sobreposição no S24+, 11px no iPhone 15 Pro).
   Vale para logado E deslogado — o defeito é anterior ao bloco de usuário. */
@media (max-width: 768px) {
  /* O `.hero` usa `align-items: center`. Em tela BAIXA (barra de URL + barra de
     navegação abertas, ~660-740px úteis no S24+) o conteúdo centralizado sobe e
     invade a faixa. Ancorar no topo torna a posição DETERMINÍSTICA em qualquer
     altura — que é o que faltava: o defeito só aparecia em viewport curto e por
     isso passou em todos os testes com tela cheia (832px). */
  .hero {
    align-items: flex-start;
  }
  .hero-content {
    padding-top: 132px;
  }
}

/* ── Navbar em telas estreitas com revenda logada ───────────────────────────
   No S24+ (384px) o bloco de usuário encostava no logo: logo 136 + user 162 +
   hambúrguer 38 = 336px contra 312px úteis. O avatar chegava a sobrepor o "e"
   final da palavra "xcene".

   "Sair" some abaixo de 480px, e é o sacrifício certo: o logout continua a um
   toque em Minha Página → painel (`painel.html:468`, `doLogout()`). Já "Minha
   Página" NÃO pode sair — o menu hambúrguer não tem link para o painel
   (verificado: só Home/Soluções/Produtos/Configurador/Loja/Sobre/Cadastro/
   Login/Contato/Buscar), então escondê-lo deixaria o usuário logado sem acesso.
   Resultado medido: folga 0 → 21px no S24+. */
@media (max-width: 480px) {
  .navbar:has(.nav-user-status.active) .nav-btn-sair {
    display: none;
  }
  .navbar:has(.nav-user-status.active) .nav-user-status {
    gap: 6px;
  }
  /* !important obrigatório: o <svg> do logo traz `style="height:32px"` INLINE no
     HTML, e estilo inline vence qualquer seletor. Sem isto a regra é ignorada em
     silêncio — foi o que aconteceu na primeira tentativa, que só "funcionou" no
     teste porque eu havia injetado com !important. */
  .navbar:has(.nav-user-status.active) .nav-logo svg {
    height: 22px !important;
  }
}

/* ── Botões flutuantes empilhados à direita — APENAS MOBILE ─────────────────
   No desktop o layout é um de cada lado (WhatsApp à esquerda, chat à direita) e
   FICA COMO ESTÁ. Em mobile os dois passam a ficar à direita, empilhados.

   O `index.html` traz duas regras inline que fixam o WhatsApp à esquerda
   (`left:28px` e depois `left:16px`), e definir só `right` NÃO desfaz isso —
   com `left` e `right` ambos definidos, o `left` vence. Daí o `left: auto`.

   Empilhamento: o chat (.pchat-fab) tem 60px de altura e fica em bottom 28px,
   então o WhatsApp vai para 28 + 60 + 12 = 100px, com 12px de respiro entre os
   dois. Ambos somam a safe-area para não cair sob a barra de gestos.

   ⚠️ !important é necessário: o `index.html` tem um <style> no CORPO da página
   (depois do </head>) com `@media(max-width:480px){.whatsapp-float{left:16px}}`.
   Como ele vem DEPOIS deste arquivo no documento, vence por ordem — não por
   especificidade. Verificado no browser: mobile-base é a folha [5] e a inline é
   a [8]. Sem !important a regra abaixo é ignorada em silêncio. */
@media (max-width: 768px) {
  .whatsapp-float {
    left: auto !important;
    right: calc(28px + env(safe-area-inset-right)) !important;
    bottom: calc(100px + env(safe-area-inset-bottom)) !important;
  }
}
