Apple, Google, Microsoft, Mozilla e Igalia concordaram em 20 áreas de foco para CSS em 2026. Pela quinta vez consecutiva. Chama-se Interop 2026.
15 áreas são novas, 5 continuam de 2025. O progresso é medido por Web Platform Tests automatizados com dashboard público. Não é promessa. É métrica.
Algumas das áreas: anchor positioning (posicionar elementos relativos a outros sem JS), a função contrast-color() que garante contraste acessível automaticamente, container style queries, view transitions entre páginas, scroll-driven animations nativas.
Scroll-driven animations em particular já estão em produção. Um relato que circulou recentemente mostra 45KB de biblioteca JavaScript removida e 200 linhas de configuração eliminadas depois de migrar pra CSS puro. O animation-timeline roda na thread do compositor, fora do main thread. Não compete com JS, não causa layout thrashing, mantém 60fps mesmo com o main thread ocupado.
O impacto concreto: menos polyfills no bundle, menos horas de QA cross-browser, menos dependência de bibliotecas de terceiros pra coisas que o navegador já faz. Anchor positioning sozinho elimina boa parte dos cálculos manuais de tooltip e popover que hoje dependem de Floating UI ou Popper.
O que me chama atenção é a consistência. Cinco anos seguidos de alinhamento entre vendors que historicamente não concordavam em nada. Interop não resolve tudo, mas criou uma pressão institucional por compatibilidade que não existia antes.
Se sua equipe ainda testa em 4 navegadores com suíte de regressão visual pesada, vale revisitar o que realmente precisa de teste manual. A distância entre browsers está menor do que parece.
O dashboard mede vendors, não o seu tráfego
O score do Interop 2026 responde se os engines passam no recorte de Web Platform Tests daquela área. Chrome, Firefox, Safari e Edge entram na mesma planilha. O número público é útil porque deixa de ser press release: dá para ver, área por área, o que ainda falha.
Ele não descreve a base que a sua aplicação atende. WebView corporativo, Safari de iPhone antigo, tablet compartilhado e o percentil lento das sessões continuam fora daquela média. Um produto com 8% de tráfego num engine atrasado ainda paga o custo do fallback. Se esse grupo concentra um fluxo de pagamento ou um canal regulado, o custo é maior do que o dashboard sugere.
A lista de 2026 também não é um único bloco de CSS. Há posicionamento, transições, IndexedDB, Navigation API, WebTransport, WebRTC e JSPI para Wasm. Tratar o anúncio como "o CSS ficou padronizado" mistura superfícies com ritmos diferentes. Anchor positioning, view transitions, scroll snap, WebRTC e CSS zoom voltaram de 2025 porque o recorte anterior ainda deixou testes falhando. Carryover é trabalho restante.
Antes de qualquer retirada de biblioteca, cruze duas fontes. A primeira é o dashboard da área que vocês pretendem usar. A segunda é a telemetria de engine nas sessões que importam, incluindo o rabo da distribuição. Sem esse cruzamento, a equipe troca um polyfill estável por um bug que só aparece no dispositivo do cliente.
Polyfill sai quando o público real já passou
Floating UI, Popper e pacotes de animação ligada a scroll existem porque posicionar overlay e amarrar timeline ao scroll não eram confiáveis entre engines. Quando o nativo cobre o caso, o pacote deixa de justificar o próprio custo: atualização, bundle e conflito com o layout atual.
A retirada é uma decisão de produto, não um reflexo do post dos vendors. Defina o recorte mínimo de engine, meça a parcela de sessões abaixo dele e só então tire o JavaScript do caminho crítico. Progressive enhancement continua sendo o mecanismo mais barato: o CSS nativo assume o caso feliz, o script permanece para quem ainda precisa. Detecção no runtime vale mais do que uma tabela de user-agent congelada no backlog.
contrast-color() ilustra o limite da feature isolada. Ela devolve preto ou branco com melhor contraste em relação à cor informada. Safari e Firefox já tinham suporte; o Interop pressiona o restante. A função não calcula contraste de texto sobre imagem, não substitui auditoria e não escolhe paleta de marca. Quem tratar isso como encerramento do trabalho de acessibilidade reabre o tema no próximo review.
Scroll-driven animations no compositor realmente tiram trabalho da main thread quando a implementação está correta. O efeito visual, a preferência por menos movimento e o comportamento em overflow aninhado continuam sendo testes de produto. Remover dezenas de kilobytes de JS só se justifica se o mesmo fluxo continuar utilizável no mix que vocês suportam.
QA muda de superfície, não desaparece
Suíte visual pesada em quatro browsers costuma existir porque o mesmo CSS produzia quatro layouts. Com menos divergência de espaçamento, o valor do screenshot em todos os engines cai para alguns componentes. Sobe o valor das interações que a foto não vê: popover="hint" que não fecha o menu, closedby no dialog, view transition entre documentos, scroll snap em carrossel com teclado.
Redistribua o tempo. Menos regressão de padding em botão. Mais fluxo com teclado, leitor de tela e redução de movimento. O projeto Interop mantém investigações de acessibilidade e de teste mobile fora do score das 20 áreas. Árvore de acessibilidade e viewport dinâmico ainda não têm a mesma pressão institucional das features pontuadas. Isso deveria aparecer no plano de QA, não só no changelog de CSS.
Eu pararia de abrir o mesmo formulário estático em quatro janelas. Manteria o Safari nos fluxos que usam API nova de overlay, navegação e mídia. O custo de um bug aí é ticket de suporte, não um pixel deslocado no Figma.
Migre por superfície, com detecção e rollback
Uma ordem prática reduz o risco de "apagamos o polyfill na segunda". Inventarie os pacotes que existem só para cobrir as áreas de 2026. Classifique cada um por bytes no bundle e por dano se o nativo falhar. Migre primeiro o que tem detecção simples e fallback barato: style queries em tema, contrast-color() em botão com cor de marca. Deixe por último overlay, foco e navegação, onde um erro quebra o caminho principal.
Cada migração precisa de três evidências no pipeline: o recorte de engine da telemetria, um teste do fluxo com a feature nativa e um caminho de volta (flag ou pacote ainda instalado) se o percentil lento falhar. Sem a terceira, a equipe descobre o buraco em produção e recoloca a biblioteca com pressa.
Advanced attr(), getAllRecords() no IndexedDB e WebTransport podem ser irrelevantes para o seu produto. Não gaste ciclo neles só porque entram nos 20%. O Interop alinha vendors. A decisão local continua sendo o que o público já consegue usar, o que ainda precisa de JS e o que o QA deixa de fotografar para passar a exercitar.
