Chrome 154 se hace cargo del sizing de iframes y la semántica de carruseles: dónde adoptarlo
Chrome 154, estable desde el 22 de septiembre de 2026, agrega frame-sizing para que un iframe igualе la altura del documento que lo contiene sin un shim de postMessage, y modos links y tabs que dan a los scroll markers de CSS roles WAI-ARIA reales. Hoy son exclusivos de Chromium, y el propio Google advierte que el sizing responsivo de iframes puede generar desplazamientos que castigan Core Web Vitals.
Chrome 154 se hace cargo del sizing de iframes y la semántica de carruseles: dónde adoptarlo
Sí: desde Chrome 154, estable el 22 de septiembre de 2026, un <iframe> puede redimensionarse solo con una propiedad CSS según la altura del documento que contiene, y un carrusel en CSS puede declarar semántica de tablist, tab y tabpanel sin escribir una línea de ARIA. Ninguna de las dos funciones es Baseline: frame-sizing y los nuevos modos de scroll-marker-group son exclusivas de Chromium por ahora, y la documentación de Google advierte que el sizing responsivo de iframes puede desplazar contenido y dañar los Core Web Vitals. La jugada correcta es adopción con feature detection: conserva tu shim de postMessage como fallback, activa el nuevo patrón donde controlas ambos documentos y deja tranquilo todo lo que se renderiza en el primer viewport hasta medirlo.
Lo que realmente llegó en Chrome 154
Dos funciones de esta versión retiran código que los equipos de front-end mantienen hace una década.
Iframes con sizing responsivo. La página que incrusta define la propiedad:
.embed {
width: 100%;
frame-sizing: content-height;
}
El documento embebido hace opt-in desde su propio <head>:
<meta name="responsive-embedded-sizing" content="allow-origins=*">
Ese es todo el mecanismo. La caja del iframe se deriva del tamaño intrínseco del documento embebido, así que un hilo de comentarios, un formulario o un artículo largo dentro del frame ya no necesita scrollbar anidado. Los valores aceptados son auto, content-width, content-height, content-inline-size y content-block-size; para crecer en vertical con escritura horizontal conviene content-height o content-block-size, y sigue siendo válido combinarlo con restricciones como max-height: 80vh.
Modos de scroll markers en CSS. scroll-marker-group ya generaba los pseudoelementos ::scroll-marker-group y ::scroll-marker que convierten una lista con scroll-snap en un carrusel con puntos. Chrome 154 agrega una segunda palabra clave que decide qué significan esos puntos:
/* modo links (default): activar un marker lleva el foco al target */ scroll-marker-group: after links; /* modo tabs: el group es tablist, los markers son tabs, los targets son tabpanels */ scroll-marker-group: before tabs;
En modo tabs, el grupo generado recibe el rol tablist, cada marker el rol tab y los elementos de origen el rol tabpanel: el patrón tabs de WAI-ARIA, producido por el navegador a partir de CSS que ibas a escribir igual.
El shim que puedes retirar y el que no
La historia del iframe es un reemplazo directo de un patrón que nunca debió necesitar postMessage.
Resize manual con postMessage | frame-sizing en Chrome 154 | |
|---|---|---|
| Quién escribe el código | Ambos documentos | CSS en el padre + un meta tag en el hijo |
| Contenido dinámico | El hijo mide y reenvía en cada cambio | El hijo llama a window.requestResize() tras cambiar el DOM |
| Cross-origin | Funciona si ambos lo implementan | Funciona, condicionado por allow-origins |
| Modo de falla | Bucles de resize, mensajes perdidos, altura vieja | No soportado → la propiedad se ignora y queda la altura fija |
| Soporte de navegador | Todos | Solo Chromium 154+ hoy |
| Superficie de seguridad | Message handlers que tienes que validar | Lista de orígenes al lado de CSP frame-ancestors |
La última fila importa más de lo que parece. frame-ancestors responde "quién puede embeber este documento"; allow-origins responde "quién puede redimensionarme". Son controles complementarios, y publicar allow-origins=* en una página que revela información sensible de layout es el mismo error que un frame-ancestors demasiado amplio. Para un widget de terceros, restringe la lista a los orígenes que la necesitan.
Dos detalles de implementación muerden en la práctica. El meta tag no se puede inyectar después de que el documento embebido cargó: tiene que estar en el HTML ya parseado, lo que significa que el opt-in lo decide quien publica el documento embebido, no la página que lo incrusta. Y el navegador no observa continuamente el layout dentro del frame: cuando cambia el contenido (más comentarios, un panel expandido), el documento embebido debe llamar a window.requestResize() después de los cambios y antes del layout. Google recomienda exactamente ese orden para evitar bucles donde una altura nueva cambia el viewport, eso cambia el contenido y eso vuelve a cambiar la altura.
La trampa de CLS
Aquí la función se gana su etiqueta de advertencia. La documentación de Google lo dice sin rodeos: los iframes responsivos pueden desplazar contenido cuando el documento embebido carga después del anfitrión, y eso puede dañar los Core Web Vitals cuando el iframe está en el primer viewport.
La mecánica es ineludible. El padre pinta con una altura provisoria, el documento hijo llega e informa un tamaño intrínseco mayor, el padre rehace el layout — y todo lo que estaba debajo del iframe se mueve. Un desplazamiento provocado por interacción queda fuera del CLS durante los primeros 500 ms, pero un embed que resuelve un segundo después del paint se cuenta completo, y se sigue contando cada vez que el frame crece.
Es el mismo modo de falla que explicamos en el desglose de overflow-anchor: la métrica y la experiencia de lectura no son la misma medida, y un layout que se siente estable puede puntuar mal.
Dónde adoptarlo y dónde esperar
| Tipo de embed | Recomendación | Por qué |
|---|---|---|
| Comentarios, formularios y widgets largos below the fold | Adoptar ya, con feature detection | El shift ocurre fuera del primer viewport; baja la exposición de LCP |
| Contenido same-origin que controlas (docs, TOC, changelog) | Adoptar con espacio reservado | También controlas el meta tag y el requestResize() |
| Embeds above the fold, media hero, burbujas de chat | Esperar | Los shifts en el primer viewport caen directo en el CLS |
| Widget de terceros cuyo vendor no shippeó el meta | Conservar el shim | Tu página no puede hacer opt-in en su nombre |
| Video o media con ratio fijo | No usar | La altura debe venir del aspect-ratio, no del flujo de contenido |
Lánzalo detrás de una feature query para que el fallback sobreviva:
.widget {
width: 100%;
height: 500px;
}
@supports (frame-sizing: content-height) {
.widget {
height: auto;
max-height: 80vh;
frame-sizing: content-height;
}
}
Carruseles: el ARIA que ahora escribe el navegador
La segunda función continúa un argumento que este blog viene sosteniendo desde cuando pedimos HTML nativo por encima de ARIA: la semántica le corresponde a la plataforma y el ARIA escrito a mano es una deuda de mantenimiento. Chrome 154 extiende esa lógica a los carruseles, el widget más mal construido de la web.
Elegir entre los dos modos es una decisión semántica, no de estilos:
- Modo
links(default) se comporta como un grupo de links: activar un marker mueve el foco al target. Úsalo para paginar entre secciones de contenido. - Modo
tabsasigna el patrón tabs completo:tablisten el grupo,taben cada marker,tabpanelen el contenido, con el orden de foco y el teclado que espera la tecnología asistiva. Úsalo solo cuando el contenido realmente sea un conjunto de paneles.
Dos advertencias. El modo tabs saca los paneles no seleccionados de la experiencia activa de accesibilidad, así que está mal para un carrusel de links independientes: mal aplicado, oculta contenido a quienes usan lectores de pantalla en lugar de ayudarles. Y ninguno de los dos modos es Baseline: MDN lista scroll-marker-group como disponibilidad limitada y experimental, con Firefox y Safari aún en progreso. Tu marcado accesible de carrusel se queda como fallback; los marcadores en CSS son una ruta de upgrade, todavía no un reemplazo.
Qué implica para tu proceso de compatibilidad
Desde hace poco todos los motores principales lanzan versión cada dos semanas y Chrome 155 ya está programado para el 6 de octubre. Justo por esa cadencia las matrices por número de versión dejaron de ser útiles: una función que hoy es exclusiva de Chromium puede ser Baseline en tres versiones, o callarse durante dos años.
Entonces el proceso es el entregable, no la función:
- Detecta por feature, nunca por versión.
@supports (frame-sizing: content-height)y un chequeo de"requestResize" in windowson las únicas pruebas que importan. - Conserva el camino viejo hasta Baseline, no hasta que se sienta viejo. Las dos funciones nuevas degradan siendo ignoradas: un iframe con altura fija y un contenedor de scroll normal siguen funcionando.
- Mide el embed, no el promedio de la página. Separa los layout shifts atribuibles a iframes: una página que aprueba en promedio puede tener un widget mal comportado.
- Hazle la pregunta correcta a los vendors. Para embeds de terceros, "¿shippean
<meta name=\"responsive-embedded-sizing\">?" reemplaza a "¿tienen un script de resize?".
Adopta el patrón donde controlas ambos lados del frame, reserva espacio antes de activarlo y deja el ARIA que ya escribiste hasta que el resto de los motores lo alcancen.
Preguntas Frecuentes
¿Qué es frame-sizing en CSS?
Es una propiedad CSS que Chrome 154 aplica al <iframe> en la página que lo incrusta. Con content-height (o content-inline-size / content-block-size), la caja del iframe se deriva del tamaño intrínseco del documento embebido, así crece con su contenido en lugar de mostrar un scrollbar interno. El documento embebido debe optar con un elemento <meta name="responsive-embedded-sizing">.
¿frame-sizing afecta los Core Web Vitals?
Puede. La documentación de Google advierte que los iframes responsivos pueden desplazar contenido cuando el documento embebido carga después del documento anfitrión, lo que castiga Core Web Vitals si el iframe está en el primer viewport. Reserva espacio con min-height o aspect-ratio, lánzalo primero below the fold y mide los layout shifts antes de extenderlo.
¿frame-sizing funciona en Firefox y Safari?
No. Con Chrome 154 la propiedad es exclusiva de Chromium: caniuse la marca como no soportada en Firefox 156 y Safari 27. Usa @supports (frame-sizing: content-height) para conservar tu código actual de resize por postMessage como fallback mientras se expande el soporte.
