Adaptar o layout ao celular e ao contêiner

A unidade 100vh esconde o botão de confirmar atrás da barra de endereço do celular assim que a página abre. O cliente desiste sem tocar em nada. A tela do celular muda de tamanho durante o uso e o dedo cobre uma área maior que o ponto tocado. O teclado errado custa toques a mais.

A medida de altura certa, o espaço devolvido nos cantos do aparelho, o tamanho de alvo por norma e o teclado certo resolvem esses quatro pontos. E entram nessa ordem.

O defeito mais comum é a unidade 100vh (cem por cento da altura visível), que conta a tela sem a barra de endereço. No celular a barra costuma estar visível na abertura, o bloco nasce mais alto do que a área real e o botão cai fora da tela. A página ainda pula quando a barra some ao rolar.

Três unidades resolvem; a diferença é qual estado da barra cada uma conta. A pequena (svh) conta com a barra visível e garante que nada seja cortado na abertura. A dinâmica (dvh) acompanha o movimento da barra em tempo real.

No bloco de tela cheia, use a dinâmica. No botão que precisa aparecer assim que a página abre, como o de continuar do checkout, use a pequena: ela é o pior caso.

O segundo defeito é o recorte da tela: a câmera em cima e a barra de gestos embaixo. O navegador só desenha por baixo deles se você pedir, e quando pede precisa devolver o espaço. São dois passos, e pular o primeiro faz o segundo devolver zero.

No primeiro passo, uma única linha da configuração de tela do site autoriza o desenho sob os recortes. O segundo usa o recuo que o aparelho informa no espaçamento de todo elemento colado nas bordas, sempre somado a um mínimo seu. Em aparelho sem recorte o recuo vale zero, e sem o mínimo o botão encosta na borda.

Quem pulou esse cuidado vê o botão de confirmar meio escondido atrás da barra de gestos. O toque abre o menu do sistema em vez de confirmar o pedido. O defeito nunca aparece no seu aparelho, porque o tamanho do recorte muda de modelo para modelo.

O dedo cobre uma área bem maior que o ponto tocado, e três normas dizem o tamanho do alvo. O piso é 24 por 24 pixels CSS, critério 2.5.8 do WCAG 2.2 no nível AA. O AAA, critério 2.5.5, e a Apple pedem 44 px; o Android pede 48 dp.

A parte que quase todo mundo esquece é o espaçamento. Três alvos de 24 px colados passam no piso e continuam errados, porque o dedo cobre os três; com 8 px entre vizinhos, o mesmo trio funciona. Quando o ícone precisa ser pequeno, aumente a área tocável com espaçamento interno, sem aumentar o desenho.

O formulário é onde o celular cobra mais caro por descuido, porque cada campo errado custa toques a mais. Duas escolhas decidem quase tudo: o modo de entrada (inputmode), que escolhe qual teclado sobe, e o preenchimento automático (autocomplete), que deixa o navegador completar o campo sozinho.

A armadilha mais comum é o campo do tipo número para CPF, CEP e cartão. Esse tipo traz setas de incremento e perde o zero à esquerda do CEP, e nenhum dos três é um número que você vá somar. Use campo de texto com modo de entrada numérico, e o teclado certo sobe sem efeito colateral.

O preenchimento automático de código recebido por mensagem resolve o pior momento do formulário: o teclado oferece o código do SMS acima das teclas, sem sair do site.

Quatro regras do manual de setembro de 2026 fecham a tela de celular. A densidade (o espaço entre linhas e botões) muda por breakpoint, o ponto de largura em que o layout troca de arranjo. Apertada no computador, folgada no celular; um valor fixo único erra num dos dois.

O tema escuro sai de tokens (valores de cor guardados com nome, como etiquetas na lata de tinta) que trocam de papel entre os dois temas. Cor fixa em cada elemento é o que quebra no escuro. O peso da fonte sobe um degrau sobre fundo escuro, porque o traço fino some.

Toda janela modal tem fechamento visível e tocável, com alvo de 44 px, porque o gesto de tocar fora ninguém descobre sozinho.

O campo que cresce com o conteúdo sai do field-sizing, em Baseline Newly Available desde 16 de junho de 2026, quando o Firefox 152 fechou o conjunto. Sem suporte, a caixa fica na altura fixa e rola por dentro.

Abra a tela mais importante do site no celular e role até o fim. Observe se a página pula quando a barra do navegador some e se algum botão fica fora da área visível na abertura. Testar só no computador, no modo de simulação, esconde esse defeito.

Meça os três menores botões e o espaço entre eles na ferramenta de inspeção. Leve cada alvo a 44 px com espaçamento interno, sem redesenhar o ícone. Num botão de confirmar horário preso ao rodapé, é a altura dinâmica que impede a queda fora da área visível.

