Guia prático para definir resolução e tamanho de tela em projetos
Quem trabalha com design ou desenvolvimento web já passou por isso: o cliente pede "uma tela responsiva" e na hora de colocar no navegador tudo vira um quebra-cabeça. O problema não é a teoria, é que existem várias camadas de medição e quase todo mundo confundeppi, px, rem,vw e vh desde o início.
O que realmente significa tamanho de telas no dia a dia
tamanho de telas não é apenas o número que aparece na caixa de especificações do fabricante. O que importa de verdade são as três coisas que interagem entre si: resolução física, densidade de pixels e tamanho CSS. Se você olhar só a resolução, vai errar a conta em praticamente qualquer projeto. Pegando um exemplo concreto. Um iPhone 14 Pro tem resolução de 1179 por 2556 píxeis físicos. A Apple aplica um fator de escala de 3, então o browser vê 393 por 852 píxeis CSS. A diferença entre esses dois números é a razão pela qual muitos designers entregam layouts perfeitos no Figma e depois veem tudo desproporcional na tela real. O fator de escala varia conforme o dispositivo. Em telas Retina costuma ser 2 ou 3. Em monitores ultrawide de computador, geralmente é 1. Em TVs conectadas via HDMI, o navegador pode aplicar uma conversão própria.
Existem também as chamadas unidades relativas que todo iniciante ignora. vw e vh são baseados no tamanho da viewport, não no conteúdo. Use vw para largura de seções em full-screen e vai ter problemas quando o usuário reduzir a janela. rem é baseado no font-size do elemento root e é mais estável para tipografia. rem costuma ser a escolha mais segura para larguras e espaçamentos porque segue a preferência do usuário. px fixos são problemáticos porque quebram a acessibilidade e não respondem bem a diferentes densidades de pixel. Uma coisa que pouca gente considera é a safe area. Nos celulares com entalhe ou câmera burburinho, o navegador aplica automaticamente padding nas bordas. Se você não usar a variável css env(safe-area-inset-top) no seu estilo, o conteúdo vai subir por trás do entalhe e ficar ilegível em cerca de um terço dos dispositivos modernos. Eu passei duas semanas tentando descobrir por que o cabeçalho de um painel administrativo cortava texto em certos iPhones sem entalhe. Descobri que era a safe area do iPad com a barra de navegação flutuante. A solução foi adicionar padding-bottom de calc(16px + env(safe-area-inset-bottom)) e testar no simulador do Xcode antes de liberar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O outro erro comum é confiar no aspect-ratio como solução definitiva. Definir aspect-ratio: 16/9 num container parece inteligente, mas em telas com barras pretas ou zoom do sistema operacional o conteúdo pode ser cortado. Eu vi um player de vídeo em um site institucional ficar com a imagem esticada em 40% das sessões porque o usuário tinha o Windows configurado com escala de 150% e o script de dimensionamento não considerava devicePixelRatio. A correção foi ler a propriedade window.devicePixelRatio e calcular a altura com base nela, em vez de depender só do aspect-ratio do CSS. Se o seu objetivo é trabalhar com múltiplos tamanhos de tela, o padrão que funciona na prática é definir breakpoints baseados no conteúdo, não nos dispositivos. breakpoints por dispositivo criam um catálogo infinito de casos. breakpoints por conteúdo mudam quando o layout não cabe mais no espaço disponível. Eu uso três pontos principais: um para telas pequenas onde a coluna única entra em colapso, um para tablets em que o menu lateral precisa se transformar em drawer, e um para desktops onde a terceira coluna passa a fazer sentido. Entre esses pontos, o fluido funciona melhor que saltos bruscos.
Para calcular tamanhos de forma fluida, use clamp com vmin. vmin escolhe o menor valor entre largura e altura da viewport, então protege contra rotação e janelas estreitas. Um exemplo realista seria clamp(320px, 85vw, 1440px) para a largura máxima de um container. Isso corta em pelo menos metade os problemas de layout horizontal sem precisar de dezenas de media queries. Há uma limitação importante que precisa ser dita claro. O tamanho de tela exato nunca será totalmente previsível em produção. Navegadores aplicam zoom, o sistema operacional altera escalas, alguns celulares reduzem a barra de endereço ao rolar e outros não. Testar só em simuladores dá uma falsa sensação de controle. O que realmente funciona é rodar testes em pelo menos um dispositivo físico por faixa de tamanho: algo abaixo de 390px de largura CSS, algo entre 768px e 834px, e algo acima de 1280px. O tempo que você gasta nesse teste é muito menor que o tempo que leva para corrigir bugs no ar, especialmente se o projeto já estiver em produção e com tráfego.
Para quem quer ir além, o recurso aspect-ratio combinado com container query resolve muitos problemas que media query não consegue. Container query observa o tamanho do pai, não da janela. Isso significa que um card pode mudar de layout dentro de uma sidebar sem precisar de regras globais. O suporte atual é bom em navegadores modernos, mas ainda pede fallback em IE e em versões antigas de Android WebView. Se o projeto depende de público corporativo com dispositivos vencidos, container query não deve ser a única estratégia. Para download e consulta rápida, o site do MDN tem a referência completa de propriedades CSS relacionadas a tamanho de tela, e o serviço de responsively.app permite simular múltiplos dispositivos ao mesmo tempo. Nada substitui a validação física, mas essas ferramentas aceleram a detecção de problemas em cerca de 60% dos casos, segundo relatos de quem usa no dia a dia.
