Artigos sobre o tema são abundantes, mas desinformação sobre ele também é, e ela vem sido indiscriminadamente reproduzida. Meias verdades, equívocos e explicações rasas podem significar retrocessos pro desenvolvimento pessoal, mas também pra aplicações em produção.
Sumário
rem é mais acessível 🔗
TL;DR - pra tamanho de fontes é mesmo, já pra outras coisas...
rem ou root font-size é relativa ao tamanho de fonte base da folha de estilos do user-agent que geralmente é 16px porém depende do dispositivo:
| Dispositivo / Navegador | font-size padrão |
|---|---|
| Opera Mini 4.5 | 13px |
| Palm webOS 2.0 & webOS TouchPad | 14px |
| Opera Mini 7 | 17px |
| AOL 9 | 20px |
| Cybook Odyssey (leitor de e-book) | 21px |
| Blackberry 6.0 | 22px |
| NetFront NX | 23px |
| Kindle 3* | 26px |
Tabela transcrita e traduzida do artigo "People don't change the default 16px font size in their browser (You wish!)" do Nicolas Hoizey.
Vemos por ai diversas postagens que vão se resumir a dizer que rem é uma unidade responsiva - o que não só é mentira, como leva as pessoas a fazerem coisas assim:
@media (max-width: 42rem) {
/* resto do código */
}
Isso cria uma media query que reage à largura do site relativa ao tamanho da fonte do user-agent. Isso significa que quando a pessoa usuária mudar a configuração de fonte do navegador pra poder enxergar melhor os textos (e elas mudam)
O breakpoint que você esperava que fosse 672px (42 * 16), agora só é ativado quando a tela tiver 840px de largura. Algumas pessoas defendem que esse comportamento é o ideal, trazendo uma grande perca de previsibilidade na declaração dos breakpoints.
Na dúvida:
💡 A tradução foi escrita pelo André Menezes (deMenezes) nesse artigo que recomendo demais se você quiser ler outro take sobre esse mesmo tópico.
rem é melhor que em 🔗
TL;DR - em tem seus próprios casos de uso que rem não conseguiria substituir
Sempre desconfiem de afirmações como "x coisa é melhor que y", geralmente elas partem de um ponto de vista limitado ou pessoal e contribuem em nada pra com quem lê.
O em é relativo ao font-size do pai quando utilizado no font-size e relativo ao font-size dele mesmo quando utilizado em outros lugares como height e width. Se utilizado indiscriminadamente pode causar problemas indesejados com elementos aninhados:
<p style="font-size: 10px">
<!-- font-size === 15px -->
<span style="font-size: 1.5em">
Teste 1.5em
<!-- font-size === 30px -->
<span style="font-size: 2em">
Teste 1.5em
</span>
</span>
</p>
📖 Esse artigo (apesar de eu não concordar com a conclusão que ele chega) explica de uma forma bem simples porquê o
emexiste, que problemas ele resolvia e o que motivou a criação dorem- R.I.P. REM, Viva CSS Reference Pixel! por Gion Kunz, em inglês
Porém o modelo mental que mais favorece o uso do em é usá-lo quando você precisa que algo cresça junto com o tamanho da fonte. No caso de uso abaixo, quando você aumenta o font-size do botão, o padding aumenta proporcionalmente, permitindo que o botão permaneça com o mesmo aspecto independente do tamanho. O mesmo funciona com ícones, gaps e coisas similares.
px e outras unidades absolutas são ruins 🔗
TL;DR - skill issue
Ou "evite usar pixeis" - mas evite onde exatamente? Com pouco direcionamento do que fazer, acabamos por chutar unidades CSS sem testar ela em diferentes casos de uso, fazendo nosso layout quebrar de maneiras inimagináveis.
px são incríveis pra definir limites, pois na maioria das vezes não faz sentido o limite de algo ser relativo. Com breakpoints, max-width, min-height e outros similares.
Outro uso é definir o tamanho de coisas que não vão mudar com o contexto, como o caso de alguns border-radius ou box-shadow. Se não faz sentido aquela propriedade ser relativa a algo, não a faça relativa.
Se vai ter algo como regra, tenha não chutar. Cada coisa tem seu caso de uso, fazer de forma consciente significa também testar de forma consciente e garantir a qualidade da aplicação.
Acessibilidade é importante e nenhuma DX vale abrir mão dela. Se seu produto só pode ser usado por algumas pessoas, ou ele não está pronto, ou é só um produto ruim.
Referências 🔗
People don't change the default 16px font size in their browser (You wish!) por Nicolas Hoizey (em inglês)
Esse artigo busca sanar aquele pensamento de que não tem problema se declarar fontes com px pois a pessoa usuária média não redimensiona a fonte.
Responsive Type and Zoom por Adrian Roseli (em inglês)
Esse artigo explica como o uso de técnicas de tipografia responsiva pode ser ruim pra acessibilidade.
Addressing Accessibility Concerns With Using Fluid Type por Maxwell Barvian (em inglês)
Já esse artigo aborda a matemática por detrás da tipografia fluida e te ensina a acertar em uma que seja acessível.
PX, EM or REM Media Queries? por Zell Liew (em inglês)
Defende a opinião de que em e rem são boas unidades em media queries e que o "delay" que mexer no root font-size causa é uma feature e não um bug.
The Surprising Truth About Pixels and Accessibility por Josh Comeau (em inglês)
Esse artigo trás uma visão mais lúcida sobre as qualidades do pixel e quando e onde usá-lo.
JSBin de teste de REM
Possibilita visualizar como um container em px e outro em rem se comportam quando o usuário muda o font-size.
WCAG - Technique C14
Técnica suficiente em relação ao critério de sucesso 1.4.4 - Resize text.
R.I.P. REM, Viva CSS Reference Pixel! por Gion Kunz (em inglês)
Explica sobre reference pixel, a história do em e do rem e trás uma visão interessante (que eu não concordo) do uso do pixel.
Valores absolutos e relativos em CSS: quando usar px, % e rem por André Menezes
Uma visão super bacana do uso dessas três propriedades.
Top comments (9)
Grande contribuição esse artigo.
E até perdi um pouco do preconceito com
em, quero ver se encontro no dia a dia exemplos parecidos com esse do Padding do botão que tu mostrou.PS: deu um orgulhinho me ver ali nas referências 🥹 valeu mestre
Merece demais manoooo, vc escreve mt bem
Que delícia de artigo bem escrito e cheio de ref
Valeeeeeu!
Ótima explicação, nunca entendi muito bem essas diferenças
Como sempre entregando um artigo de ótima qualidade e que me ajuda a entender uma parte do desenvolvimento que sempre travei e nunca entendi muito bem, tenho a mania de usar tudo em PX, pois nunca me foi dito como usar e do pq usar outras, muito obrigado pelas referencias ajuda muito aprofundar o conhecimento.
Muito obrigado por compartilhar seu conhecimento 🦤.
Ô moço Camilo... "Perca" não existe... O artigo é ótimo, mas um erro crasso desses arrisca a PERDA de credibilidade do autor. Tirando isso, o artigo é muito bom pra quem tá encarando design de front-end!
Lkkkkk pode ficar tranquilo que desse risco eu não tenho medo não, obrigado mano
Incrível! Em um único post: explicou, exemplificou com código e anexou as referências. Conteúdo fino senhores.🍷🗿