Ao longo dos anos, os desenvolvedores criaram várias maneiras criativas (e não tão criativas) de evitar o inferno da especificidade. Neste breve artigo, compartilharei com você um truque que permitirá evitar conflitos de especificidade nos casos em que lidar com eles da maneira usual resultaria em seletores desnecessariamente complicados.

inferno de especificidade

Tudo bem, acalme-se agora. Não existe “inferno” no desenvolvimento front-end. Só falta experiência e/ou conhecimento. Ambos facilmente corrigidos ganhando o que está faltando. Eu prometo a você isso. “Inferno da especificidade” é apenas uma frase que usei para chamar sua atenção. Na vida real, os conflitos de especificidade não são tão comuns, especialmente se você aprender como a especificidade funciona .

É principalmente apenas um caso estranho aqui e ali, onde você se vê incapaz de substituir algum estilo por causa de um seletor de alta especificidade que você usou em outro lugar. Se você me der licença para puxar um número atrás de mim, isso acontece cerca de 1 em 76 vezes. Ou era 67... Enfim, é raro, essa é a questão.

Aqui está um exemplo que criei para este artigo. É deliberadamente simples demonstrar o conceito e pode não ser muito óbvio por que você precisaria de uma solução diferente até que você realmente aprenda que precisa na vida real, então, por favor, tenha paciência comigo.

Primeiro o HTML:

<ul id="articles">
  <li class="active">
    <h2>Specificity hell</h2>
    <p>Published on: Feb 12, 2005</p>
    <a href="/specificity-hell.html">Read the article</a>
  </li>
  <li class="archived">
    <h2>How important is !important?</h2>
    <p>Published on: Feb 10, 2005</p>
    <a href="/how-important-important.html">Read the article</a>
  </li>
  <li>
    <h2>Stop nesting selectors in 2005!</h2>
    <p>Published on: Jan 12, 2005</p>
    <a href="/stop-nesting-selectors-2005.html">Read the article</a>
  </li>
</ul>

#articles li {
  background: #ffe;
}

.active {
  background: #faf;
}

.archived {
  background: #aff;
}

Agora, não vou entrar em todo o “porquê” é mais específico etc. Esse não é o ponto. Em vez disso, mostrarei como evitar esse tipo de conflito sem ajustar a especificidade.

Neste caso particular, ajustar a especificidade não é tão difícil, então deixe-me mostrar rapidamente antes de prosseguirmos:

#articles li {
  background: #ffe;
}

#articles .active {
  background: #faf;
}

#articles .archived {
  background: #aff;
}

Os conflitos de especificidade ocorrem apenas quando temos o mesmo elemento visado por dois seletores diferentes ao mesmo tempo. A solução? Pare de segmentar o mesmo elemento com vários seletores (às vezes). Graças à :not()pseudoclasse , isso também é bastante trivial de se conseguir.

Eu chamo essa técnica de “seletores mutuamente exclusivos” ou MESs para abreviar.

No nosso caso, um artigo não pode ser ambos .activee não.active ao mesmo tempo, mas o #articles liseletor se aplica em ambos os casos. Podemos separar claramente esses dois casos em CSS com este pequeno ajuste:

#articles li:not(.active, .archived) {
  background: #ffe;
}

.active {
  background: #faf;
}

.archived {
  background: #aff;
}

Quando usar estes

Não é necessário usar sempre como padrão. Embora o exemplo acima seja obviamente manipulado para exigi-los, ainda assim conseguimos resolver esse problema sem usar os MESs. A especificidade é boa (ou pelo menos administrável) em pequenas quantidades e não vale a pena eliminar a todo custo (já posso ver a multidão do BEM saindo .shed--wall--pitchfork__stored).

Acho que esse truque é mais eficaz quando usado conforme necessário, conforme você se depara (ou prevê razoavelmente) os problemas. Não transforme isso em uma religião, agora!