/* ============================================================
   QivoN - correcoes de responsividade (gerado por
   catalogo-sync/gen_mobile_fix.py - NAO editar a mao)
   ============================================================ */

/* ------------------------------------------------------------
   1. O estouro horizontal da pronta-entrega: 418px a 375px.

   NAO se corrige com overflow-x:hidden. A causa e que item de grid
   e item de flex nascem com `min-width:auto`, que significa "nao
   encolha abaixo do seu conteudo". O `main` da pronta-entrega e
   item do grid `.enc-layout`, e dentro dele a barra de categorias
   tem 6 chips com `white-space:nowrap` somando 599px. O `main`
   entao assumia 773px dentro de uma tela de 375px e arrastava a
   pagina inteira para fora.

   `.cf-nav-scroll` ja nascia com `overflow-x:auto` - a rolagem
   lateral dos chips e o desenho pretendido. Era o `min-width:auto`
   que a impedia de funcionar.

   FORA de media query de proposito: medido, o mesmo estouro
   acontece a 700px (+95px) e a 1000px (+36px). Onde nao ha
   estouro, a regra nao muda nada - ela so permite encolher quem
   precisaria encolher.
   ------------------------------------------------------------ */
.enc-layout > * { min-width: 0; }
.cf-nav-scroll  { min-width: 0; }

/* ------------------------------------------------------------
   8. O MESMO defeito nas 2.362 paginas de produto: 20px a 320px
   (29/09/2026).

   Mesma causa da regra 1, outro lugar. `.ap-info` e item do grid da
   pagina de produto e nasce com `min-width:auto`. Dentro dele, a
   caixa de frete tem `<input id="apfCep">` + botao "Calcular" num
   flex de uma linha; o input ja traz `min-width:0`, mas isso deixa o
   INPUT encolher - nao deixa o `.ap-info` assumir largura menor que o
   min-content dos filhos. Ele assumia 316px com 24px de recuo, ou
   seja 340px numa tela de 320.

   Provado uma candidata por vez, com a pagina no navegador:

     #apfCep{width:0}            340 -> 320   resolve, mas trata o sintoma
     .apf-form{min-width:0}      340          nao resolve
     .ap-frete{min-width:0}      340          nao resolve
     .ap-info{min-width:0}       340 -> 320   resolve na causa

   Nao se corrige com `overflow-x:hidden`: o `body` das paginas de
   produto JA tem isso, e foi exatamente por isso que o defeito viveu
   ate aqui. O `hidden` esconde a barra e deixa o documento com 340px
   de largura - a pagina continua arrastando de lado no dedo.

   Fora de media query pelo mesmo motivo da regra 1: onde ha espaco,
   `min-width:0` nao muda nada. Medido a 360 e 375px: sem efeito.
   ------------------------------------------------------------ */
.ap-info { min-width: 0; }

