You can access this article in English here
Você pode acessar este artigo em inglês aqui
Eu adoro participar de comunidades de tecnologia. Além de aprender muito com pessoas com mais experiência do que eu, eu tenho a oportunidade de dividir um pouco do que aprendi com outros desenvolvedores. Além disso, ao tentar responder algumas dúvidas que surgem, eu me obrigo a pesquisar e acabo conhecendo profundamente algumas técnicas que eu sabia que funcionavam, mas não sabia por quê.
Recentemente no Discord da Alura eu esbarrei com uma dúvida de uma usuária que queria resolver um problema de layout em telas menores. As fontes dela estavam grandes demais, e o conteúdo quebrava. Um dos usuários do Discord orientou ela a mudar as medidas dos tamanhos de fonte para REM.
E não é a primeira vez que vi essa confusão.
Já trabalhei em um projeto em que um desenvolvedor experiente utilizava uma biblioteca que convertia todas as medidas originalmente em PX (pixel) para REM, acreditando que assim estava contribuindo com a responsividade do site.
Sabendo que tipografia é um assunto que recebe tão pouco carinho dos desenvolvedores (sim, eu tô falando com você que só declara font-size e font-family, e ignora completamente font-weight e line-height), resolvi escrever este artigo para falar de algumas boas práticas ao trabalhar com texto no desenvolvimento web.
1) Concentre as informações de tipografia em um único lugar
A primeira coisa que vejo com muita frequência é a repetição da declaração de tamanho de fonte.
No cabeçalho, a pessoa desenvolvedora declara:
.cabecalho{
font-size: 18px
}
Alguns momentos depois, essa pessoa vai precisar declarar:
.titulo{
font-size: 18px
}
Isso funciona, é claro. Mas e se houver uma mudança nos tamanhos de fonte usados no projeto? Vamos precisar fazer uma gincana para encontrar todas as ocorrências.
E mudar.
Uma.
A.
Uma.
Pouco prático, né?
Há um princípio na programação que podemos usar para pensar como resolver esse problema: o DRY (Don’t repeat yourself – Não se repita). Ele postula que, se estamos copiando um trecho de código ou informação, aquilo poderia ser isolado em uma função ou variável, que poderão ser chamadas ou referenciadas em outros pontos do código.
Poderíamos, então, declarar nosos tamanhos de fonte como Custom Properties do CSS (Propriedades Personalizadas, vulgo “variáveis do CSS”).
:root{
--fs-1: 12px;
--fs-2: 16px;
--fs-3: 20px;
}
.cabecalho{
font-size: var(--fs-2)
}
.hero-banner{
font-size: var(--fs-3)
}
main .titulo{
font-size: var(--fs-3)
}
.rodape{
font-size: var(--fs-2)
}
Assim, reduzimos a chance de erros, além de ter essas informações concentradas em um só lugar, aumentando em muito a manutenibilidade do nosso código.
2) Nunca mais use PX
É muito raro em programação a gente poder falar algo com essa força: nunca faça X, sempre faça Y. Com frequência temos múltiplas maneiras de atingir um objetivo, técnicas diferentes com vantagens e desvantagens, e temos sempre que analisar o caso para pensar qual a melhor forma de implementar. E essa é uma das belezas desse ramo. Gosto de pensar que em programação não existe uma forma certa de fazer algo, apenas formas não-erradas.
Mas nesse caso eu falo sem medo de errar: você não deveria usar PX para o tamanho das suas fontes.
Deixa eu contar uma história: Alberto não consegue ler com letras muito pequenas. Elas parecem se embaralhar diante dele, ficam borradas, o que desmotivava Alberto ao fazer pesquisas na web para a escola. Isso mudou quando Alberto descobriu que poderia alterar a fonte padrão do seu navegador! A fonte padrão dos navegadores é 16px, mas Alberto consegue alterar para 24px, o que torna sua vida muito melhor.
Acontece que a pessoa desenvolvedora que fez um dos sites que o Alberto quer acessar usou PX (pixels) em todas as fontes. E 18px sempre vão ser 18px, porque ele é uma medida absoluta, ou seja, não se adapta às preferências do usuário. Usar PX no tamanho da fonte tornou a experiência do Alberto menos satisfatória, talvez até impossibilitando ele de acessar aquele conteúdo.
É isso que acontece quando usamos PX no tamanho das fontes: nós estamos ignorando a preferência dos usuários e impondo o tamanho exato que nós escolhemos.
Felizmente temos como contornar esse problema usando a unidade de medida REM.
O REM se baseia no tamanho de fonte padrão do navegador. Como o padrão é de 16px, geralmente 1rem vai ser igual a 16px.
“Mas, Caio, eu preciso usar 18px no meu projeto, não 16px.”.
Moleza: na medida padrão, 18px é igual a 1.125rem. É só dividir o valor que você quer por 16.
Segue uma listinha de alguns valores comuns:
.25rem = 4px;
.5rem = 8px;
.75rem = 12px;
1.5rem = 24px;
Perceba que eu falei que esses são geralmente os valores de REM em PX. Isso porque essa conversão foi feita usando os valores padrão do navegador. No caso do nosso amigo Alberto, isso seria diferente: 1rem seria igual a 24px, e 1.125rem seria igual a 27px.
Assim, todo mundo sai ganhando: quem usa o tamanho padrão de fonte vai ter a mesma experiência, mas quem escolhe mudar, tem a sua escolha respeitada.
Vejamos como ficaria a nossa declaração lá no item 1:
:root{
--fs-1: 12px;
--fs-2: 16px;
--fs-3: 20px;
}
Viraria:
:root{
--fs-1: .75rem;
--fs-2: 1rem;
--fs-3: 1.25rem;
}
Fácil, né?
Mais uma coisa: muita gente, por achar difícil fazer a divisão por 16, faz o seguinte:
html{
font-size: 62,5%
}
Assim a fonte padrão passa a ser 10px, e fica muito mais fácil definir o valor em REM. Maravilha, né?
Só que não.
Fazer isso pode confundir outros desenvolvedores, é difícil de desfazer, e pode trazer conflito com bibliotecas possivelmente utilizadas no projeto.
Então, não mude a fonte base do navegador. Isso pode trazer algum conforto e facilidade para você agora, mas pode trazer consequências ruins para os seus usuários, e para colaboradores do projeto.
3) REM não resolve responsividade
Agora que você sabe o que é o REM e como usá-lo, seu site vai ficar todo responsivo e bonitão, né?
Você, pessoa leitora atenta, leu a introdução desse artigo e já sabe que não. Vamos entender isso direito.
Quando falamos de responsividade estamos geralmente falando de um site que se adapte aos diversos tamanhos de tela que existem: o site funciona sendo aberto em celulares, em tablets, em telas de laptop, e em monitores ultrawide.
Acontece que o REM não tem nada a ver com tamanho de tela. 1rem vai ser, por padrão, 16px em uma tela de celular ou em uma televisão.
Como ele não liga para o tamanho da sua tela, digamos que você crie um retângulo para telas de 1600px. E você define a largura desse retângulo assim: width: 100rem.
Você vai conseguir um retângulo de 1600px para os usuários que usarem a fonte padrão, mas se algum usuário mudar a fonte padrão para 20px, seu retângulo passa a ter 2000px, gerando transbordamento na tela que você tinha em mente.
Fiz um exemplo disso no CodePen. Como cada um dos leitores vai estar vendo isso em telas diferentes, eu reproduzi o cenário de uso de REM para ajustar conteúdo ao tamanho da tela estabelecendo a largura como 100%, daí diminuí 16px e aumentei 1rem.
Dessa forma, com o tamanho padrão vai dar tudo certo, mas quando o padrão do usuário for diferente, nosso layout quebra. Isso porque nesse tipo de contexto nós não queremos usar REM, nem PX. O ideal é trabalhar com porcentagem. Mas o mergulho em responsividade fica para outro artigo!
Ou acesse aqui.
Observação: Eu estou definindo a fonte no HTML em 16px para permitir que façamos o teste da mudança da fonte padrão de forma mais fácil. Esse trecho de código tem fins puramente didáticos.
No próximo exemplo, podemos ver que o texto dentro da caixa vai estar ora dentro, ora transbordando, conforme a gente brinca de diminuir e aumentar a tela, ou de mudar a fonte padrão pelo input.
O comportamento é errático.
A largura e altura da caixa são estabelecidas de forma que, quando o conteúdo varia, temos quebra do layout. A conclusão é: nosso H1 ter a fonte definida com REM não ajudou em nada a responsividade.
Ou acesse aqui.
Observação: eu estabeleci a altura dessa div usando height com fins didáticos. Estabelecer height em elementos com conteúdo é uma prática ruim para responsividade.
"Caio, meu mundo caiu! Como eu faço para deixar as fontes do meu projeto responsivas?"
A forma mais comum de tornar as suas fontes responsivas é com elas: as media queries.
Com isso você define que a partir de determinado tamanho de tela – digamos, 1200px - suas fontes que eram 12px, 16px e 20px vão ter um tamanho de 18px, 24px e 32px – sim, nesse blog difundimos a palavra do mobile-first.
Ficaria algo mais ou menos assim:
:root{
--fs-1: .75rem;
--fs-2: 1rem;
--fs-3: 1.25rem;
}
@media (min-width: 75em){
:root{
--fs-1: 1.125rem;
--fs-2: 1.5rem;
--fs-3: 2rem;
}
}
Não se assuste com a media query definida com EM. É uma boa prática declarar media queries com essa medida. Um dia posso falar disso por aqui.
O REM, como vimos no tópico anterior, vai ajudar a tornar nosso site acessível. Veja que eu disse “ajudar a tornar acessível”. O assunto acessibilidade é extenso e multifacetado, e precisamos tomar muitas medidas para garantir a acessibilidade no nosso site para o máximo de pessoas possível. Temos que atentar às cores, à navegação com teclado, leitores de tela e muito mais. No caso do REM, estamos lidando apenas com um aspecto: o tamanho das fontes.
Para ilustrar essa distinção entre responsividade e acessibilidade eu criei esse exemplo. Nele, temos 4 casos de texto:
1) não-responsivo e não-acessível (não muda de acordo com o tamanho da tela, e usa PX)
2) não-responsivo e acessível (não muda de acordo com o tamanho da tela, mas usa REM)
3) responsivo e não-acessível (muda de acordo com o tamanho da tela, mas usa PX)
4) responsivo e acessível (muda de acordo com o tamanho da tela, e usa REM)
Mexa na largura da tela e no tamanho da fonte para ver como o tamanho de fonte se comporta em cada caso
Ou acesse aqui
Com esses exemplos a gente consegue ver que, sim, já passou da hora de você substituir todas as suas fontes de PX para REM, mas não se engane: isso não vai tornar seu site responsivo.
4) Defina o tamanho das suas linhas
Quando você ia fazer trabalhos da escola ou faculdade que precisavam ter um número X de páginas, você tinha a tentação de mudar a altura da linha, para o conteúdo ocupar mais espaço.
“Coloca o espaçamento 2x, ninguém vai perceber”, diz a vozinha na sua cabeça.
A verdade é que a altura da linha faz toda a diferença na legibilidade de um texto (o termo correto aqui seria leiturabilidade. Fique aí com esse palavrão e pesquise a diferença).
É muito comum encontrar projetos em que o texto tem a família da fonte definida, o peso e o tamanho, mas a altura da linha não é declarada.
Quando fazemos isso, delegamos para o navegador a escolha da altura de linha, e cada navegador tem um padrão diferente. Não é uma boa, né?
Por isso devemos sempre declarar explicitamente nossa altura de linha. Mas como fazemos isso? Com a propriedade line-height!
A gente deve seguir os mesmos princípios que para tamanho de fonte: nada de PX!
Imagina que você tenha uma fonte de 1rem (nada de PX pra fonte, lembra?), e coloca a altura da linha com 20px. O que vai acontecer se a fonte padrão do usuário for 24px? Isso mesmo: a fonte das letras vai passar a ser de 24px, mas a altura da linha vai ficar travada em 20px, e o texto vai ficar todo embolado.
Ou acesse aqui
Uma saída seria definir a line-height em REM, assim ela poderia variar junto com o tamanho da fonte. Porém, fazendo dessa forma, sempre que a gente mudar o tamanho da fonte em uma media query a gente precisaria lembrar de mudar a line-height também, para manter sempre a mesma proporção.
Tem uma forma mais fácil de fazer isso: essa propriedade aceita porcentagem. Então a gente pode declarar a line-height como a gente fazia no Microsoft Word: 1, 1.2, 1.5, 2.
Nesse nosso exemplo, caso eu tenha uma fonte de 1rem e line-height de 1.25, os valores por padrão serão 16px para o tamanho da fonte e 20px para o tamanho da linha. Mas se a fonte padrão da pessoa usuária for 24px, os valores serão 24px e 30px respectivamente. Assim teremos sempre a mesma proporção entre fonte e altura de linha. Para melhorar: caso o tamanho da nossa fonte mude com media queries, não precisamos redeclarar a line-height!
Veja esse exemplo: aqui estamos usando REM para as fontes, mudando elas com media query e definindo line-height proporcionalmente ao tamanho da fonte.
Ou acesse aqui
Conclusão
Neste artigo aprendemos algumas boas práticas de tipografia, vimos como ter mais controle sobre as nossas fontes, como evitar a repetição de código, e como tornar nossos textos mais acessíveis e responsivos.
Com tudo que vimos aqui, você já sabe tudo que precisa sobre tipografia para fazer projetos para a web impecáveis. Mas a gente sempre pode ir além, né?
Você notou que eu falei que “A forma mais comum de tornar as suas fontes responsivas é com elas: as media queries.”?
E se eu te dissesse que você pode fazer o tamanho das suas fontes variar SEM USAR MEDIA QUERIES???
Pois fique de olho, que em breve sai um artigo falando sobre como implementar a técnica de tipografia fluida.
Top comments (10)
Muito massa o artigo! Uma dica pra quem quer facilidade na conversão de PX para REM é uma extensão do VS Code que eu uso e gosto bastante, a px-to-rem: é prática de usar e evita ter que usar "gambiarras" pra facilitar cálculos no desenvolvimento. Parabéns!
Bela dica, Angela! Eu nunca usei - até agora =)
Po, dá uma chance, é prático demais!
Que aula! Sério mesmo. Uma verdadeira aula de responsividade e fontes, com exemplos de tudo. Esse é o tipo de trabalho que poucos se preocupariam em tentar entender e seguem copiando e colando, porém o resultado nunca chega no esperado, e o pior, nunca sabem o motivo.
Parabéns! Já estou esperando o próximo artigo!
Robson, fico feliz demais de ler seu comentário! O próximo já está no forno. Obrigado pela sua leitura =)
Uma dica muito boa que eu usei em vários projetos para responsivar, é usar VW no tamanho da fonte, desse jeito a fonte aumenta e diminui o tamanho automaticamente de acordo com o tamanho da tela da pessoa. Essa é a maior sacada de todas. Claro que nesse caso não é levado em consideração a acessibilidade, mas a responsividade fica a melhor possível.
Eu também fiz isso quando descobri VW, Eduardo! Como te falei lá no LinkedIn, é bom a gente nunca fazer isso por causa da acessibilidade (além de isso derrubar métricas do site por causa dos parâmetros da WACG). No próximo artigo vou falar mais disso.
Sensacional!!!
Valeu, Kevin!
Parabéns! Conteúdo muito bom e simples de entender.
Ficarei no aguardo dos próximos artigos!