Apple, Google, Microsoft, Mozilla e Igalia acordaron 20 áreas para Interop 2026 y continúan un esfuerzo de cinco años por mejorar consistencia entre navegadores. Quince áreas son nuevas y cinco continúan desde 2025. El progreso se mide con Web Platform Tests automatizados y un dashboard público.
La lista incluye anchor positioning, contrast-color(), container style queries, view transitions entre documentos y animaciones guiadas por scroll. Pueden sustituir categorías de JavaScript y trabajo específico cuando las implementaciones convergen. Las timelines nativas también mueven trabajo fuera del main thread y evitan scripts ligados al layout.
La ganancia operativa es menor bundle, menos polyfills y menos QA manual. No autoriza borrar todos los fallbacks el día del anuncio. Interop mide conducta probada entre vendors; un producto sirve una mezcla concreta de navegadores, accesibilidad y dispositivos antiguos.
El dashboard mide vendors, no tu tráfico
El score de Interop 2026 responde si los engines pasan los Web Platform Tests de esa área. Chrome, Firefox, Safari y Edge entran en la misma hoja. El número público sirve porque deja de ser un comunicado: se ve, área por área, lo que aún falla.
No describe la base que atiende tu aplicación. WebView corporativo, Safari de iPhone antiguo, tablet compartida y la cola lenta de las sesiones quedan fuera de esa media. Un producto con 8% de tráfico en un engine atrasado sigue pagando el fallback. Si ese grupo concentra un flujo de pago o un canal regulado, el costo es mayor de lo que sugiere el dashboard.
La lista de 2026 tampoco es un único bloque de CSS. Hay posicionamiento, transiciones, IndexedDB, Navigation API, WebTransport, WebRTC y JSPI para Wasm. Tratar el anuncio como "el CSS ya está estandarizado" mezcla superficies con ritmos distintos. Anchor positioning, view transitions, scroll snap, WebRTC y CSS zoom volvieron de 2025 porque el recorte anterior aún dejaba tests en rojo. Un carryover es trabajo pendiente.
Antes de retirar una biblioteca, cruza dos fuentes. La primera es el dashboard del área que pretenden usar. La segunda es la telemetría de engine en las sesiones que importan, incluida la cola de la distribución. Sin ese cruce, el equipo cambia un polyfill estable por un bug que solo aparece en el dispositivo del cliente.
El polyfill sale cuando el público real ya pasó
Floating UI, Popper y los paquetes de animación ligada al scroll existen porque colocar overlays y atar timelines al scroll no eran fiables entre engines. Cuando lo nativo cubre el caso, el paquete deja de pagar su propio costo: actualización, bundle y conflicto con el layout.
La retirada es una decisión de producto, no un reflejo del post de los vendors. Define el recorte mínimo de engine, mide la parte de sesiones por debajo y solo entonces saca el JavaScript del camino crítico. Progressive enhancement sigue siendo el mecanismo más barato: el CSS nativo toma el caso feliz, el script permanece para quien aún lo necesita. La detección en runtime vale más que una tabla de user-agent congelada en el backlog.
contrast-color() ilustra el límite de la feature aislada. Devuelve negro o blanco con mejor contraste respecto al color informado. Safari y Firefox ya tenían soporte; Interop presiona al resto. La función no calcula contraste de texto sobre imagen, no sustituye una auditoría y no elige paleta de marca. Quien lo trate como el cierre del trabajo de accesibilidad reabre el tema en el siguiente review.
Las animaciones guiadas por scroll en el compositor sí sacan trabajo del main thread cuando la implementación es correcta. El efecto visual, la preferencia por menos movimiento y el comportamiento en overflow anidado siguen siendo tests de producto. Quitar decenas de kilobytes de JS solo se justifica si el mismo flujo sigue usable en la mezcla que ustedes soportan.
El QA cambia de superficie; no desaparece
Una suite visual pesada en cuatro browsers suele existir porque el mismo CSS producía cuatro layouts. Con menos divergencia de espaciado, el screenshot en todos los engines pierde valor para algunos componentes. Gana valor la interacción que la foto no ve: popover="hint" que no cierra el menú, closedby en el dialog, view transition entre documentos, scroll snap en un carrusel con teclado.
Redistribuyan el tiempo. Menos regresión de padding en un botón. Más flujo con teclado, lector de pantalla y reducción de movimiento. Interop mantiene investigaciones de accesibilidad y de test mobile fuera del score de las 20 áreas. El árbol de accesibilidad y el viewport dinámico aún no tienen la misma presión institucional que las features puntuadas. Eso debería aparecer en el plan de QA, no solo en el changelog de CSS.
Yo dejaría de abrir el mismo formulario estático en cuatro ventanas. Mantendría Safari en los flujos que usan API nueva de overlay, navegación y media. El costo de un bug ahí es un ticket de soporte, no un píxel desplazado en Figma.
Migren por superficie, con detección y rollback
Un orden práctico reduce el riesgo de "borramos el polyfill el lunes". Inventarien los paquetes que existen solo para cubrir las áreas de 2026. Clasifiquen cada uno por bytes en el bundle y por daño si lo nativo falla. Migren primero lo que tiene detección simple y fallback barato: style queries de tema, contrast-color() en un botón de marca. Dejen para el final overlay, foco y navegación, donde un error rompe el camino principal.
Cada migración necesita tres evidencias en el pipeline: el recorte de engine de la telemetría, un test del flujo con la feature nativa y un camino de vuelta (flag o paquete aún instalado) si el percentil lento falla. Sin la tercera, el equipo descubre el agujero en producción y recoloca la biblioteca con prisa.
Advanced attr(), getAllRecords() en IndexedDB y WebTransport pueden ser irrelevantes para tu producto. No gasten ciclo en ellos solo porque entran en los 20. Interop alinea vendors. La decisión local sigue siendo qué puede usar ya el público, qué aún necesita JS y qué el QA deja de fotografiar para pasar a ejercitar.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
