Módulo 3 · 1 de 7
Pixels não são todos iguais
Leitura: ~4 min
Você está lá, no seu MacBook, com o Figma aberto. O layout está perfeito. As margens estão alinhadas, a tipografia está consistente, os espaçamentos seguem a grade certinha. Você exporta, compartilha o link do protótipo com o cliente e espera o elogio.
Aí chega a mensagem: "O site tá quebrado."
Você abre no seu computador. Funciona. Abre no seu celular. Funciona. Pede print para o cliente. Ele manda: um Galaxy A14, com a fonte do sistema aumentada, dividindo a tela com o WhatsApp. E o seu layout, que era tão bonito, está com textos sobrepostos, botões cortados e a navegação sumiu.
Pois bem, isso não é um bug. É uma lacuna de conhecimento sobre como telas funcionam. E é exatamente isso que vamos resolver agora.
O pixel não é uma medida fixa
Pense comigo: você abre uma imagem de 1080 pixels de largura no seu monitor de 27 polegadas e ela parece normal. Abre a mesma imagem em um celular de 6 polegadas com a mesma resolução de 1080px e ela parece nítida, menor, mais densa. Por quê? Porque pixel não é uma medida fixa de tamanho. Pixel é um ponto de luz, e o tamanho físico dele depende da tela onde ele aparece.
E aqui entra um conceito que você precisa gravar: PPI (Pixels Per Inch, ou pixels por polegada). PPI é a densidade de pixels em uma tela. Quanto mais pixels você espreme em uma polegada, mais nítida a imagem fica, mas menor cada pixel individual se torna. Um monitor de desktop pode ter 96 PPI. Um iPhone pode chegar a cerca de 460 PPI. A mesma quantidade de pixels ocupa um espaço físico totalmente diferente.
E o que são DP, rem e em?
Se pixel muda de tamanho conforme a tela, o que acontece com o botão de 48 pixels do seu Figma no celular do usuário? A resposta curta é tranquilizadora: na web e no Figma, nada de ruim. O px do seu Figma é um pixel lógico, e o navegador compensa a densidade sozinho, então seu botão de 48px não vira uma lasquinha minúscula em tela densa nenhuma.
Aprofundamento opcionalPor que funciona assim?
No app nativo Android, px é o pixel físico do hardware, e por isso existem unidades como o dp, que compensam a densidade (o sistema multiplica o valor conforme os PPI da tela). Nesse mundo, sim, a regra é não usar pixels "crus". Já na web, o px é lógico e independente de densidade: a especificação do CSS define 1px como 1/96 de polegada, e o navegador converte para pixels físicos multiplicando pelo fator da tela (2x, 3x).
O problema real do px na web é outro: ele ignora o tamanho de fonte que o usuário configurou no navegador ou no sistema. É para respeitar essa preferência que existem rem e em. E foi exatamente isso, somado à tela dividida, que quebrou o layout no Galaxy A14 lá do início: fonte ampliada pelo usuário, não densidade de pixels. Vale conhecer as principais unidades de cada mundo:
- DP (Density-independent Pixels): é a unidade que o Android usa. 1 dp = 1 pixel em uma tela de 160 PPI. Em telas mais densas, o sistema multiplica automaticamente. Quando você projeta para Android, pense em dp, não em px.
- pt (Points): o equivalente da Apple. 1 pt = 1 pixel em uma tela de 163 PPI (o iPhone original). Retina displays usam 2x ou 3x esse valor por baixo dos panos.
- rem: unidade da web. 1 rem = o tamanho da fonte raiz do documento (geralmente 16px). Se você define um botão com
padding: 1rem, ele se adapta proporcionalmente quando o usuário muda o tamanho de fonte no navegador. - em: similar ao rem, mas relativo ao tamanho da fonte do próprio elemento, não à raiz. Se um botão está com fonte de 20px, 1em ali vale 20px; troque a fonte do botão e o em acompanha. Útil para componentes que precisam escalar internamente, mas mais difícil de controlar em hierarquias complexas.
Sim, são nomes estranhos. Mas cada um resolve um problema específico para o contexto onde é usado, e você não precisa decorar as fórmulas, só entender que existem e por quê.
Sei que esses conceitos podem soar um pouco técnicos e até intimidantes no início, mas garanto que, uma vez que você entende o que significam e como influenciam o design, eles se tornam parte natural do seu processo. O ponto central é: unidades relativas existem para que seu design respeite o contexto do usuário, não force o usuário a se adaptar ao seu layout.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
Um dev diz que seu botão de 48px vai virar uma lasquinha minúscula na tela densa do iPhone. Ele está certo?
Na web, não. O px do seu Figma é um pixel lógico, e o navegador compensa a densidade sozinho: em uma tela 2x ou 3x, ele desenha o botão com mais pixels físicos para manter o mesmo tamanho aparente. Essa preocupação com "pixel cru" faz sentido no Android nativo, onde px é o pixel físico do hardware, e por isso lá se usa dp.
Um usuário aumentou a fonte do sistema e reclama que seu layout quebrou. Por que trocar px por rem ajudaria?
Porque px ignora a preferência de fonte que o usuário configurou; rem existe justamente para respeitar essa escolha. Ao definir tamanhos e espaçamentos em rem, tudo escala junto quando a pessoa aumenta a fonte, em vez de o texto crescer sozinho e estourar um contêiner de tamanho fixo.