CSS4 não existe. Mas o CSS de 2026 já reage a tamanho, estado, posição e scroll

Em 2020, publiquei um texto dizendo que CSS4 nunca existiria como a próxima versão única do CSS. Recentemente, um leitor encontrou aquele artigo e disse que eu não estava sendo totalmente sincero.

Ele tocou no ponto certo.

Não porque o W3C tenha lançado um pacote chamado CSS4. Isso não aconteceu. O problema é que responder apenas "CSS4 não existe" deixa de fora quase tudo o que aconteceu com a linguagem nos últimos seis anos.

A resposta curta e precisa, em setembro de 2026, é esta:

CSS4 e CSS5 não existem como versões oficiais únicas da linguagem. Depois do CSS Level 3, os módulos passaram a evoluir de maneira independente. Por isso existem Selectors Level 4, CSS Color Level 4 e CSS Cascade Level 5 sem existir uma versão global chamada CSS4 ou CSS5.

Só que a discussão do nome ficou pequena. O CSS atual já consegue reagir ao tamanho de um componente, ao estado dos elementos dentro dele, à posição do scroll e à localização de uma âncora. Ele também ganhou estados nativos de interface, trajetórias de movimento, formas declarativas e espaços de cor perceptuais.

A pergunta útil deixou de ser "qual é a versão do CSS?". Agora ela é: como saber o que já pode entrar em produção e o que ainda precisa de fallback?

Snapshot, Baseline e Interop respondem a perguntas diferentes

Tratar esses três projetos como sinônimos cria uma falsa sensação de segurança.

Referência	Pergunta que ela ajuda a responder	O que ela não garante
CSS Snapshot	Quais especificações formam o estado atual do CSS segundo sua estabilidade normativa?	Adoção completa pelos navegadores usados no seu produto
Baseline	O recurso chegou ao conjunto principal de navegadores acompanhado pelo projeto?	Compatibilidade com toda versão antiga, WebView ou browser corporativo
Interop	Em quais áreas os motores estão trabalhando para aumentar a convergência?	Suporte completo ou idêntico naquele momento

O CSS Snapshot 2025 é explícito: módulos independentes podem chegar ao Level 4 ou além, mas a linguagem inteira não possui mais esses níveis. O mesmo documento também avisa que a inclusão de um módulo considera estabilidade da especificação, não sua taxa de adoção nos browsers.

Baseline e Interop completam a análise, mas a decisão final ainda depende da sua audiência e do papel daquele recurso na interface.

Três provas de que o problema mudou

1. Um componente pode responder ao próprio espaço e ao estado interno

Media queries observam o viewport. Container queries permitem que a unidade responda ao espaço que realmente recebeu no layout.

<article class="probe">
  <label>
    <input id="advanced" type="checkbox">
    Exibir telemetria avançada
  </label>

  <div class="probe__layout">
    <section>Métricas</section>
    <aside>Detalhes</aside>
  </div>
</article>

.probe {
  container: probe / inline-size;
}

.probe__layout {
  display: grid;
  gap: 1rem;
}

@container probe (min-width: 36rem) {
  .probe__layout {
    grid-template-columns: 2fr 1fr;
  }
}

.probe:has(#advanced:checked) {
  border-color: oklch(72% 0.2 250);
}

O layout responde ao contêiner, não à tela inteira. O elemento pai reage ao checkbox com :has(), sem listener de clique e sem uma classe sincronizada por JavaScript.

Isso não transforma CSS em linguagem de regra de negócio. Significa apenas que decisões de apresentação podem permanecer na camada que já conhece o layout e a estrutura.

2. Um popover pode abrir e se posicionar sem calcular coordenadas

O HTML representa a abertura. O CSS relaciona o painel à sua âncora.

<button class="beacon" popovertarget="telemetry">
  Abrir telemetria
</button>

<aside id="telemetry" popover>
  Dados do módulo selecionado
</aside>

.beacon {
  anchor-name: --beacon;
}

