Camadas de cascata no CSS: qual regra vence, e em qual passo

O que são camadas de cascata

Uma camada de cascata é uma gaveta com nome onde você põe CSS para poder ordenar grupos inteiros de regras entre si sem tocar num único seletor. Você declara a ordem uma vez — @layer reset, components, utilities — e daí em diante o que estiver em utilities vence o que estiver em components, não importa como os seletores se comparem. É o mecanismo que o CSS ganhou para o problema que a especificidade nunca foi feita para resolver: impedir que um framework, uma biblioteca de componentes e os seus próprios ajustes briguem.

A regra que surpreende todo mundo é o que acontece com o CSS que não está em camada nenhuma. A especificação diz que toda declaração não atribuída a uma camada explícita é adicionada a uma camada final implícita — e como camadas posteriores vencem as anteriores, os estilos sem camada vencem todas as camadas que você declarou. Não por serem mais específicos, nem por virem depois no arquivo. Por estarem sem camada, o que os coloca por último na ordem das camadas.

A própria especificação demonstra isso. Ela mostra uma regra audio simples com especificidade 0,0,1, escrita primeiro, vencendo uma regra audio[controls] de 0,1,1 dentro de uma camada reset — e diz sem rodeios que as declarações sem camada têm precedência mesmo tendo menos especificidade e vindo antes na ordem de aparição. Esse é o exemplo padrão desta página, e a ferramenta aponta o passo das camadas como o que decidiu.

Como usar

1. Cole as regras que estão competindo. Declarações de camada, blocos de camada e regras comuns são todos lidos. Deixe só as declarações realmente em disputa — a cascata resolve uma propriedade de cada vez, e a ferramenta avisa se encontrar mais de uma.
2. Leia o passo que decidiu, não só a vencedora. O veredicto nomeia qual dos seis passos separou as duas primeiras. Essa é a parte que importa: se disser passo quatro, nenhuma classe que você acrescente a um seletor vai mudar o resultado.
3. Confira a ordem das camadas. Ela aparece na ordem que o navegador usa, com a camada final implícita dos estilos sem camada lá embaixo, que é onde ela realmente fica. Os botões de exemplo cobrem o caso da especificação, um !important que sai pela culatra, uma ordem de camadas definida antes, e uma disputa que chega até a especificidade.

Por que !important enfraquece uma regra sem camada

Esta é a parte que parece bug e não é. A especificação diz que, ao comparar declarações de camadas diferentes, para as normais vence a da última camada — e para as important vence a da primeira. A importância inverte a ordem das camadas por completo.

Agora junte isso com a camada final implícita. Uma declaração sem camada fica por último, o que a torna a mais forte entre as normais. Marque com !important e a ordem vira do avesso: última passa a ser a mais fraca, então a mesma regra deixa de vencer todas as camadas e passa a perder para todas. Colocar !important num ajuste sem camada, que é o reflexo quando algo não pega, é justamente o movimento errado — é o segundo botão de exemplo desta página.

A nota da especificação explica por que isso é coerente e não perverso: segue a mesma lógica da ordem de origens, onde estilos important do autor são mais fracos que os important do usuário mesmo que os normais do autor sejam mais fortes que os normais do usuário. A marca !important existe para que quem está mais abaixo na pilha possa impor algo que quem está acima não consiga anular. As camadas herdam essa lógica, então a marca significa ceda à camada base, não vença a qualquer custo.

A consequência prática vale ser dita com clareza. Se você usa camadas e precisa que um ajuste vença, ponha-o numa camada posterior em vez de recorrer ao !important. E se você já tem !important espalhado por CSS sem camada, adotar camadas vai mudar quais dessas regras vencem, numa direção que não se enxerga só lendo.

A especificidade é o quinto passo de seis

A cascata ordena as declarações por seis critérios em sequência, e para no primeiro que as separe. Primeiro origem e importância, depois contexto, depois se a declaração está presa diretamente ao elemento, depois as camadas, depois a especificidade, e por fim a ordem de aparição. A especificidade é a quinta. Tudo acima dela vence antes de o seletor sequer ser examinado.

Isso inverte como o assunto costuma ser ensinado. A especificidade fica com as calculadoras, as regrinhas em base dez e as discussões, e decide uma disputa só depois que origem, importância, fixação e camadas empataram todas. Este site também tem uma calculadora de especificidade, e ela responde a uma pergunta genuinamente diferente: diz como dois seletores se comparam, enquanto esta página diz se essa comparação chega a acontecer.

As duas páginas compartilham um motor exatamente por isso — os números de especificidade daqui são calculados pelo mesmo módulo, então as duas não podem imprimir valores diferentes para o mesmo seletor.

Há mais um membro da lista que vale conhecer. Estilos presos diretamente — um atributo style — ficam no passo três, acima das camadas e acima da especificidade. É por isso que um estilo inline vence um seletor de ID sem ser mais específico que nada: ele vence dois passos antes.

O que isto não faz

Ele lê de propósito uma fatia pequena de CSS: declarações de camada, blocos de camada e regras comuns. Não é um parser de CSS geral, então uma media query, uma container query, uma regra aninhada ou um bloco supports é ignorado com um aviso em vez de resolvido. Isso mantém a página sobre a cascata e não sobre parsing, e significa que você deve colar as regras que competem e não uma folha de estilos inteira.

Dois dos seis passos não são aplicados, e pelo mesmo motivo: não há a que aplicá-los. O contexto precisa de fronteiras de shadow tree, que uma folha colada não tem. E dois dos oito postos de origem são as declarações de transição e de animação, que precisam de algo realmente rodando. A tabela completa é mostrada com essas linhas marcadas, então a omissão fica visível em vez de silenciosa.

Ele também não conhece o seu documento. A cascata só compara declarações que se aplicam ao mesmo elemento e à mesma propriedade, e se dois seletores casam com o mesmo elemento é uma pergunta sobre o seu HTML. A ferramenta assume que tudo que você cola está em disputa; se uma regra nunca casa, ela nem entra na competição.

Por fim, isto resolve a cascata, não o caminho todo da folha de estilos até o pixel desenhado. Herança, as palavras-chave revert e revert-layer e as transições agem depois que uma vencedora é escolhida, e nenhuma delas é modelada aqui.

Por que é grátis?

Ler CSS e ordenar declarações é trabalho de texto e roda no seu navegador. Não há servidor envolvido, então não há nada para cobrar nem conta para criar.

Nada é enviado e nada é guardado. Recarregue a página e ela terá esquecido o seu CSS.