/* ------------------------------------------------------------
   10. Duas barras `sticky` grudando no MESMO lugar, na
   pronta-entrega (29/09/2026). Vale em TODAS as larguras.

   A pagina tem quatro elementos `sticky`:

     .site-header    top:0px     z:500
     .cat-tabs-bar   top:60/66px z:450
     .sidebar        top:110px   z:auto
     .cf-nav         top:66px    z:40     <-- a barra de filtros

   `.cf-nav` gruda a 66px, que e exatamente onde `.cat-tabs-bar`
   tambem gruda. As duas ocupam a mesma faixa e a de cima tem
   z-index 450 contra 40: assim que a pagina rola, as abas passam
   por cima de 30px dos 35px do seletor de ordenacao.

   O efeito nao e visual, e funcional: medido com
   `elementFromPoint` no centro do controle, quem recebe o toque e
   `.cat-tab`. **Ordenar e filtrar ficam inclicaveis enquanto se
   rola** - e rolar e o unico jeito de ver a grade.

   Isto NAO e defeito de celular. Medido nas 13 larguras do Bloco
   F, de 320 a 2560: reprovava em **13 de 13**. Por isso a regra
   fica fora de qualquer media query.

   Os 114px sao medidos, nao arredondados: `.cat-tabs-bar` termina
   em 108px ate 768 e em 114px de 1024 para cima. 114 limpa as duas
   pontas (sobra 6px no celular, 0 no desktop). Com a regra: 13 de
   13 livres.

   `z-index` nao resolve. Subir o da `.cf-nav` poe a barra de
   filtros por cima das abas - troca quem fica inacessivel, nao
   conserta. As duas barras precisam se EMPILHAR, e empilhar e
   escolher o `top` da de baixo.

   **A CORRECAO NAO PODE MORAR AQUI, E ESSA E A LICAO.**

   Ela chegou a ser escrita nesta folha, o teste passou, o arquivo
   ficou no disco com a regra certa - e o site continuou reprovando
   nas 13 larguras. `js/catalogo-filtros.js` cria a barra e injeta
   um `<style id="cf-css">` no <head> em tempo de execucao: ele
   entra DEPOIS do `<link>` desta folha, e com a mesma
   especificidade quem chega por ultimo ganha.

   Regra que esta no arquivo e nao vale e pior que regra ausente:
   ela faz o proximo leitor acreditar que o assunto foi tratado.
   Por isso ela foi retirada daqui, e o `top` corrigido na origem -
   em `js/catalogo-filtros.js`, onde o valor e escrito.

   Sobra um caso a 320px, e ele e outro problema: ali o strip de
   chips fica com 73px visiveis para 633px de conteudo, porque o
   `min-width:0` da regra 1 (que tirou o estouro a 375px) tambem o
   deixa colapsar quando o "Ordenar" divide a linha. Os chips
   continuam alcancaveis arrastando. Fica registrado sem correcao:
   as tres candidatas de flex testadas nao mudaram um pixel, o que
   diz que a largura vem de outro lugar - e chutar regra em layout
   que nao se entendeu e como se cria o proximo band-aid.
   ------------------------------------------------------------ */

