5 minutos de leitura
Autor(a)
Yuri é desenvolvedor full-stack, formado em Tecnologia de Informação pela USP. Como instrutor de cursos presenciais (Front-end, Java e PHP, Spring e MySQL) sumarizou mais de 1 000 horas de aulas ministradas.
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Olá, se vocês não viram o primeiro post da série clica aqui e dá uma lida nesse antes.
Bom, agora vamos resolver o problema dos nomes das classes de CSS, vamos recapitular o componente .box que eu criei:
-- Box
.box {}
.image {}
.title {}
Imagina agora que o nosso componente navbar tem seu próprio elemento título também, qual nome daríamos pra classe desse título?
-- Navbar
.navbar {}
.title {}
O problema de usar nomes tão genéricos é que nomes de classe assim vão conflitar uns com os outros, veja que tanto o componente box quanto navbar tem um .title declarado. Como podemos fazer pra resolver isso?
Gente pensa comigo, o titulo da navbar pertence a qual componente? A própria navbar!
O título do box pertence a qual componente? O próprio box!
-- Box
.box {}
.box .title {}
.box .image {}
-- Navbar
.navbar {}
.navbar .title {}
.navbar .item {}
Agora sim! Os estilos vão ser específicos pros seus elementos!
Apesar da gente ter melhorado o código agora, esse código novo ainda vai entristecer muita gente, principalmente quem for dar manutenção no futuro.
Olha, vamos pensar o seguinte, lembra do nosso item ativo da navbar? Então, vamos pensar que o CSS do nosso modificador ativo tem de ser escrito por uma outra pessoa nova no projeto e que nós não fazemos mais parte desse projeto. A pessoa provavelmente vai escrever algo do tipo:
.active {}
Quando ela inserir esse modificador no elemento da navbar o que vai acontecer?
<navbar …>
<a .. class="item active">
...'
Não acontece NADA.
EITA, como assim nada?
Pois é, no CSS existe uma coisa chamada especificidade, quanto mais específico for o CSS mais prioridade ele vai ter pra estilizar o elemento. Veja só isso:
<navbar class="navbar">
<a href="#" class="item">Home</a>
<a href="#" class="item active">Courses</a>
<a href="#" class="item">Carreiras</a>
</navbar>
Quais são os seletores CSS que temos que estão estilizando o nosso link courses?
.navbar .item {}
.active {}
Qual desses seletores você acha que é mais específico e vai ter mais prioridade?
.navbar .item {}
Pois é, um seletor com duas classes é mais específico do que um seletor com apenas uma!
O que vai acontecer é que a pessoa que criou o estilo do .active vai ter que deixar esse seletor igualmente ou até mais espeficífico que o seletor acima. Resultando em:
.navbar .active {}
E se depois disso outra pessoa quiser estilizar? Vai ter que ir ficando cada vez mais específico até chegar no.
.. 1 minuto de silêncio ..
!important
Isso é horrivel porque o !important é um curinga para burlar a especificidade, ou seja, se alguém quiser estilizar ainda mais o elemento vai ter problemas!
Se um dia você mexer com temas prontos do Wordpress e tentar customizar eles você vai sentir na pele todos esses problemas, confia em mim!
Bom, ok, mas como resolver esse problema ? Simples, deixando menos específicas as classes! Vamos tentar deixar apenas o NOME do seletor mais específico:
.navbar {}
.navbar-title {}
.navbar-active {}
Repare que agora temos uma classe só com nome composto! Agora .navbar-active sobrescreve .navbar-title!
Existe já um padrão pra isso e é o famoso Block Element Modifier, BEM.
Explicando as siglas do BEM temos:
(B)lock - Esse seria basicamente o que o SMACSS chama de Módulo e o que chamamos aqui de componente também, isso seria qualquer componente que criamos que possa ser reutilizado em várias páginas, como o caso do nosso box ou da navbar.
De agora em diante quando eu me referir a block ou bloco vou estar falando de algum componente.
(E)lement - Esse seria um elemento que está dentro do nosso bloco, por exemplo tanto os nossos itens dentro da nossa navbar, quanto o title e a image dentro do box, lembra?
-- navbar block
<navbar class="navbar">
<a href="#" class="navbar-item">Home</a>
<a href="#" class="navbar-item">Courses</a>
<a href="#" class="navbar-item">Carreiras</a>
</navbar>
.navbar {}
.navbar-item {}
-- box block
<a class="box" href="#">
<img loading="lazy" class="box-image" src="#">
<h3 class="box-title">Curso de HTML CSS >
</a>
.box {}
.box-image {}
.box-title {}
(M)odifier - Esse seria o nosso modificador, lembra do active? navbar-itemActive.
O que o BEM propõe é organizar esses nomes, que nomes vamos dar para os elementos? E os modifiers? E os blocks? Ele ajuda a gente a seguir um padrão. Para o BEM esse padrão seria:
block__element--modifier
Ou seja, refatorando nosso código a gente teria:
Para o block box:
.box {}
.box__title {}
.box__image {}
Veja que no exemplo do box não temos modifier, apenas o block box e os elements title e image!
Vamos para o nosso block navbar agora:
.navbar {}
.navbar__item {}
.navbar__item--active {}
Lembra que active é o nosso modifier? Voilà!
BEMerizamos o nosso CSS! É assim que a gente faz na Alura hoje em dia, usando tanto as técnicas descritas nesse post como as técnicas descritas no post anterior de organização de arquivos do front!
Pessoal nesses dois posts falamos apenas de HTML e CSS, pro javascript já são outros quinhentos, quem sabe eu não escrevo um post falando um pouco do JS também no futuro!
Só vou complementar com algumas últimas informações:
O BEM não é restritivo, ou seja, se você separar os seus blocks dos elements e dos modifiers você já está seguindo um padrão BEM! Olha só, na Alura antes a gente seguia o padrão:
Block-element--modifier
Esse padrão funcionou durante um tempo mas conforme o código cresceu a gente começou a achar ele confuso, o element do modifier a diferença é 1 hífen só.
Isso começou a dar problema. Se vocês derem inspect em algumas páginas da Alura hoje ainda vão achar código assim!
Obrigado por lerem e forte abraço!
Avalie este artigo
