Compatibilidade de navegador raramente entra no planejamento com a elegância de uma feature. Ela aparece quando alguém abre um bug no Safari, quando um componente de design fica diferente no Firefox, ou quando o QA descobre que uma API nova tem uma interpretação própria em cada engine. O Interop 2026 existe justamente para atacar uma parte dessa conta antes que ela vire uma coleção de condicionais difíceis de explicar.
A iniciativa reúne Apple, Google, Igalia, Microsoft e Mozilla em torno de testes da plataforma web. Não é uma tabela de marketing dizendo que todos os navegadores são iguais; é um conjunto de áreas em que as engines concordam em medir, corrigir e acompanhar interoperabilidade por meio dos Web Platform Tests.
O que está no radar em 2026
São 20 áreas de foco, 15 delas novas. A lista mistura recursos que chamam atenção no CSS, como anchor positioning, container style queries, contrast-color(), shape() e scroll-driven animations, com problemas bem menos glamourosos e igualmente importantes: carregamento de módulos ES, timing de eventos de scroll e compatibilidade geral da web.
- UI e CSS: dialogs, popovers, Scroll Snap, View Transitions, CSS Zoom e shapes.
- Plataforma: Navigation API, IndexedDB, Fetch Uploads and Ranges e WebTransport.
- Runtime: integração entre Promises JavaScript e WebAssembly.
- Confiabilidade: WebRTC, Web Compat e testes em cenários móveis.
Essa variedade é saudável porque compatibilidade não é só “o seletor novo funciona?”. Uma aplicação pode ter CSS perfeito e ainda falhar por uma diferença em navegação, storage, eventos ou módulos. É o tipo de detalhe que não aparece em uma demo de trinta segundos, mas aparece num produto usado todos os dias.
Como isso muda uma decisão de projeto
Interop não é uma permissão automática para remover todo fallback. O uso prático é mais sóbrio: quando uma feature entra no escopo, a equipe ganha uma fonte melhor para investigar seu estado, em vez de depender apenas da experiência de quem testou no próprio notebook. Acompanhe a compatibilidade real, defina os navegadores atendidos e escolha um caminho base que continue funcional.
.card {
position: relative;
}
/* Base funcional: o tooltip segue no fluxo normal. */
.tooltip {
margin-top: .5rem;
}
@supports (anchor-name: --card) {
.card { anchor-name: --card; }
.tooltip {
position: absolute;
position-anchor: --card;
position-area: bottom;
}
}O valor desse padrão não está em usar anchor positioning a qualquer custo. Está em poder adotar uma melhoria onde ela funciona sem transformar quem está fora da matriz de suporte em usuário de segunda classe. Para componentes essenciais, como checkout, autenticação e navegação principal, a degradação precisa ser uma decisão de produto, não um acidente de CSS.
Menos hacks permanentes
Há um efeito menos óbvio nas iniciativas Interop: elas tornam mais visível quando um workaround pode começar a ter data de aposentadoria. A base de código web acumula prefixed properties, polyfills, detectores de user agent e CSS defensivo porque esses recursos foram necessários em algum momento. Revisá-los quando o cenário melhora reduz manutenção, peso e incerteza.
Mas a palavra importante é revisar. O dashboard mostra progresso em testes, não o perfil dos usuários da sua aplicação. Antes de retirar um fallback, consulte a compatibilidade da feature exata, rode testes nos fluxos críticos e observe sua audiência. Compatibilidade é trabalho contínuo; o Interop 2026 só deixa esse trabalho um pouco menos solitário.