@media (max-width: 768px) {

  /* ----------------------------------------------------------
     2. A logo fora de centro: 23px a 375px, 49px a 320px.

     O header e `grid-template-columns:1fr auto 1fr`, que centra a
     logo quando as duas colunas 1fr ficam iguais. A da direita tem
     3 botoes de 44px (142px de min-content) e nao encolhe; a
     esquerda fica com a sobra. A 768px+ ha espaco para as duas
     serem iguais e a logo esta perfeitamente centrada - por isso o
     desktop nao tem o problema e nao e tocado aqui.

     Reduzir a logo de 54px para 44px devolve ~20px a cada lado. A
     imagem e 640x427; a altura menor mantem a proporcao exata
     (a largura acompanha), entao ela nao espreme nem estica.
     ---------------------------------------------------------- */
  .header-logo img { height: 44px; }

  /* ----------------------------------------------------------
     3. O "site da zoom sozinho".

     Nao e a meta viewport - ela esta correta nas 2.402 paginas
     (`width=device-width,initial-scale=1`) e sem `user-scalable=no`,
     que continua sendo o certo para acessibilidade.

     E o iOS: ao focar um campo com fonte menor que 16px, o Safari
     amplia a pagina - e depois da ampliacao ela desliza para os
     lados. Estavam abaixo de 16px: a busca do catalogo e da
     pronta-entrega (12px), o "ordenar" (12px), o login (14px) e a
     busca do site (14px).

     A primeira versao desta regra era so `input,select,textarea` e
     nao pegou quase nada: seletor de tipo vale (0,0,1) e perde para
     `.ct-f input` (0,1,1), `.enc-inp` e `.cf-sort` (0,1,0). Medir
     depois de aplicar foi o que mostrou isso - a regra existia e
     estava sendo ignorada em 5 dos 6 campos.

     Por isso cada alvo abaixo esta nomeado: empata em especificidade
     e ganha por vir depois. `select.cf-sort` leva o tipo junto de
     proposito - aquele bloco e injetado por JS no fim do <head>,
     depois desta folha, entao empate ali seria derrota.
     ---------------------------------------------------------- */
  input, select, textarea,
  .ct-f input, .sr-bar input, .search-top input,
  input.enc-inp, select.cf-sort, input.form-input, .form-input,
  input.cat-sort, select.cat-sort, #catSort, #cfSortM, #peSearch,
  #srInput, #clEmail, #clSenha { font-size: 16px; }

  /* ----------------------------------------------------------
     4. Alvos de toque abaixo de 44px (referencia da Apple HIG e
     do WCAG 2.5.5). Medidos: fechar do menu 35x35 (15x21 nas
     paginas de produto) e os links de categoria do menu 238x36.
     ---------------------------------------------------------- */
  .mob-close { width: 44px; height: 44px; display: flex;
               align-items: center; justify-content: center; padding: 0; }
  .mob-sub a, .mob-lk-main { min-height: 44px; display: flex; align-items: center; }

  /* ----------------------------------------------------------
     5. A lupa sai do cabecalho para a logo poder centrar.

     Com 3 botoes de 44px a coluna da direita tem 142px de
     min-content e nao encolhe; a esquerda fica com a sobra e a
     logo era empurrada 15px para fora do centro a 375px e 43px a
     320px. Com 2 botoes a coluna cai para ~93px e as duas laterais
     ficam iguais.

     `html.qv-busca-no-menu` nao e enfeite: a classe e posta pelo
     `js/busca-sugestoes.js` DEPOIS de inserir a busca no menu. Se
     aquele arquivo estiver velho no cache do visitante (o
     .htaccess guarda JS por um mes), a classe nao aparece, a lupa
     continua no cabecalho e ninguem fica sem busca. Esconder e
     oferecer sao o mesmo passo, e nao dois arquivos torcendo para
     expirar juntos.
     ---------------------------------------------------------- */
  html.qv-busca-no-menu .header-right button[aria-label="Pesquisar"] { display: none; }

  .mob-busca { width: 100%; background: none; border: none; padding: 0;
               font-family: inherit; font-size: 1rem; color: inherit;
               cursor: pointer; text-align: left; gap: .45rem; }

  /* ----------------------------------------------------------
     6. Alvos de toque da gaveta do carrinho, do rodape e dos
     modais - a segunda rodada da auditoria (22/09/2026).

     Medido a 375px, com produto real na gaveta e o modal aberto.
     NAO ha estouro horizontal em nenhum deles: gaveta, rodape,
     tabela de especificacoes e modal de guia cabem todos na tela.
     O que falha e o tamanho do que se toca:

       .q-btn (- e +)        22x22
       .ci-del (remover)     13x25
       .cart-x (fechar)      17x34
       .tg-x (fechar modal)  30x30
       .tg-guide-link        101x14
       .footer-soc a         30x30

     O minimo AA do WCAG 2.5.8 e 24x24; a diretriz da Apple e o
     WCAG 2.5.5 pedem 44x44. Quatro deles reprovam ate no minimo.

     A area cresce por `::after`, nao por padding: o desenho nao se
     move um pixel e o dedo ganha a area. Padding mudaria a altura
     das linhas do carrinho e do rodape, que e justamente o que o
     pedido proibiu mexer sem necessidade.

     Os valores nao sao uniformes porque os vizinhos nao sao. O vao
     entre `-` e `+` e 28px, entao 11px para cada lado nao os faz
     colidir (param em 131 e 137). Os icones sociais tem so 8px de
     vao: 7px para cada lado se sobreporia, por isso eles crescem
     4px na horizontal e 7px na vertical. O `.ci-del` esta a 169px
     do `+` mais proximo - nao ha risco de tocar um e acertar o
     outro, que seria grave por ele apagar o item.

     `.tg-x` fica FORA da regra de `position:relative`: ele ja e
     `position:absolute` no canto do modal, e sobrescrever isso o
     jogaria para o meio do conteudo. Ele ja e ancestral posicionado
     do proprio ::after, entao nao precisa.
     ---------------------------------------------------------- */
  .cart-x, .ci-del, .q-btn, .tg-guide-link,
  .footer-soc a { position: relative; }

  .cart-x::after, .ci-del::after, .q-btn::after, .tg-x::after,
  .tg-guide-link::after, .footer-soc a::after { content: ""; position: absolute; }

  .q-btn::after         { inset: -11px; }        /* 22x22  -> 44x44 */
  .ci-del::after        { inset: -10px -16px; }  /* 13x25  -> 45x45 */
  .cart-x::after        { inset: -5px -14px; }   /* 17x34  -> 45x44 */
  .tg-x::after          { inset: -7px; }         /* 30x30  -> 44x44 */
  .tg-guide-link::after { inset: -15px 0; }      /* 101x14 -> 101x44 */
  .footer-soc a::after  { inset: -7px -4px; }    /* 30x30  -> 38x44 */

  /* ----------------------------------------------------------
     Os 7 links do rodape sao `display:inline` com `line-height:28px`
     e `padding:0`: a caixa clicavel tem a altura da FONTE (14px),
     nao a da linha. Metade do passo de 28px e vao morto entre um
     link e o proximo.

     `inline-block` faz a caixa ocupar os 28px que a linha ja
     reservava - o alvo dobra e nada se move, porque o espaco ja
     estava la. Medido antes: nenhum dos 7 quebra em duas linhas,
     que e a unica coisa que `inline-block` mudaria.

     28px passa o minimo AA (24) e nao chega aos 44 da diretriz.
     Chegar exigiria espacar a lista, que e mudanca de desenho.
     ---------------------------------------------------------- */
  .footer-col a { display: inline-block; }

  /* ----------------------------------------------------------
     9. Mais seis alvos abaixo do minimo (29/09/2026).

     Achados pelo `medir_responsivo.js`, que mede a area util por
     HIT-TEST (`elementFromPoint`) em vez de ler o retangulo. A
     diferenca importa nos dois sentidos: os alvos ja expandidos aqui
     em cima somem da lista sozinhos - o `::after` deles e creditado -
     e estes seis continuam aparecendo depois de creditado tudo.

       .hero-new-dot    24x3  - os pontinhos do carrossel da home
       .breadcrumb a   27x18  - "Inicio", nas 15 paginas da raiz
       .ap-bc a        27x18  - o mesmo, nas 2.362 de produto
       .cat-grid-hdr a 82x18  - "Ver todos"
       .ct-card.tt a  105x14  - "Esqueci minha senha", na conta

     Mesma tecnica das regras acima: `::after`, nunca padding.
     "Esqueci minha senha" e o caso que mais dolorido: quem erra o
     toque nele fica sem entrar na conta.

     TODOS crescem SO na vertical (`inset: -Npx 0`). Na horizontal
     eles tem vizinho colado - o `>` do breadcrumb, o "Criar conta"
     ao lado - e alargar faria tocar um e acertar o outro.

     Os pontinhos do carrossel param em 24px de area util porque
     24px e a LARGURA deles, e alargar e decisao de desenho, nao de
     acessibilidade. 24 e exatamente o minimo do criterio 2.5.8.
     ---------------------------------------------------------- */
  .hero-new-dot, .breadcrumb a, .ap-bc a,
  .cat-grid-hdr a, .ct-card.tt a { position: relative; }

  .hero-new-dot::after, .breadcrumb a::after, .ap-bc a::after,
  .cat-grid-hdr a::after, .ct-card.tt a::after { content: ""; position: absolute; }

  .hero-new-dot::after   { inset: -13px 0; }   /*  24x3  -> 24x29 */
  .breadcrumb a::after   { inset: -13px 0; }   /*  27x18 -> 27x44 */
  .ap-bc a::after        { inset: -13px 0; }   /*  27x18 -> 27x44 */
  .cat-grid-hdr a::after { inset: -13px 0; }   /*  82x18 -> 82x44 */
  .ct-card.tt a::after   { inset: -15px 0; }   /* 105x14 -> 105x44 */
}

