Interop 2027 se está decidiendo ahora: cómo rankeamos las propuestas del navegador desde nuestro propio stack
Unas 100 propuestas de Interop 2027 están en una votación pública mientras el equipo debe cerrar la selección antes del 10 de diciembre de 2026. Contamos el código de compatibilidad que nuestro sitio realmente envía — 0 polyfills, 0 bloqueos @supports, 1 IntersectionObserver, 4 listeners de scroll — y usamos tres filtros para elegir las seis propuestas que vale la pena rankear.
Interop 2027 se está decidiendo ahora: cómo rankeamos las propuestas del navegador desde nuestro propio stack
Las áreas focales de Interop 2027 se están eligiendo, en la práctica, este mes. Unas 100 propuestas presentadas entre el 3 y el 23 de septiembre de 2026 están en una votación pública, el equipo de Interop debe cerrar la selección antes del 10 de diciembre de 2026 y el alcance oficial no llega hasta el 4 de febrero de 2027. Para todo el que no sienta en ese equipo, el ranking es la única palanca que queda: entras con GitHub, eliges unas diez de la centena, y solo cuentan las señales positivas. La forma correcta de usarlo no es «¿qué función suena más linda?» sino «¿qué propuesta elimina trabajo de compatibilidad que ya estamos pagando?». Corrimos esa prueba contra nuestro propio código fuente el 13 de octubre de 2026: contamos los shims, las compuertas y los observadores que realmente enviamos, los cruzamos con las propuestas abiertas y seis pasaron nuestros filtros.
El calendario, tal como está en el documento del proceso
El proceso de selección de Interop 2027 es público, y las fechas importan más que la lista de funciones:
| Fecha | Qué pasa |
|---|---|
| 3–23 de septiembre de 2026 | Ventana de envío. Las áreas focales se presentan como issues en web-platform-tests/interop con la etiqueta focus-area-proposal. |
| Ahora hasta la selección | El segundo ranking público anual del equipo de Firefox: unas 100 propuestas, unas 10 elecciones por persona, requiere sesión de GitHub. |
| Antes del 10 de diciembre de 2026 | Selección terminada por el equipo de Interop. La consenso exige al menos dos organizaciones participantes a favor y ninguna en contra. |
| 4 de febrero de 2027 | Se publica el alcance de Interop 2027. |
| 11 de febrero de 2027 | Se lanza el dashboard, los autores reciben retroalimentación y se cierran los issues originales. |
Dos números dan contexto al proyecto. Interop 2026 marcaba Chrome 98, Edge 98, Firefox 96 y Safari 92 el 3 de septiembre de 2026 — el porcentaje de pruebas aprobadas en la suite compartida — así que los mecanismos funcionan. Y el ranking del año pasado recogió más de 1.900 respuestas, que Mozilla dice haber usado tanto para empujar propuestas dentro de Interop como para priorizar el desarrollo de funciones en Firefox. Esa es la parte que conviene tomar en serio: esta votación no es una encuesta, es insumo de un roadmap.
Qué dice nuestro codebase (y qué no)
web.dev publicó el 18 de septiembre de 2026 un prompt de agente de código para exactamente este trabajo: escanear el proyecto en busca de polyfills, librerías wrapper, bloques @supports y workarounds en JavaScript propio, cruzar lo que encuentres con las propuestas abiertas y ordenar el resultado por código eliminado. Corrimos la misma auditoría a mano contra nuestro sitio en Astro y Cloudflare Pages el 13 de octubre de 2026:
| Señal contada en nuestro propio código | Valor |
|---|---|
Polyfills en package.json | 0 |
Compuertas @supports en el código que enviamos | 0 (hay 38 coincidencias, todas dentro de los ejemplos de nuestros propios artículos) |
| Script inline en los 11 archivos de componentes y layouts que llevan uno | ~1.300 líneas |
IntersectionObserver en componentes que enviamos | 1 |
Listeners de scroll / resize en componentes que enviamos | 4 |
| Detecciones explícitas de características | 2 (requestIdleCallback en window) |
| Media queries nativas que usamos | 3 (prefers-reduced-motion dos veces, prefers-color-scheme una) |
Elementos <iframe> en el markup de producción | 1 (el frame noscript de Google Tag Manager) |
Archivos de imagen en public/images | 610 JPEG, 0 AVIF, 0 JPEG XL |
Cabecera Content-Security-Policy en el origen de producción | ninguna, verificada con curl el 13 de octubre de 2026 |
La primera línea de esa tabla es el hallazgo que cambió nuestro ranking: casi no nos queda capa de compatibilidad por eliminar. Hace diez años un sitio de agencia traía un bundle de polyfills y un muro de fallbacks @supports; el nuestro no trae ninguno de los dos. Así que un ranking construido solo sobre «¿cuánto código elimina esta propuesta?» saldría casi vacío para nosotros — lo que significa que, en un stack que ya vive en Baseline, los filtros útiles son los otros dos.
Tres filtros, aplicados en orden
- ¿Elimina código que enviamos hoy? Contable con la auditoría de arriba. Raro para nosotros, decisivo cuando se cumple.
- ¿Ya depuramos este mismo bug entre navegadores? Un hueco que ya pagamos una vez, en horas, en un proyecto de cliente.
- ¿Podemos medir la mejora para el usuario en nuestra propia telemetría o en pruebas con tecnologías de asistencia? Layout shift, LCP, INP o un lector de pantalla que deja de comportarse distinto en cada motor.
Lo que pasa dos de los tres filtros se rankea. Lo demás queda sin rankear, que en esta votación es la forma correcta de no decir nada.
Las seis que rankeamos, y la que descartamos
| Propuesta (issue de GitHub) | Por qué pasó los filtros | Veredicto |
|---|---|---|
| Responsive iframes (#1443) | Filtros 1 y 2. El 26 de septiembre leímos a nuestros lectores que mantuvieran su shim de postMessage porque frame-sizing es solo de Chromium. La propuesta cubre el lado que incrusta (frame-sizing), el opt-in del documento incrustado (<meta name="responsive-embedded-sizing">) y window.requestResize(), todo dentro de CSS Box Sizing Level 4. Su estado Baseline es Limited Availability con 20 votos de desarrolladores. | Rankear, primera opción |
| Pausar el media de un iframe cuando no es visible (#1468) | Filtros 1 y 3. Nosotros enviamos un solo frame de terceros, pero cada sitio de cliente que mantenemos lleva frames de chat, video o analítica, y un frame fuera de pantalla que sigue decodificando es CPU y batería que no podemos imputar en nuestros propios presupuestos de rendimiento. | Rankear |
| Renderizado progresivo de JPEG XL y AVIF (#1459) | Filtros 2 y 3. Medimos la transcodificación de JPEG XL en nuestro propio blog el 9 de octubre. La propuesta señala que el renderizado progresivo de JPEG XL ya funciona en Firefox y Chrome pero no en Safari, mientras el decode progresivo de AVIF es solo de Chrome tras las mejoras de avifenc — y el renderizado progresivo fue la razón número uno por la que los desarrolladores pedían JPEG XL. | Rankear |
| Trusted Types (#1465) | Filtros 2 y 3, con un asterisco honesto. Publicamos la guía completa de adopción de Trusted Types el 21 de agosto de 2026 y nuestro propio origen de producción sigue respondiendo sin cabecera Content-Security-Policy; Lighthouse registra la directiva ausente como un ítem de severidad Alta en nuestro propio reporte. Estamos rankeando la función que nosotros mismos todavía no terminamos de adoptar. | Rankear |
| Animaciones CSS disparadas por scroll | Filtros 1. Cuatro listeners de scroll y un IntersectionObserver siguen siendo cómo hacemos los efectos de aparición al desplazarnos. Sosteníamos en julio que las animaciones nativas vinculadas al scroll terminan con ese patrón, y los triggers por scroll son la mitad que falta. | Rankear |
JavaScript Temporal | Ninguno. Tenemos 11 llamadas a new Date(, todas leyendo fechas de las colecciones de contenido, sin aritmética de zonas horarias en ninguna parte. Temporal es una mejor API, pero no eliminaría nada de lo que enviamos, así que rankearla sería gusto y no evidencia. | Descartar |
Lo descartado es justamente el punto del ejercicio. Temporal aparece en casi todas las listas de «funciones que quiero» y a nosotros también nos gustaría — pero nuestro voto es un recurso escaso, y gastar uno de los diez en una librería que nuestro codebase no usa hace que los otros nueve signifiquen menos.
Por qué la auditoría con agente cayó en el momento equivocado
El prompt del 18 de septiembre termina con «presenta o vota propuestas antes del 23 de septiembre», y esa puerta ya cerró: las propuestas están dentro y la lista abierta ahora pertenece a las organizaciones que seleccionan. Lo que sigue abierto es el ranking, y necesita exactamente la misma evidencia. Un agente que lista tus polyfills, tus bloques @supports y tus workarounds basados en observadores no te está dando un backlog de refactor: te está dando la justificación para diez líneas rankeadas.
Si lo corres ahora, espera que la salida se ordene distinto a la nuestra. Un equipo que todavía envía un bundle de polyfills verá que el filtro 1 lo hace todo. Un equipo maduro con código en Baseline llegará a donde llegamos nosotros: pocas cosas por eliminar, varios bugs ya pagados y un puñado de propuestas donde la mejora se puede medir en el mismo dashboard que reportas al cliente.
Preguntas frecuentes
¿Qué es Interop 2027? Un proyecto anual de interoperabilidad dentro del repositorio web-platform-tests, con representantes de Apple, Google, Igalia, Microsoft y Mozilla. Los desarrolladores presentan propuestas como issues de GitHub, cada organización las selecciona y prioriza internamente y la lista final se adopta por consenso: al menos dos organizaciones a favor y ninguna en contra. El avance se mide con la suite compartida de Web Platform Tests.
¿Cuándo se anuncian las áreas focales? El envío corrió del 3 al 23 de septiembre de 2026; la selección debe cerrarse antes del 10 de diciembre de 2026; el alcance se publica el 4 de febrero de 2027 y el dashboard se lanza el 11 de febrero de 2027.
¿Cómo se rankea? Con sesión de GitHub en la página de ranking de Firefox, eliges unas 10 de las aproximadamente 100 y rankeas solo lo que te guste de verdad: lo que no rankeas se ignora, lo que rankeas cuenta como señal positiva y el ranking se guarda hasta que termine el proceso.
¿Un agente de código puede decirte qué propuestas te importan? Sí, para eso está el prompt de web.dev del 18 de septiembre: escanear polyfills, librerías wrapper, bloques @supports y workarounds en JS propio, cruzarlos con las propuestas abiertas y ordenar por código eliminado. Como la ventana de envío cerró el 23 de septiembre, usa esa salida para rankear y no para presentar.
Fuentes
- Submit your proposals for Interop 2027 — web.dev, 3 de septiembre de 2026
- Find features to support for Interop 2027 with your coding agent — web.dev, 18 de septiembre de 2026
- Interop 2027 proposal selection process — web-platform-tests/interop
- 2027 Web Platform Feature Ranking — web-standards.dev
- Responsive iframes — interop issue #1443
- Progressive image rendering for JPEG XL and AVIF — interop issue #1459
- Pausing iframe media when not visible — interop issue #1468
- Trusted Types — interop issue #1465
Lectura relacionada en mintec.co
- Chrome 154 se hace cargo del sizing de iframes: dónde adoptarlo
- Chrome 155 ya decodifica JPEG XL: lo medimos sobre nuestra propia biblioteca de 162 MB
- Trusted Types ya es Baseline: el freno que tu frontend necesita antes de innerHTML
sizes=autoya es Baseline: y nuestro propio blog no tiene ni srcset- Scroll-driven animations nativas en CSS: el fin de IntersectionObserver para los reveals
- Carga diferida nativa de video y audio:
loading='lazy'en todos los navegadores
Preguntas Frecuentes
¿Qué es Interop 2027?
Es el proyecto anual de interoperabilidad que se ejecuta dentro del repositorio web-platform-tests con representantes de Apple, Google, Igalia, Microsoft y Mozilla. Los desarrolladores presentan propuestas de áreas focales como issues de GitHub, cada organización las selecciona y prioriza internamente, y la lista final se adopta por consenso: al menos dos organizaciones participantes a favor y ninguna en contra. El avance se mide con la suite compartida de Web Platform Tests.
¿Cuándo se anuncian las áreas focales de Interop 2027?
El documento de selección fija tres fechas: el envío de propuestas corrió del 3 al 23 de septiembre de 2026, la selección debe terminarse antes del 10 de diciembre de 2026, el alcance de Interop 2027 se publica el 4 de febrero de 2027 y el dashboard se lanza el 11 de febrero de 2027.
¿Cómo se rankean las propuestas de Interop 2027?
Con sesión de GitHub en la página pública de ranking del equipo de Firefox eliges unas 10 de las aproximadamente 100 propuestas. Rankea solo las funciones que te gustan de verdad: todo lo que rankeas cuenta como señal positiva y lo que no rankeas se ignora. El ranking se guarda automáticamente y se puede editar hasta que el proceso termine; el año pasado se enviaron más de 1.900 rankings.
