Durante años, “que se vea bien en todos los navegadores” fue una promesa tan habitual como imprecisa. La web moderna ofrece más capacidades nativas para animar, posicionar elementos, gestionar navegación y crear experiencias en tiempo real; pero que una función exista no significa que se comporte igual en cada navegador, versión o dispositivo.
Ese es el contexto de Interop 2026, una iniciativa en la que participan organizaciones vinculadas a los principales motores de navegador para mejorar la implementación consistente de funciones de la plataforma web. Entre sus focos aparecen Scroll Snap, animaciones ligadas al desplazamiento, View Transitions, WebRTC, WebTransport, la Navigation API y problemas de compatibilidad concretos, como la carga de módulos ECMAScript.
La compatibilidad no es un detalle de última hora: es una definición de producto sobre qué experiencia se le promete a cada persona usuaria.
Qué cambió: ya no alcanza con preguntar si una función “es compatible”
La respuesta corta a esa pregunta suele ocultar lo importante. Una función puede estar disponible en las versiones estables más recientes de los navegadores principales y, aun así, requerir una alternativa para equipos antiguos, navegadores integrados dentro de otras aplicaciones, tecnologías asistivas o casos de uso específicos.
MDN utiliza Baseline para resumir el estado de disponibilidad de funciones web. Es una señal útil para iniciar una decisión: “ampliamente disponible” indica una historia de soporte consistente; “recientemente disponible” señala que llegó a los navegadores principales, pero puede no alcanzar a versiones más viejas. Sin embargo, la propia documentación aclara que ese indicador no sustituye las pruebas de accesibilidad, rendimiento, seguridad, usabilidad o compatibilidad con dispositivos antiguos.
La novedad editorial de Interop 2026 no es que la web vuelva a ser incompatible por definición. Al contrario: muestra que los navegadores están coordinando esfuerzos sobre diferencias reales que afectan proyectos reales. La consecuencia práctica es clara: adoptar tecnología moderna exige decidir qué ocurre cuando esa tecnología no está disponible o no responde como se esperaba.
Las áreas de Interop 2026 que conviene mirar con criterio
La lista de áreas de foco no es una lista de tareas obligatorias para todos los sitios. Sirve para detectar dónde conviene evitar supuestos apresurados.
- Interacciones y movimiento: Scroll Snap, animaciones guiadas por scroll y View Transitions pueden mejorar la percepción de fluidez, pero el contenido y la navegación deben seguir funcionando sin depender de una animación.
- Interfaces complejas: la Navigation API, los diálogos y popovers, o los registros de componentes personalizados pueden ser relevantes en aplicaciones, paneles y sistemas con mucho estado.
- Comunicación en tiempo real: WebRTC y WebTransport importan más en videollamadas, colaboración, transmisión y software interactivo que en un sitio institucional simple.
- Problemas menos vistosos, pero decisivos: Interop incluye carga de módulos, orden de eventos de scroll y animación, y propiedades CSS históricamente implementadas con prefijos. Son detalles capaces de romper partes de una interfaz aunque el diseño parezca correcto.
Según WebKit, el programa contempla veinte áreas y se mide con Web Platform Tests, pruebas automatizadas que evalúan la conformidad con los estándares. Es una buena noticia para la plataforma, pero no convierte automáticamente una función en apropiada para cualquier público.
Cómo decidir si adoptar una función moderna
Antes de convertir una novedad del navegador en una dependencia central, conviene responder estas preguntas en orden:
- ¿Qué problema concreto resuelve?
Si solo agrega efecto visual, no debería impedir leer, comprar, enviar un formulario o navegar. - ¿Quiénes usan el sitio y desde qué contexto?
No es lo mismo una herramienta interna con equipos actualizados que un portal público con audiencia móvil amplia y desconocida. - ¿Cuál es el mínimo funcional sin esa capacidad?
Definí primero el recorrido sin la función avanzada; después agregá la mejora para los navegadores que la soporten correctamente. - ¿Qué evidencia de soporte necesitás?
Revisá la documentación de la función, el estado de Baseline y los navegadores acordados para el proyecto. No uses una sola demostración como evidencia suficiente. - ¿Cómo se probará?
Asigná responsables, dispositivos o servicios de prueba, recorridos críticos y criterios de aceptación antes de desarrollar.
El enfoque más sólido: mejora progresiva, no resignación
La mejora progresiva no significa ofrecer una versión descuidada a parte de la audiencia. Significa construir primero una experiencia clara y funcional con las capacidades ampliamente disponibles, y sumar mejoras cuando el entorno las permite.
Por ejemplo, una transición entre páginas puede aportar continuidad visual, pero el enlace debe seguir llevando al destino aunque la transición no se ejecute. Un carrusel con ajuste de desplazamiento puede facilitar la exploración, pero sus elementos deben poder recorrerse con teclado, táctil y controles visibles. Una interfaz de tiempo real necesita informar de forma comprensible qué sucede si el canal avanzado no está disponible.
MDN explica en su introducción a las pruebas entre navegadores que no es posible dar soporte a todos los navegadores y dispositivos existentes; por eso hay que acordar el rango a cubrir. Esa conversación debe ocurrir con quien define el negocio, no quedar escondida como una decisión técnica posterior.
Una matriz mínima para incluir en el alcance
Para evitar interpretaciones distintas, documentá una matriz breve antes del desarrollo o de una mejora relevante:
- Navegadores y sistemas operativos que se probarán.
- Versiones mínimas o criterio de actualización admitido.
- Dispositivos prioritarios: móvil, escritorio, tablet o terminales de uso interno.
- Recorridos críticos: inicio, navegación, búsqueda, formulario, registro, compra o acceso a un área privada.
- Funciones con alternativa prevista y descripción de esa alternativa.
- Problemas conocidos aceptados, si existieran, y su impacto real.
- Momento de prueba: prototipo, ambiente de pruebas, prepublicación y revisión posterior al lanzamiento.
Este documento no necesita ser extenso. Su valor está en reemplazar una expectativa abierta por criterios que se puedan comprobar.
Conclusión: Interop es una señal para planificar mejor
Interop 2026 confirma que la plataforma web sigue ganando capacidades y que los navegadores trabajan sobre diferencias que históricamente han costado tiempo a equipos y usuarios. Para un proyecto, la lección no es frenar toda adopción tecnológica: es evitar que una función nueva defina por sí sola la experiencia principal.
La acción más útil es concreta: elegí los navegadores y recorridos que importan para tu audiencia, definí la experiencia mínima que debe funcionar en todos ellos y probá las mejoras modernas sobre esa base. Si necesitás llevar ese criterio a un proyecto nuevo o a una evolución de tu presencia digital, conocé nuestros sitios web y planes web.