/* ------------------------------------------------------------
   7. O preco coberto pelo botao "Adicionar" no card (22/09/2026).

   O card foi desenhado para mouse:

     .pcard-act { position:absolute; bottom:0;
                  transform: translateY(100%);
                  background: linear-gradient(to top, #fff 60%, transparent) }
     .pcard:hover .pcard-act { transform: none }

   O botao mora escondido ABAIXO do card, clipado pelo
   `overflow:hidden`, e sobe por cima do conteudo quando o mouse
   entra. Com fundo branco: ele nao divide espaco com o preco, ele
   TAPA o preco. No desktop isso passa porque so dura enquanto o
   ponteiro esta ali.

   **A parte do hover ja estava resolvida, e nao e essa a falha.**
   As paginas da raiz ja trazem, no CSS embutido:

     @media(hover:none){ .pcard-act{ transform:none } }

   Ou seja: no celular o botao ja aparecia sempre - de proposito.
   O que ninguem fez foi **reservar o lugar dele**. Ele continua
   `position:absolute; bottom:0`, entao passa a ficar permanentemente
   por cima dos ultimos ~61px do card, e o preco mora justamente ali.

   Medido nos 12 cards da aba Mais Vendidos a 375px, com a regra de
   hover que ja esta no ar: **9 dos 12 com o preco coberto, ate 39px**.
   Nao e aleatorio - sao os cards com desconto, onde o bloco de preco
   tem tres linhas (preco antigo, preco atual, percentual) e por isso
   desce ate a faixa do botao. Com o `padding-bottom`: 0 de 12.

   Os 68px sao medidos, nao arredondados: o `.pcard-act` tem 60,5px
   (0,7rem de padding + 38px de botao) e sobram ~7px de folga.

   O DOM poe `.pcard-act` ANTES de `.pcard-body`, entao tirar o
   `position:absolute` jogaria o botao para o meio do card, entre a
   foto e o nome - medido, e por isso descartado. Ele continua
   absoluto; o espaco e que passa a existir.

   O `transform:none` abaixo DUPLICA o que as paginas da raiz ja
   fazem, e fica de proposito: os `produto-v*.css` nao tem essa regra,
   e assim a folha nao depende de o CSS embutido continuar trazendo-a.
   Hoje isso nao muda nada - nenhuma pagina de produto renderiza
   `.pcard` (conferido nas 2.362). E seguro e nao e inutil: e a folha
   ficar completa sozinha.

   `.pc2-quick` nao entra aqui, mas o MOTIVO escrito ate 29/09/2026
   estava errado, e errado do jeito perigoso: dizia que nenhum `.pc2`
   e renderizado, que era "folha morta". Medido no DOM, a **home tem
   12 cards `.pc2`**, com 12 `.pc2-quick` - e a home e onde o trafego
   de anuncio cai. A frase autorizava a nao conferir justamente a
   pagina mais visitada.

   Conferido de novo, agora no pixel: o `.pc2-quick` NAO tapa o preco.
   O retangulo dele cruza o do preco em ate 23px e o fundo e preto a
   82%, entao a conta de sobreposicao acusa - mas `elementFromPoint`
   no centro do preco devolve `.pc2-price`, e a captura de tela mostra
   o valor limpo. Sobreposicao de retangulo nao e cobertura; quem
   decide e a ordem de pintura.

   Fica sem regra porque nao ha defeito, e nao porque nao ha `.pc2`.

   (Nota: nao se escreve o glob de `data` com barra e asterisco aqui
   dentro - essa dupla ABRE outro comentario, e o conferir_css pegou
   exatamente isso na primeira tentativa desta secao.)
   ------------------------------------------------------------ */
