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:
|
1 2 3 4 5 6 7 |
.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:
|
1 2 3 4 5 6 7 8 |
.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.
|
1 2 |
<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:
|
1 2 3 |
.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:
|
1 2 3 4 5 |
<div class="module"> <h2 class="unique"> Header Especial </h2> </div> |
Comparativamente:
|
1 2 3 4 5 6 7 8 9 10 11 |
.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:
|
1 2 3 4 |
<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.
|
1 2 3 |
#im #just .gonna[do] .this .to .be #safe { /* (ಥ_ʖಥ) */ } |
Mas afetar mais coisas faz parte dos poderes de CSS. Ter uma base sólida a partir da qual você está construindo significa que menos substituições serão necessárias.
Veja, a seguir, algumas estratégias para lidar com isso.
Usar uma biblioteca de padrões e/ou style guide e/ou Atomic Design
Uma biblioteca de padrões (ou pattern library ou algo assim) pode significar que você tem o que está procurando quando precisa. Precisa de algumas abas? Aqui está, esta é a forma estabelecida para fazer isso. E é (provavelmente) construído de tal forma que a especificidade já é baixa, então, substituí-lo não será excessivamente difícil.
O Atomic Design — que explicamos rapidamente em nossa live sobre como identificar componentes — pode orientar como seu site (ou a biblioteca de padrões) é construído, então, mesmo que você não tenha um padrão completo para o que precisa, você tem os “blocos de construção”, por assim dizer.
Um Guia de Estilo (ou Style Guide) pode ajudar bastante, pois pode impor regras específicas sobre especificidade na tentativa de salvá-lo de si mesmo.
Lidar com problemas fora do seu controle
Talvez algum código de terceiros (third-party code) espere ou injete certo HTML nas páginas do seu projeto. Você tem que saber lidar com isso. Você ainda pode tentar usar os seletores de baixa especificidade que puder ou:
- Deixar comentários no código indicando porque os seletores são assim;
- Usar seletores de baixa especificidade com
!important(em último caso); - Perguntar às pessoas responsáveis pelo código não-ideal se elas podem corrigi-lo.
Aumentar um pouco a especificidade
Se uma batalha de especificidade é inevitável, ao invés de pegar uma marreta como um ID ou usar !important, tentar algo mais ameno.
Por exemplo, um qualificador de elemento é a atualização de especificidade mínima possível.
|
1 2 3 4 5 6 |
ul.override { /* Vencedor */ } .normal { } |
Mas limitar um seletor a uma tag específica é um fator limitante estranho. De repente, pode ser preferível apenas adicionar uma classe adicional — se outro nome não fizer sentido, você pode até usar a mesma classe, se necessário.
|
1 2 3 4 5 6 7 8 9 10 |
.nav.override { } .override.override { } .nav { } |
“The single-class wrapper”
Uma maneira bastante poderosa de lidar com uma sobrescrita é usar um elemento de envolvimento (wrapper) existente sobre a área à qual você precisa aplicar as sobreposições de estilo ou adicionar um novo.
|
1 2 3 |
<div class="override"> ... coisas existentes ... </div> |
Agora, você tem a capacidade de substituir qualquer estilo existente, adicionando apenas uma única classe ao seletor.
|
1 2 |
.override .existing { } |
Se você pensou no Namespace de Escopo mostrado em nossa live, você pensou muitíssimo bem.
Conclusão
Para a imensa maioria dos projetos, ter problemas de especificidade CSS é comum — por isso aconselhamos a leitura do nosso livro que explica o conceito em detalhes.
Como foi visto, existem muitas maneiras de se lidar e de resolver esse tipo de problema. Uma dica extra é fazer uma análise de especificidade do seu código atual através de alguma das ferramentas que mostramos em nossa live para ter uma visão geral da gravidade do problema.
Talvez, conhecer bem o conceito de Especificidade CSS e suas implicações práticas seja a melhor maneira de lidar com a coisa, já que muitos potenciais problemas são resolvidos preventivamente.
E você, tem alguma outra técnica para resolver problema de especificidade CSS que gostaria de compartilhar? Comente!