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?

Source