@media (hover: none) {
  .pcard-act  { transform: none; }
  .pcard-body { padding-bottom: 68px; }
}

/* ------------------------------------------------------------
   11. Metade do menu "Joias" fora da tela, em notebook
   (29/09/2026, reportado pelo dono).

   `.hnav-dropdown` abre CENTRADO no item que o dispara
   (`left:50%` + `translateX(-50%)`), e isso funciona enquanto o
   painel e estreito: os outros tem 190px. A variante `.dd-grid`
   -- a de "Joias", com duas colunas e 23 categorias -- tem 360px,
   e "Joias" e o PRIMEIRO item da nav. Metade de 360 cai a esquerda
   de um item que esta a ~60px da borda, entao 120px saem da tela.

   Nao e caso de tela pequena. Medido no navegador, a coluna da
   esquerda inteira some a partir de 1536px, e 12 dos 23 links
   ficam inalcancaveis -- 1536, 1440 e 1366 sao larguras de
   notebook comum, provavelmente a maioria de quem visita em
   computador. So 1680px para cima escapava.

           1920px   left= 150   23/23 links
           1680px   left=  30   23/23
           1536px   left= -42   11/23
           1366px   left=-120   11/23   <- o notebook do dono

   A correcao e ancorar o painel na BORDA ESQUERDA do item em vez
   de no centro dele. Vale em qualquer largura e nao inventa
   breakpoint: dropdown alinhado ao gatilho e o comportamento
   normal de um menu que abre no primeiro item, e a folga toda
   esta a direita. Tem de repetir no estado de hover porque a
   animacao de entrada reescreve o `transform` inteiro.

   Sem `@media`: o defeito nao e de mobile. Abaixo de 992px quem
   manda e o menu hamburguer, que tem marcacao propria e nao passa
   por aqui.

   Confere com `catalogo-sync/medir_dropdown.js`, que mede o
   retangulo do painel e conta links dentro da janela.
   ------------------------------------------------------------ */
