Por qué el viewport era la pregunta equivocada

Entre 2013 y 2020, “element queries” fue la petición más repetida de la comunidad de CSS y la que más rotundamente rechazaron los implementadores. No era desidia ni falta de recursos: la propuesta ingenua contenía una dependencia circular que ningún motor puede resolver, y cualquier implementación honesta tenía que romper el círculo de alguna forma. Las container queries son la forma en que la especificación decidió romperlo, y por eso vienen con una restricción que parece arbitraria hasta que conoces el problema que evita.

La petición y su trampa

La petición era razonable: “quiero aplicar estilos a un elemento según el ancho de ese elemento”. Escrita en pseudocódigo sería algo así:

/* Esto NO existe y no puede existir */
.tarjeta (width < 400px) {
  .tarjeta { display: block; }
  .tarjeta img { inline-size: 100%; }
}

El problema aparece en cuanto los estilos aplicados pueden cambiar el ancho del propio elemento. Imagina una tarjeta con inline-size: fit-content cuyo ancho depende de su contenido. Si mide 380px, la condición se cumple, y la regla pone la imagen al 100% y apila el contenido, lo que hace que la tarjeta pase a medir 420px. Con 420px la condición deja de cumplirse, los estilos se retiran, la tarjeta vuelve a 380px, y la condición se cumple otra vez.

El navegador no oscilaría visualmente: se quedaría colgado. El cálculo de layout no converge, y un motor no puede entregar un frame hasta que converge. No hay heurística aceptable: limitar las iteraciones produce resultados no deterministas que dependen del orden de evaluación, y detectar el ciclo en el caso general es tan caro como resolverlo.

Esto no es un caso rebuscado. Cualquier elemento cuyo tamaño dependa de su contenido —que en CSS son casi todos, porque el tamaño intrínseco es el comportamiento por defecto— puede entrar en el bucle.

Por qué los polyfills no lo resolvían

Todas las librerías de element queries de aquella década funcionaban igual: medir con JavaScript, añadir una clase, dejar que el navegador recalculara. El bucle no desaparecía, simplemente pasaba de ser un problema del motor a ser un problema tuyo, con dos agravantes.

El primero, de corrección: la medida ocurre después del layout, así que el usuario ve un frame con el estilo equivocado antes de la corrección. En una carga de página eso es un salto visible, y en las métricas de estabilidad visual se paga.

El segundo, de terminación: si tus estilos cambiaban el tamaño medido, el bucle seguía existiendo, solo que ahora consumía un frame por vuelta en lugar de colgar el hilo. La página se quedaba parpadeando a 60 oscilaciones por segundo hasta que alguien tocaba el código.

ResizeObserver, estandarizado en 2020, formalizó el problema en vez de esconderlo. Su algoritmo procesa las notificaciones en profundidades crecientes del árbol y, si tras una pasada quedan cambios pendientes en elementos ya notificados, dispara un evento de error ResizeObserver loop limit exceeded y abandona el resto hasta el siguiente frame. Es decir: el estándar admite explícitamente que el bucle puede ocurrir y define cómo rendirse de forma controlada. Ese error, que mucha gente ha visto en sus registros sin saber qué significaba, es el fantasma de las element queries.

El compromiso

La solución de las container queries es directa y consiste en aceptar una restricción a cambio de la funcionalidad: para poder consultar el tamaño de un elemento, ese elemento debe declarar que su tamaño no depende de su contenido en el eje consultado. Eso es lo que hace container-type, y el mecanismo que lo garantiza es el containment, que veremos con detalle en la lección siguiente.

Con esa garantía, el bucle desaparece porque desaparece la realimentación: el motor calcula el tamaño del contenedor a partir de su propio contexto —lo que le dé su padre—, evalúa la condición, aplica los estilos y sabe con certeza que nada de lo que ocurra dentro puede cambiar el número que acaba de usar.

De esa restricción se derivan las dos características de las container queries que más desconciertan al principio y que son puras consecuencias lógicas, no decisiones de diseño arbitrarias. Que un elemento no pueda consultarse a sí mismo, porque los estilos que aplicaría afectan a su propio contenido. Y que container-type: size haga que un elemento sin altura declarada colapse a cero, porque le has dicho al motor que ignore su contenido al calcular la altura, y sin contenido y sin altura declarada no queda nada.

Lo que esto cambia en la arquitectura de componentes

El cambio profundo no es sintáctico. Hasta ahora, un componente CSS no podía ser una unidad autocontenida: para adaptarse necesitaba información —el ancho de la ventana— que era global, y por tanto tenía que coordinarse con todo lo demás. Un componente que se adapta al viewport no es reutilizable, es reutilizable en las condiciones en que fue diseñado.

Con la consulta de contenedor, el componente pasa a depender solo de lo que su padre le da, que es exactamente el mismo contrato que ya usas en cualquier sistema de componentes de JavaScript: recibes props, no lees variables globales. Un componente escrito así se puede colocar en una portada, en una barra lateral, en un modal y en una vista de impresión sin que su autor tuviera que conocer ninguno de esos sitios.

Ese es el motivo por el que esto se considera el cambio de layout más importante de la década, muy por encima de cualquier propiedad nueva: no añade una capacidad, elimina una dependencia global.