CSS3, CSS4 ou CSS5? Qual é a versão atual do CSS em 2026

Em 2020, publiquei neste blog um texto chamado CSS4: a nova versão do CSS que nunca existirá. Anos depois, um leitor encontrou a publicação e disse que eu não estava sendo “totalmente sincero”.

A observação merece atenção porque aponta para uma confusão que o título antigo não resolvia sozinho. Se CSS4 não existe, por que há especificações chamadas CSS Color Module Level 4, Selectors Level 4 e CSS Cascading and Inheritance Level 5? Se o CSS deixou de ter versões, por que existe um grupo comunitário tentando organizar recursos sob os nomes CSS4 e CSS5? E, principalmente, como alguém decide o que já pode usar em produção?

A resposta curta é esta:

Em setembro de 2026, não existe uma versão única chamada CSS4 ou CSS5. Depois do CSS Level 3, a linguagem passou a evoluir por módulos independentes. “Level 4” ou “Level 5” pode ser o nível de um módulo específico. CSS4 e CSS5 também aparecem como rótulos propostos pela comunidade, mas não substituem as normas oficiais, o CSS Snapshot, o Baseline ou os dados de suporte dos browsers.

Essa resposta encerra a dúvida do número. Ela ainda não mostra o tamanho da mudança.

Seis anos atrás, uma boa explicação poderia parar na modularização. Hoje isso seria pouco. O CSS ganhou mecanismos para consultar o tamanho de um componente, reagir à estrutura do HTML, guardar estados nativos, posicionar elementos por âncoras, animar a partir do scroll, criar formas e calcular cores em espaços perceptuais. Não é uma lista de promessas: há uma interface funcional no meio deste texto para você testar.

O ponto deste artigo não é trocar “CSS3” por outro adesivo. É trocar uma pergunta que ficou pequena por um método que continua útil quando o próximo recurso chegar.

O texto de 2020 estava errado?

O núcleo factual do artigo de 2020 continua correto: não havia um lançamento único de CSS4 esperando para substituir CSS3. O próprio CSS Snapshot 2025 do W3C é direto ao afirmar que não existe “CSS Level 4” para a linguagem inteira.

O problema estava na distância entre essa frase e a pergunta prática do leitor.

“CSS4 não existe” pode soar como “o CSS parou no 3”. Não parou. Também pode sugerir que qualquer uso de “CSS4” é simplesmente falso. A história é mais interessante: o nome não representa uma versão oficial monolítica, mas existe uma iniciativa comunitária que discute justamente o valor didático de agrupar eras do CSS moderno.

Por isso, o texto antigo não precisa ser apagado nem disfarçado de novidade. Ele registra uma explicação de 2020. Este artigo assume a continuação: preserva o que permanece verdadeiro, corrige o que ficou incompleto e acrescenta o método de decisão que faltava.

Há uma diferença importante entre atualizar uma data e atualizar uma ideia. Trocar “2020” por “2026” no título não ensinaria nada novo. Separar norma, suporte e estratégia de adoção muda a forma como você trabalha.

Por que CSS1 e CSS2 pareciam versões comuns

No começo, era razoável imaginar CSS como uma sequência parecida com a de um software.

O CSS Level 1 foi publicado como uma especificação que reunia a linguagem. O CSS Level 2 também foi definido em um documento amplo, dividido em capítulos. Isso criou um modelo mental simples:

CSS1 -> CSS2 -> CSS3 -> CSS4 -> CSS5

Só que a seta deixa de descrever a realidade depois do CSS2.

Uma linguagem de estilos para toda a Web cresceu demais para avançar como um único pacote. Seletores, cores, fontes, layout, animação, mídia, fragmentação, escrita vertical e dezenas de outros assuntos não amadurecem na mesma velocidade. Esperar que tudo ficasse pronto ao mesmo tempo atrasaria trechos estáveis por causa de trechos em teste.

A solução foi modularizar.

O CSS Snapshot 2025 explica que o CSS Level 3 se apoia no CSS Level 2 e avança módulo por módulo. A partir daí, os módulos são nivelados de maneira independente. Um módulo que atualiza algo já presente no CSS2 pode chegar ao Level 3 ou Level 4, enquanto uma área nova pode começar no Level 1.

O número, portanto, mudou de endereço.