Troque CPF, CEP e cartão do tipo número para texto com modo de entrada numérico e confira se o zero à esquerda do CEP sobrevive. Peça densidade folgada no celular, tema escuro por tokens e um botão de fechar visível em toda janela.

O cartão que se reorganiza pelo espaço e a grade em alvenaria

Um componente (o pedaço de tela que se repete, como o cartão de produto) decide sozinho o layout pelo espaço que recebe, sem JavaScript. Ele deixa de existir em duas versões separadas, uma para a lista e outra para a página.

Sete recursos nativos resolvem esse cartão único: o que cada um faz, onde já roda no navegador e o desenho de reserva para quando ainda não roda.

Container query (a pergunta sobre o espaço que o componente recebeu, e não sobre a tela) muda quem responde: o contêiner pergunta, o filho decide o arranjo. As consultas de tamanho são Baseline Widely Available desde 14 de agosto de 2025.

Um cartão empilha imagem e texto abaixo de 340 px de contêiner e põe os dois lado a lado acima disso, com a mesma marcação em qualquer página. Num cartão de imóvel, isso apaga a segunda versão do componente, hoje mantida só para a lista de resultados.

A armadilha é declarar a consulta no próprio cartão: o elemento que pergunta pelo espaço precisa ser o pai, nunca ele mesmo.

A style query pergunta pelo valor de uma variável em vez da largura. Você guarda a densidade num token (o valor salvo com nome, como etiqueta na lata de tinta) e o cartão aperta ou afrouxa sozinho.

As consultas de estilo entraram em Baseline Newly Available em 19 de maio de 2026, quando o Firefox 151 fechou o conjunto. Sem suporte, o cartão fica na densidade confortável.

Subgrid (a grade filha que herda as linhas e colunas da grade mãe) alinha título, preço e botão de cards vizinhos na mesma linha. Isso vale mesmo quando um título ocupa duas linhas e o outro, uma. Ele é Baseline Widely Available desde 15 de março de 2026.

O plano B antigo era altura mínima fixa, que sobra espaço num card e corta texto no outro.

Grade em alvenaria é a galeria de alturas diferentes que se encaixa sem buraco, como a estante de caixas de tamanhos variados. Até 2026 ela exigia biblioteca (o pacote de código pronto) medindo cada bloco.

A sintaxe final ficou grid-lanes, dentro do próprio Grid. O Safari 26 foi o primeiro a embarcar; Chrome e Firefox mantêm o recurso atrás de opção experimental.

Sem suporte, a grade comum deixa vãos entre as linhas e todos os blocos continuam visíveis.

Altura que anima de auto era o outro caso de biblioteca. Com interpolate-size e calc-size(), o navegador interpola até palavras como auto, e o detalhamento de um pedido abre com transição de duas linhas. Chrome e Edge 129 trouxeram o recurso, foco do Interop 2026. Use em bloco pequeno; anime a página inteira e o celular engasga.

A terceira troca é a ordem de leitura. Com reading-flow e reading-order, no Chrome 137, o Tab segue a ordem visual do Grid, e o leitor de tela também, sem reescrever a marcação. A armadilha é reordenar só com CSS, sem reading-flow: quem navega por teclado pula de um canto ao outro da tela sem entender por quê.

Dois ajustes de tipografia fecham o cartão. O text-box-trim remove o espaço fantasma que a métrica da fonte deixa acima e abaixo da letra, e o título alinha com o ícone sem margem negativa. Roda em Chrome e Edge 133 e no Safari 18.2; o Firefox ainda não tem.

O text-wrap: pretty evita a palavra órfã na última linha do parágrafo. Chrome e Safari o implementam, o Firefox não, e por isso ele segue em Limited Availability, como melhoria progressiva; sem suporte, o texto quebra na linha padrão.

Como bússola de prioridade, o Interop 2026 (o acordo anual dos fabricantes de navegador) lista 19 áreas de foco, 11 delas de CSS. É por ela que se ordena o progressive enhancement (a melhoria progressiva: base que funciona em todo lugar, enfeite onde o navegador aceita).

O critério para adotar cabe numa frase: use o recurso nativo atrás de uma consulta de suporte quando o desenho de reserva cumpre a função. Segure a biblioteca só quando esse desenho quebra a função.

Escolha o componente que mais se repete no site e peça os sete recursos numa conversa só com o agente. Diga que o cartão da lista e o da página interna são o mesmo, e que o arranjo reage ao espaço do contêiner.

Peça que título, preço e botão caiam na mesma linha em todos os cards da fileira por subgrid. Altura mínima fixa no lugar dele sobra espaço num card e corta texto no outro.

Antes de aceitar a entrega, abra a página no celular mais antigo disponível. Sem a consulta de suporte, o navegador que desconhece a regra descarta a linha e a galeria quebra.