.hnav-item .hnav-dropdown.dd-grid       { left: 0; transform: translateX(0) translateY(-6px); }
.hnav-item:hover .hnav-dropdown.dd-grid { transform: translateX(0) translateY(0); }

/* ------------------------------------------------------------
   O MENU ABRE DO LADO DO BOTAO QUE O ABRE.
   Pedido do dono em 20/10/2026: "o menu ao clicar nos tres
   risquinhos em cima na ESQUERDA abre pelo LADO DIREITO".

   O hamburguer fica a esquerda do cabecalho e a gaveta nascia
   ancorada em `right:0` com `translateX(100%)`. Clicar num canto
   e ver o painel vir do canto oposto quebra a relacao entre o
   gesto e o resultado, e de quebra o painel cruza a tela inteira
   por cima do conteudo.

   O CARRINHO E A CONTA FICAM A DIREITA, e isso e a outra metade
   do pedido: os botoes deles estao naquele lado, e a gaveta do
   carrinho (`.cart-drawer`) nao e tocada aqui.

   SAO QUATRO PROPRIEDADES, nao uma. Trocar so o `transform`
   deixaria o painel ancorado a direita deslizando para fora da
   tela; e a borda e a sombra continuariam apontando para o lado
   errado -- detalhe que ninguem nomeia e todo mundo sente.

   Sem `@media`: a `.mob-nav` so existe no cabecalho mobile, que
   a propria pagina ja esconde acima de 992px.
   ------------------------------------------------------------ */
.mob-nav {
  right: auto;
  left: 0;
  transform: translateX(-100%);
  border-left: 0;
  border-right: 3px solid var(--teal);
  box-shadow: 5px 0 30px rgba(0, 0, 0, .16);
}
.mob-nav.open { transform: translateX(0); }