Ele deixou de ser uma versão global da linguagem e passou a indicar a evolução de uma parte dela.

O que “Level 4” e “Level 5” realmente significam

Considere estes nomes que aparecem no Snapshot do W3C:

• CSS Color Module Level 4;
• CSS Cascading and Inheritance Level 4;
• CSS Cascading and Inheritance Level 5;
• Selectors Level 4;
• CSS Grid Layout Module Level 2;
• CSS Custom Properties for Cascading Variables Module Level 1.

Eles convivem no mesmo CSS. Não existe contradição em usar, na mesma folha de estilos, algo definido por um módulo Level 1, outro Level 4 e outro Level 5.

O nível indica a revisão daquele módulo. Ele não funciona como selo universal de novidade, qualidade ou suporte. Um número maior também não prova que o recurso funciona em todos os browsers.

É possível ter uma norma madura com adoção incompleta. Também é possível ter amplo suporte enquanto detalhes da norma continuam em ajuste. A relação entre padrão e browser é próxima, mas não é uma fila com uma única catraca.

Essa distinção evita dois erros comuns:

1. “Está em um documento do W3C, então posso usar sem verificar.”
2. “O módulo é Level 1, então deve ser antigo ou limitado.”

Nenhum dos dois raciocínios se sustenta. O nível pertence ao módulo. O suporte depende dos browsers. A decisão pertence ao contexto do projeto.

Então CSS4 e CSS5 existem ou não?

A resposta correta depende do que você quer dizer com “existir”.

Como versão oficial única da linguagem

Não. O CSS Working Group não lançou um pacote chamado CSS4 que substitui CSS3, nem um pacote CSS5 que substitui CSS4. A definição oficial continua modular. O Snapshot reúne especificações que formam o estado da linguagem em uma determinada data, sem transformar esse conjunto em uma nova versão monolítica.

Como nível de um módulo

Sim. “Level 4” e “Level 5” existem em nomes oficiais de módulos. CSS Color 4 e CSS Cascade 5 são exemplos. Dizer “um recurso do CSS Color Level 4” é muito diferente de dizer “este site usa a versão CSS4”.

Como rótulo comunitário e didático

Também existe uma discussão real.

O CSS4 Community Group foi criado em 2020 para debater uma forma de agrupar adições recentes à linguagem. A própria descrição do grupo deixa claro que isso não muda a operação do CSS Working Group, não altera a numeração das especificações e permanece separado dos Snapshots oficiais.

Em 2024, a comunidade CSS-Next publicou um pedido de comentários para uma categorização inicial. A proposta agrupa aproximadamente:

A proposta tenta resolver um problema de comunicação. “CSS moderno” não informa época, conjunto de recursos nem pré-requisitos. Rótulos por era podem ajudar cursos, vagas e conversas a expressar evolução.

Mas um recurso didático não deve ser confundido com um contrato técnico. Para decidir se anchor positioning entra no seu produto, saber que alguém o associa a “CSS5” é menos útil do que conhecer sua norma, seu estado no Baseline, a convergência atual, seu público e o fallback.

Snapshot, Baseline e Interop não são três nomes para a mesma coisa

Esta é a parte que faltava na explicação antiga. Há pelo menos três perguntas diferentes escondidas em “qual é a versão atual do CSS?”.

CSS Snapshot: o que compõe a linguagem em determinado momento?

O CSS Snapshot reúne as especificações que formam o estado do CSS segundo critérios de estabilidade do trabalho de padronização.

Na data de verificação deste artigo, 11 de setembro de 2026, o Snapshot publicado mais recente que encontramos é o CSS Snapshot 2025, uma nota do CSS Working Group publicada em 18 de setembro de 2025. A página de trabalho atual do CSS Working Group acompanha módulos e rascunhos que continuam evoluindo em 2026.

Isso precisa ser dito sem maquiagem editorial: não existe um “CSS Snapshot 2026” publicado só porque este artigo foi escrito em 2026.

O próprio Snapshot avisa que sua classificação considera a solidez das normas, não a taxa de adoção nos browsers. Ele responde muito bem à pergunta sobre a definição da linguagem. Não foi criado para ser uma tabela pronta de suporte para autores.

Baseline: quando um recurso chega ao conjunto principal de browsers?

O Web Platform Baseline organiza o suporte a recursos da plataforma em estados claros.

De forma simplificada:

