Especificidade CSS Explicada: Como a Cascata Decide

Você escreve .sidebar .card { color: blue; }, carrega a página e o card continua vermelho por causa de uma regra adicionada uma hora antes: .card { color: red; }. A nova regra vem depois no arquivo. Mesmo assim, perde. O navegador compara os dois seletores com um sistema de pontos fixo, e .sidebar .card pontua mais alto que .card, não importa qual você escreveu por último.

Esse sistema de pontos é a especificidade. Depois que você aprende a calculá-la de cabeça, “por que meu CSS não se aplica” se torna aritmética pura. Não tem nada a ver com layout: Grid ou Flexbox decide onde um elemento fica, a especificidade decide qual regra define a cor ou o tamanho quando duas regras entram em conflito.

Como o navegador pontua um seletor

Cada seletor tem um peso formado por três números, geralmente escritos como um trio separado por hífens: ID-classe-tipo. Some o que o seletor contém, coluna por coluna:

O seletor universal * e os combinadores (o espaço, >, ~, +) somam 0-0-0. Eles decidem quais elementos correspondem, não com que força a regra vence.

Alguns seletores reais:

1
2
3
4
5
6

.card            { }  /* 0-1-0 */
.sidebar .card   { }  /* 0-2-0 */
#main .card      { }  /* 1-1-0 */
div.card         { }  /* 0-1-1 */
a:hover          { }  /* 0-1-1 */
nav ul li a      { }  /* 0-0-4 */

Para comparar dois valores, vá da esquerda para a direita; a primeira coluna que divergir decide. 1-1-0 vence 0-2-0 porque a coluna do ID (1 contra 0) decide antes de alguém olhar para as classes. Assim, #main .card vence .sidebar .card .title .text, não importa quão longo seja o segundo seletor. Um ID supera qualquer quantidade de classes.

Por que uma regra CSS mais recente pode continuar perdendo

Voltando ao exemplo inicial, com os números calculados:

1
2

.card        { color: red; }   /* 0-1-0 */
.sidebar .card { color: blue; } /* 0-2-0 */

0-2-0 vence 0-1-0 na coluna das classes, então o card fica azul independentemente da ordem no arquivo. A ordem no arquivo é o critério ao qual quase todo mundo recorre primeiro, mas só vale quando os trios são idênticos:

1
2

.card { color: red; }   /* 0-1-0 */
.item { color: blue; }  /* 0-1-0, mesmo peso, declarada depois: vence */

As duas regras pontuam 0-1-0, então vence a que aparece mais tarde na folha de estilo (ou no bloco <style> posterior, ou na folha vinculada depois da outra). Esse é o único caso em que “a última vence” é o modelo mental correto. Funciona em projetos pequenos, por isso é a primeira coisa que todo mundo aprende, e para de funcionar assim que um projeto passa de um punhado de seletores.

Os estilos inline ficam acima de tudo isso. Um atributo style="color: green" no elemento vence qualquer regra em qualquer folha de estilo, não importa quantos IDs ela encadeie. Só as declarações !important conseguem superá-lo.

1

<p class="card" id="warning" style="color: green;">...</p>

1
2

#warning { color: red; }         /* perde para o estilo inline */
#warning { color: orange !important; } /* vence — !important também supera estilos inline */

!important não faz parte do trio de especificidade. É um nível separado, de prioridade mais alta: qualquer declaração !important vence qualquer declaração normal, estilos inline incluídos, independentemente do peso do seletor. Quando duas declarações !important entram em conflito, a especificidade decide (depois a ordem no arquivo), exatamente como sem a flag. É assim que um único !important se transforma numa corrida armamentista. O próximo desenvolvedor que precisar sobrescrevê-lo não tem outra jogada além de outro !important, e logo ninguém sabe mais qual regra deveria vencer.

Quais seletores somam zero especificidade: :where() contra :is()

Alguns seletores permitem direcionar com precisão sem pagar o preço normal.

:where() sempre contribui com 0-0-0, independentemente do que você colocar dentro:

1

