10 dicas para manter a Especificidade CSS baixa

Recentemente, em uma live que fizemos sobre Ferramentas de Especificidade CSS, foi perguntado: quanto menor a especificidade geral no CSS, melhor? Resumindo a resposta, foi dito que não há regras fixas para isso, mas manter a especificidade CSS baixa em todos os seletores é uma meta válida.

Em geral, baixa especificidade geral pode ser considerado como um sinal de que as coisas estão em relativa harmonia. Você não está lutando contra si mesmo e tem muito espaço para substituir estilos quando precisar.

Então, sendo uma meta válida a se ter em um projeto, como manter essa especificidade CSS baixa ao longo do tempo?

Atenha-se à classe que você precisa

Talvez você esteja escrevendo um seletor de alta especificidade (ou, mesmo, superqualificado) porque está substituindo um seletor já existente. Talvez o elemento que você esteja tentando selecionar está incluído em várias páginas, impondo que você o selecione a partir de uma classe de especificidade mais alta:

.section-header {
  /* estilos */
}

body.about-page .section-header {
  /* sobrescrita com especificidade mais alta */
}

A depender do projeto em que esse tipo de situação aconteça, essa solução pode (e deve) ser usada. Entretanto, ela pode não ser a melhor possível.

Caso você tenha o controle sobre as classes usadas nos elementos (ou possa solicitar a outro membro da equipe), uma solução que ajuda a manter a especificidade CSS baixa é usar um nome de classe novo:

.section-header {
  /* estilos */
}

.about-section-header {
  /* sobrescrita com a mesma especificidade */
  /* possivelmente, estendendo a classe-padrão */
}

Considere a ordem de escrita do código

Além de uma classe que estende outra, como mostrado no exemplo acima, outra possibilidade é aplicar um nome de classe adicional para lidar com uma substituição de estilos.

<header class="section-header section-header-about">
</header>

Neste caso, os estilos de .section-header-about podem estar, na verdade, sobrescrevendo o da outra classe. Isso pode acontecer devido à ordem da regra na folha de estilos. Ambos os seletores têm exatamente a mesma especificidade, portanto, pelos efeito da Cascata CSS, neste conflito de seletores, vence o que for declarado por último.

Caso seja um projeto em algum caso específico, para consertar isso deve-se apenas garantir que, onde quer que você escreva sua classe de substituição, ela venha depois na ordem do código.

Usar metodologias e arquiteturas CSS geralmente ajuda a resolver esse problema meio que automaticamente, pois boas convenções de projeto são pensadas para evitar esse tipo de problema corriqueiro.

Reduza a especificidade do que se está substituindo

Você sabe o que dizem sobre deixar as coisas melhores do que você as encontrou: você deveria fazer isso. :)

Se houver um ID em um elemento e for assim que ele está sendo estilizado (usado como seletor), você pode removê-lo? Se você considerou fazer isso, eu gosto da maneira que você pensa, mas, definitivamente, faça uma pesquisa em todo o projeto por esse ID antes de fazê-lo.

E não limite essa pesquisa a apenas o código CSS. Esse ID pode estar sendo usado como um hook para algum JavaScript, por exemplo. Nesse caso, você não deve removê-lo e adicionar uma classe ou usar uma classe já existente de CSS para fazer o que deve ser feito.

Lembrando que usar Namespaces CSS (neste caso, o de JavaScript) já elimina esse problema de IDs usados indevidamente como hooks JS automaticamente.

Não tenha medo de usar classes CSS

Imagine um seletor como:

.module > h2 {

}

Isso vai funcionar bem até o dia em que você quiser um estilo especial para esse h2 — fora outras desvantagens, algumas vistas em nossa live sobre OOCSS.

Você também poderia optar por algo como:

<div class="module">
  <h2 class="unique">
    Header Especial
  </h2>
</div>

Comparativamente:

.module > h2 {
  /* estilos */
}

.unique {
  /* vai perder no conflito de especificidade */
}

.module .unique {
  /* vai funcionar, mas com especificidade diferente */
}

É por isso que as boas metodologias CSS (como BEM) recomendam um planejamento de classes mais plano:

<div class="module">
  <h2 class="module-header"></h2>
  <div class="module-content"></div>
</div>

Use a Cascata

À medida que um projeto evolui, torna-se cada vez mais perigoso alterar seletores de baixa especificidade, já que eles podem afetar mais coisas e desencadear consequências indesejadas.