• Limited Availability: o recurso ainda não está disponível em todo o conjunto principal acompanhado pelo Baseline;
• Newly Available: passou a funcionar em todo esse conjunto, mas a chegada ainda é recente;
• Widely Available: o suporte amplo já atravessou a janela de 30 meses definida pelo projeto.

O painel do Baseline 2026 inclui, entre os itens que se tornaram Newly Available no ano, recursos como consultas de estilo em contêineres, a pseudoclasse :open, contrast-color() e custom highlights.

Baseline não é uma versão do CSS. Ele também não decide sozinho se um recurso serve para o seu produto. Ele torna mais fácil descobrir se o suporte básico convergiu no conjunto de browsers observado.

Interop: em que áreas os motores estão trabalhando para convergir?

O projeto Interop 2026 coordena áreas de foco entre implementações. Entre os temas do ciclo aparecem posicionamento por âncora, consultas de estilo em contêineres, diálogos e popovers, animações guiadas por scroll, transições de visualização, contrast-color(), scroll snap e shape().

Estar em uma área do Interop não significa “suporte completo garantido”. Significa que aquela área foi priorizada para melhorar interoperabilidade e resultados nos testes compartilhados.

Uma frase resume a divisão:

Snapshot ajuda a responder o que forma o CSS. Baseline mostra onde um recurso funciona. Interop mostra onde os motores concentram esforço para convergir.

Ainda falta a quarta pergunta: “isso serve para os meus usuários?”. Nenhum painel externo conhece sozinho sua matriz de navegadores, suas exigências de acessibilidade ou o custo aceitável de um fallback.

Observatório CSS 2026: o CSS moderno trabalhando como sistema

É fácil transformar CSS moderno em uma coleção de truques. Um card usa :has(), outro tem uma animação e um terceiro muda de cor. O resultado impressiona por alguns segundos, mas não demonstra como recursos diferentes compõem uma interface.

O painel abaixo foi construído como uma peça única. Os controles são inputs, labels, links, details, summary, botão e popover nativos. Não há JavaScript controlando modo, seleção, abertura, rolagem, forma ou movimento.

Teste com mouse, toque e teclado. Expanda o módulo de tamanho. Marque os três sinais. Abra e feche os painéis. Role a linha do tempo horizontal. Abra a telemetria ancorada. Navegue pelos fragmentos. Pause o cometa. Troque a forma, a paleta e o modo de toda a central.

Se algum recurso novo não estiver disponível, a experiência não desaparece. O componente preserva conteúdo e controles nativos; as camadas mais novas refinam layout, posição, movimento e cor. Essa é a diferença entre usar CSS experimental como fundação obrigatória e usá-lo como aprimoramento progressivo.

Nove coisas que essa interface faz sem JavaScript de estado

O código completo do painel vive no próprio projeto, não em uma animação gravada. Alguns trechos revelam as decisões principais.

1. O componente responde ao próprio tamanho

Media queries respondem ao viewport. Container queries permitem que uma unidade reutilizável responda ao espaço que o layout lhe concedeu.

.module {
  container: probe / inline-size;
}
 
@container probe (min-width: 18rem) {
  .module__layout {
    grid-template-columns: 0.72fr 1.28fr;
  }
}

No painel, os botões “Compacto” e “Expandido” alteram a largura do módulo. O ponto de quebra pertence ao componente. Duas instâncias na mesma tela poderiam assumir layouts diferentes sem consultar o viewport.

Para uma implementação focada nesse assunto, há também o artigo CSS Container Queries na prática.

2. O elemento pai reage à estrutura com :has()

Por muito tempo, o CSS selecionava com facilidade descendentes de um elemento, mas não o ancestral com base no que havia dentro dele. :has() muda essa relação.

.panel:has(#signal-size:checked):has(#signal-state:checked):has(#signal-color:checked) {
  border-color: var(--success);
}
 