:where(.theme-dark, .theme-light) .card { background: #222; } /* 0-1-0 — só .card conta */

Isso torna :where() o invólucro certo para valores padrão e estilos de tema que precisam ser fáceis de sobrescrever. Uma biblioteca de componentes pode entregar seus padrões dentro de :where(), e uma regra simples .card { } de quem a usa vence sem precisar de !important.

:is(), :not() e :has() funcionam de forma diferente. Não somam peso próprio, mas assumem o peso do seu argumento mais específico:

1
2
3

p                 { }  /* 0-0-1 */
:is(p, #intro)    { }  /* 1-0-0 — #intro é o argumento mais pesado */
div:not(.hidden)  { }  /* 0-1-1 — .hidden ainda conta */

Então :where() é gratuito, e :is() custa tanto quanto o mais pesado que você colocar dentro, mesmo que esse argumento nunca corresponda ao elemento.

Como as cascade layers sobrepõem a especificidade

Se você está acumulando classes e IDs para ganhar disputas que não têm nada a ver com o quão específico um seletor deveria ser, o projeto precisa de @layer, não de mais aninhamento.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

@layer reset, base, components, utilities;

@layer reset {
  * { margin: 0; padding: 0; }
}

@layer components {
  .card { color: red; }
}

@layer utilities {
  .text-blue { color: blue; }
}

A ordem das layers vem de onde você declara os nomes, não do peso dos seletores. utilities foi declarada por último, então uma regra dentro dela vence uma regra em components, mesmo que .text-blue tenha o mesmo peso 0-1-0 que .card. A especificidade continua resolvendo conflitos dentro de uma layer. Entre layers, a ordem das layers vence sem apelação e a especificidade nunca é consultada.

Uma regra pega quase todo mundo de surpresa na primeira vez: para declarações normais (sem !important), estilos fora de qualquer layer vencem estilos dentro de uma layer. Você move seu CSS de componentes para @layer components mas deixa uma sobrescrita sem layer, e essa regra sem layer vence independentemente da ordem em que você declarou as layers. Para declarações !important, a precedência se inverte: as regras important da layer declarada primeiro vencem as das layers posteriores, e os estilos important sem layer ficam no último lugar de todos. A inversão é intencional, e é a parte da especificação que vale reler antes de depender dela.

O suporte dos navegadores já deixou de ser um argumento contra as layers há um tempo: @layer roda em todos os engines principais desde 2022. O custo real é organizacional. O time precisa combinar uma ordem de layers antecipadamente (reset, base, components, utilities é um esquema comum) e encaixar o CSS novo na layer certa. É mais um problema de processo do que de sintaxe.

Erros comuns com especificidade CSS

• Combater especificidade com mais especificidade. Cada sobrescrita adiciona uma classe ou um ID mais pesado que a anterior, até mudar uma cor exigir #app .page .section .card.is-active.is-selected. É o mesmo padrão de falha do spaghetti code: cada correção adiciona mais confusão em vez de remover. A solução quase nunca é um seletor mais pesado. É um mais plano, ou uma layer.
• Recorrer a !important no primeiro conflito. Ganha a disputa imediata e prepara a próxima, porque a próxima sobrescrita não tem mais nenhuma jogada de especificidade normal disponível.
• Esquecer que pseudoclasses contam. :hover, :focus, :nth-child() e o argumento de :not() somam todos 0-1-0. Um simples a { color: blue; } mais abaixo no arquivo não vai sobrescrever a:not(.disabled) { color: red; } escrito acima, porque a versão com :not() é mais pesada.
• Assumir que o valor herdado vence porque a regra “parece” mais forte. Uma regra que aponta diretamente para um elemento sempre vence um valor herdado, qualquer que seja a especificidade da regra de onde vem a herança. Se um filho mostra a cor errada, procure uma regra que aponte para esse filho antes de suspeitar da herança.
• Misturar :is() num seletor esperando que continue barato. :is() assume o peso do seu argumento mais pesado, então :is(.card, #sidebar) é na prática um seletor 1-0-0 disfarçado.

Como verificar a especificidade no DevTools

Você não precisa contar colunas na mão quando um bug está na sua frente. Inspecione o elemento no Chrome ou Firefox DevTools e abra o painel Styles (Rules no Firefox). Cada regra correspondente aparece listada em ordem de cascata, com as declarações sobrescritas tachadas. Passe o mouse sobre um seletor e os dois navegadores mostram sua especificidade. A partir daí você sabe em segundos se está diante de uma diferença de especificidade, um problema de ordem de layers, ou simples ordem de arquivo entre duas regras de peso igual.

Na próxima vez que uma regra perder sem motivo aparente, calcule os dois trios antes de adicionar uma classe ou um !important para forçá-la. Normalmente, a correção certa é tirar peso do seletor que está vencendo, não empilhar mais peso no que deveria ter vencido.

Artigos relacionados

• CSS Grid ou Flexbox: Quando Usar Cada Um
• O Que É Spaghetti Code e Como Refatorá-lo
• O Que É CORS e Como Corrigir Erros CORS