@supports (position-anchor: --beacon) {
  #telemetry:popover-open {
    position-anchor: --beacon;
    top: anchor(bottom);
    left: anchor(center);
    translate: -50% 0.5rem;
  }
}

Sem anchor positioning, o popover nativo ainda pode abrir. A camada nova melhora a posição sem transformar sua ausência em falha funcional.

3. A posição do scroll pode dirigir a animação

.timeline {
  overflow-x: auto;
  scroll-snap-type: inline mandatory;
  scroll-timeline: --history inline;
}

.progress {
  transform-origin: left;
  animation: fill linear both;
  animation-timeline: --history;
}

@keyframes fill {
  from { scale: 0.05 1; }
  to { scale: 1 1; }
}

Não há evento scroll, cálculo manual de porcentagem nem requestAnimationFrame. Sem a timeline, o conteúdo continua rolável e o scroll-snap continua útil. O efeito é progressivo.

O experimento que não cabia em uma coleção de snippets

Snippets separados mostram sintaxe. Eles não provam que os recursos conseguem formar uma interface coerente.

Por isso construí o Observatório CSS 2026, uma central interativa que combina nove capacidades em um único sistema:

1. container queries;
2. :has();
3. estados nativos com :checked, :open e :target;
4. animações guiadas pelo scroll;
5. anchor positioning e popover;
6. navegação por fragmentos;
7. motion path;
8. clip-path com shape() progressivo;
9. OKLCH, color-mix() e contrast-color().

Os controles usam HTML nativo. Não há JavaScript mantendo o estado das interações. O componente também preserva conteúdo e operação quando uma camada recente não está disponível, funciona por teclado e respeita prefers-reduced-motion.

Você pode testar a interface aqui:

Abrir o Observatório CSS 2026 e testar as nove capacidades

O critério que uso antes de colocar CSS novo em produção

Uma demonstração impressionante ainda não é uma decisão de produto. Para cada recurso, faço cinco perguntas:

1. Qual é a fonte da afirmação? Localizo o módulo, seu estágio e documentação de compatibilidade datada.
2. A funcionalidade é essencial ou progressiva? Comprar, autenticar e ler exigem um limiar diferente de uma transição visual.
3. Qual tarefa permanece sem o recurso? Fallback deve preservar informação e operação, não necessariamente reproduzir cada pixel.
4. A matriz genérica representa meus usuários? Baseline não conhece WebViews antigas, políticas corporativas nem os dados reais do seu produto.
5. Quando essa decisão será revista? Registro data, navegadores testados, fallback e condição para removê-lo.

O princípio é simples:

.feature {
  /* Base legível e funcional para todos. */
}

@supports (position-anchor: --menu-trigger) {
  .feature {
    /* Melhoria aplicada somente quando a capacidade existe. */
  }
}

CSS moderno não elimina fundamentos. Ele recompensa HTML semântico, cascade compreendida, acessibilidade e fallbacks deliberados.

Então qual versão do CSS você usa?

Na maioria dos projetos, a resposta mais honesta é apenas CSS.

Quando precisar de precisão, cite o recurso ou o módulo: container queries, Selectors Level 4, CSS Color 4, Cascade Layers. Se a conversa for sobre adoção, acrescente o estado Baseline e os browsers realmente testados.

CSS4 não virou o sucessor oficial de CSS3. CSS5 também não. Ao mesmo tempo, níveis 4 e 5 são reais dentro dos módulos, e existe até um grupo comunitário discutindo CSS4 como rótulo didático, separado das normas oficiais.

O leitor que questionou meu texto antigo tinha razão sobre o problema central: dizer somente que CSS4 não existe já não explica o CSS que usamos hoje.

A versão completa reúne a história, a distinção entre os níveis, as fontes verificadas em setembro de 2026, os nove exemplos, os fallbacks e o Observatório funcionando no navegador:

Ler o artigo completo e experimentar o CSS de 2026

Qual desses recursos mudou mais a forma como você escreve CSS? E qual ainda parece cedo demais para o seu ambiente de produção?