.panel:has(#signal-size:checked):has(#signal-state:checked):has(#signal-color:checked)
  .all-systems {
  display: block;
}

Marque os três sinais no painel de estrutura. O contêiner percebe a combinação de estados dos descendentes e revela a mensagem final. Não existe listener de clique atualizando uma classe.

Isso não transforma CSS em substituto universal de lógica de aplicação. Ele apenas devolve ao mecanismo de estilo decisões que pertencem à apresentação da estrutura.

3. O HTML já possui estado interativo

details e summary oferecem divulgação nativa, foco por teclado e um atributo open que representa o estado. A pseudoclasse :open permite estilizar elementos que estão abertos.

.details[open] summary::after {
  rotate: 45deg;
}
 
@supports selector(details:open) {
  .details:open {
    border-color: var(--accent);
  }
}

O primeiro seletor é o fallback amplamente compreendido. O bloco de suporte acrescenta a forma mais expressiva quando disponível. A informação continua acessível nas duas camadas.

4. O scroll pode dirigir uma animação

O trilho histórico usa scroll-snap-type para encaixar as cenas. Quando timelines de scroll estão disponíveis, a posição horizontal também controla o preenchimento da barra.

.timeline {
  scroll-timeline: --history inline;
  overflow-x: auto;
  scroll-snap-type: inline mandatory;
}
 
.progress {
  animation: fill linear both;
  animation-timeline: --history;
}
 
@keyframes fill {
  from { scale: 0.08 1; }
  to { scale: 1 1; }
}

Sem suporte à timeline, o trilho ainda rola e o snap continua útil. A barra permanece como elemento visual estático. A falha é estética, não funcional.

O tema merece profundidade própria, por isso o blog mantém o artigo Animações de scroll nativas com CSS.

5. Um popover pode se posicionar pela própria âncora

Menus, tooltips e callouts costumavam exigir cálculo de coordenadas, observação de resize, tratamento de scroll e bibliotecas especializadas. Anchor positioning fornece uma linguagem declarativa para relacionar o elemento posicionado ao elemento que o orienta.

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

O botão do painel usa o mecanismo declarativo de popover do HTML. Anchor positioning melhora sua posição. Se essa melhoria faltar, o popover nativo continua abrindo segundo o comportamento do browser.

6. A URL também pode representar estado

Os links do painel de navegação apontam para fragmentos reais. Ao selecionar “Cores”, por exemplo, a URL ganha #obs-colors, o navegador leva o foco visual à área e :target destaca o destino.

.module:target {
  border-color: var(--accent);
  box-shadow: 0 0 0 3px color-mix(in srgb, var(--accent) 18%, transparent);
}

É uma interação pequena, mas ilustra um princípio grande: nem todo estado de interface precisa morar em memória JavaScript. Quando o fragmento descreve navegação real, ele ainda oferece histórico, link copiável e comportamento conhecido do navegador.

7. Movimento pode seguir uma trajetória

O cometa não interpola uma pilha de translate() calculada manualmente. Ele percorre um offset-path.

.comet {
  offset-path: path("M 18 72 C 70 5 170 5 245 68");
  animation: flight 3.5s ease-in-out infinite alternate;
}
 
@keyframes flight {
  from { offset-distance: 0%; }
  to { offset-distance: 100%; }
}

O controle “Pausar movimento” é um checkbox. A regra com :has() troca animation-play-state. Além disso, o componente respeita prefers-reduced-motion: se o sistema operacional pede menos movimento, as animações não ficam repetindo.

8. Formas podem ser descritas em CSS

O painel começa com um clip-path: polygon(...), usado como base. Em browsers capazes de interpretar shape(), a forma alternativa ganha curvas declarativas.

.object {
  clip-path: polygon(50% 0%, 100% 38%, 80% 100%, 50% 76%, 20% 100%, 0% 38%);
}
 
@supports (clip-path: shape(from 0 0, line to 100% 0, close)) {
  .object {
    clip-path: shape(
      from 50% 0%,
      curve to 98% 35% with 92% 5%,
      curve to 70% 98% with 100% 78%,
      curve to 5% 70% with 35% 100%,
      curve to 50% 0% with 0% 28%,
      close
    );
  }
}

Novamente, a camada nova não é usada para esconder conteúdo essencial. Ela aumenta a liberdade visual quando existe.

9. Cor deixou de ser uma coleção de hexadecimais isolados

OKLCH descreve a cor em eixos mais úteis para manipulação perceptual. color-mix() cria relações entre cores sem duplicar uma paleta inteira. contrast-color() pode escolher uma cor de contraste em implementações que já oferecem a função.

.swatch {
  --brand: oklch(72% 0.2 28);
  background: linear-gradient(
    135deg,
    color-mix(in oklch, var(--brand), black 22%),
    var(--brand)
  );
  color: white;
}
 
@supports (color: contrast-color(red)) {
  .swatch {
    color: contrast-color(var(--brand));
  }
}

O fallback declara texto branco. A função de contraste assume a decisão apenas quando reconhecida. Em um design system, esse padrão reduz valores copiados, mas não elimina a obrigação de testar contraste real, estados de interação e combinações extremas.

O “sem JavaScript” precisa ser entendido sem fanatismo

O painel não usa JavaScript para controlar suas interações. Isso não prova que toda aplicação deveria banir JavaScript.

Prova outra coisa: hoje atribuímos ao JavaScript tarefas que, em muitos casos, o navegador já executa com semântica, acessibilidade e fallback melhores.

Use CSS e HTML para estados de apresentação, adaptação de layout, divulgação nativa, posicionamento e movimento quando esses mecanismos expressarem o problema. Use JavaScript quando houver regra de negócio, dados assíncronos, coordenação complexa, persistência, validação que ultrapassa o navegador ou comportamento que realmente depende de programação imperativa.

O ganho não é vencer uma competição de menor número de bytes de JavaScript. É reduzir a quantidade de estado que seu código precisa inventar e sincronizar.

Um details aberto já sabe que está aberto. Um fragmento já sabe qual é o alvo. Um componente dentro de um contêiner já conhece o espaço que recebeu. Duplicar esses fatos em outra camada pode ser necessário, mas deixou de ser automático.

Como decidir se um recurso CSS pode entrar em produção

Perguntar “qual browser suporta?” ainda é amplo demais. Uma decisão responsável cabe em cinco verificações.

1. Qual é a fonte da afirmação?

Comece pela especificação do módulo e por documentação que declare compatibilidade com data e versão. Uma postagem de rede social pode revelar o recurso; ela não deve ser a única base de uma decisão de produto.

O trabalho atual do CSS Working Group ajuda a localizar as normas. Baseline ajuda a ler o suporte. Testes como web-platform-tests ajudam a observar convergência. Dados do seu próprio produto mostram quais browsers realmente chegam aos usuários.

2. A funcionalidade é essencial ou é uma melhoria?

Se a ausência do recurso impede comprar, autenticar, ler ou concluir a tarefa principal, a exigência de compatibilidade é alta. Se ela remove um brilho, uma curva ou uma transição, um fallback simples pode bastar.

O painel separa essas camadas:

3. Existe um fallback honesto?

Fallback não significa reconstruir exatamente o mesmo efeito antigo. Significa preservar informação e tarefa.

Sem container query, um card pode ficar em coluna. Sem anchor positioning, um popover pode abrir na posição padrão. Sem timeline de scroll, o conteúdo continua rolável. Sem shape(), um polígono continua desenhando a forma. O projeto não precisa fingir igualdade visual onde há apenas equivalência funcional.

@supports ajuda quando a presença de uma propriedade ou seletor representa de fato a capacidade necessária:

.feature {
  /* Base legível e funcional. */
}
 
@supports (position-anchor: --menu-trigger) {
  .feature {
    /* Melhoria que depende de anchor positioning. */
  }
}

4. Seus usuários estão representados pela matriz genérica?

Baseline oferece uma linguagem comum, não uma análise personalizada da sua audiência.

Um painel interno usado apenas em browsers gerenciados pode adotar algo cedo. Um serviço público que atende aparelhos antigos, webviews embutidas ou políticas corporativas precisa de outro limiar. A pergunta não é “o CSS moderno está pronto?”. É “a camada essencial continua funcionando dentro da matriz que este produto assumiu?”.

5. Como o recurso será reavaliado?

Compatibilidade muda. Um fallback que hoje é obrigatório pode virar peso morto. Uma sintaxe experimental pode mudar antes de estabilizar.

Registre a data da decisão, os browsers testados, o link da norma, o estado Baseline, a função do fallback e a condição para removê-lo. “Testado uma vez” não é plano de manutenção.

O que realmente mudou nos últimos seis anos

A maior mudança não é uma propriedade isolada. É o aumento do vocabulário declarativo disponível para problemas de interface.

Em 2020, explicar modularização já desmontava a expectativa de um lançamento CSS4. Em 2026, a mesma explicação precisa alcançar um segundo nível: módulos independentes não produzem apenas números independentes. Eles produzem capacidades que chegam em momentos diferentes, combinam-se entre si e pedem decisões graduais de adoção.

O CSS atual consegue observar mais contexto:

• o tamanho do contêiner, não apenas o viewport;
• a presença e o estado de descendentes;
• a posição do scroll como origem de tempo;
• uma âncora como referência espacial;
• preferências do usuário, como redução de movimento;
• relações perceptuais entre cores;
• estados que o próprio HTML já representa.

Isso altera arquitetura. Um componente pode carregar mais de sua própria lógica visual. Um design system pode expressar relações em vez de manter tabelas de valores duplicadas. Uma interação pode conservar semântica nativa em vez de começar por uma div e reconstruir teclado, foco e estado.

Também aumenta a responsabilidade. Quanto mais poderosa a camada, mais fácil produzir uma demonstração espetacular e inacessível. Movimento precisa de propósito e opção de redução. Contraste calculado ainda precisa ser validado. Conteúdo rolável precisa funcionar por teclado. Um seletor elegante não justifica esconder a tarefa principal de parte do público.

CSS moderno não é licença para abandonar fundamentos. É justamente o contrário: os recursos mais interessantes funcionam melhor quando nascem sobre HTML semântico, cascade compreendida e fallbacks deliberados.

Para organizar essa base em projetos grandes, vale cruzar esta leitura com Cascade Layers e especificidade sem gambiarras e BEM, OOCSS ou Utility-First.

Afinal, qual CSS devo dizer que uso?

Na maioria dos projetos, diga apenas CSS.

Se o contexto exigir precisão, nomeie o recurso ou o módulo: “container queries”, “Selectors Level 4”, “CSS Color 4”, “Cascade Layers”. Se a conversa for sobre suporte, acrescente o estado Baseline e a matriz de browsers testada. Se for sobre ensino e eras históricas, explique que CSS4 ou CSS5 são rótulos comunitários, não releases oficiais da linguagem.

“Este site usa CSS3” não chega a ser sempre uma frase absurda, mas quase nunca descreve o que a pessoa pensa que descreve. Um site atual provavelmente combina uma base histórica do CSS2 com módulos de níveis 1, 2, 3, 4 e 5, além de partes em diferentes estágios de especificação e implementação.

O número único transmite uma segurança que a plataforma não oferece.

A melhor resposta para a crítica do leitor

O leitor tinha razão sobre um ponto essencial: dizer apenas que CSS4 nunca existiria deixava uma história grande demais do lado de fora.

CSS4 não se tornou o sucessor oficial e monolítico de CSS3. CSS5 também não. Ao mesmo tempo, níveis 4 e 5 são reais dentro de módulos, e CSS4/CSS5 são nomes reais em uma proposta comunitária de organização didática. Ignorar uma dessas camadas produz uma resposta tecnicamente estreita.

Mas a correção mais útil não é escolher um lado da disputa pelo nome. É mostrar por que o nome não resolve o trabalho.

Quando você encontrar um recurso novo, faça quatro perguntas:

1. Em qual módulo e estágio de especificação ele está?
2. Qual é seu suporte no Baseline e nos browsers relevantes?
3. Em que ponto a interoperabilidade ainda está convergindo?
4. Qual experiência permanece quando essa camada não existe?

O Observatório CSS 2026 foi construído com essa ordem: HTML semântico, base funcional, melhorias detectáveis e movimento reduzido respeitado. Ele não precisa ser idêntico em todo navegador para continuar sendo o mesmo sistema.

Essa é, para mim, a resposta mais honesta sobre a versão atual do CSS: não há um próximo número esperando para liberar a linguagem. Há uma plataforma viva, modular e poderosa, e aprender a lê-la vale muito mais do que decorar o nome de uma versão.

Fontes e data de verificação

As afirmações sobre normas, suporte e interoperabilidade foram verificadas em 11 de setembro de 2026. Estados de suporte mudam e devem ser consultados novamente antes de uma decisão de produção.

• CSS Snapshot 2025, W3C
• CSS current work, W3C
• CSS4 Community Group, W3C
• RFC de categorização CSS3, CSS4 e CSS5, CSS-Next
• Web Platform Baseline, WebDX Community Group
• Baseline 2026, web.dev
• Interop 2026, web.dev