Tailwind 4.3: @container-size, container queries que también miden altura

Las container queries de Tailwind ya cubrían el caso más habitual desde hace versiones: que un componente reaccione al ancho del contenedor que lo envuelve, no al ancho del viewport global. Con @container en el padre y modificadores @sm, @md, @lg, @max-* en los hijos, un mismo card se adapta si vive en una sidebar estrecha o en una zona ancha del layout.

v4.3 añade una pieza que faltaba: @container-size, una variante de @container que mide ancho y alto del contenedor. La diferencia parece pequeña pero abre un caso que antes obligaba a recurrir a JavaScript o a CSS custom: componentes que tienen que adaptarse a restricciones verticales.

La diferencia frente a @container clásico

@container por defecto mide solo el ancho del contenedor (inline-size). Las unidades CSS asociadas (cqi, cqw) funcionan dentro de él. El alto, sin embargo, no se mide: aunque pongas cqh o cqb dentro, el navegador no tiene de dónde calcular el valor.

@container-size mide ambas dimensiones. A partir de ese momento, las unidades de block-size (cqb, cqh) sí se resuelven con un valor real.

<!-- @container clásico: solo mide ancho -->
<div class="@container">
  <div class="w-[50cqw]">
    <!-- 50% del ancho del contenedor: funciona -->
  </div>
</div>

<!-- @container-size: mide ancho Y alto -->
<div class="@container-size">
  <div class="h-[50cqb]">
    <!-- 50% del alto del contenedor: funciona también -->
  </div>
</div>

Igual que @container, también admite nombre para identificar contenedores anidados:

<div class="@container-size/sidebar">
  <div class="w-[100cqw] h-[75cqb]">
    <!-- ancho = 100% del contenedor sidebar
         alto = 75% del block-size del mismo contenedor -->
  </div>
</div>

¿Sustituye a @container?

No. Es complementario. Decidir entre uno y otro depende de qué necesitas medir:

Caso Usa Razón Componente responde al ancho disponible @container + @sm/@md/@lg Coste mínimo de medición. Es lo más común. Componente necesita altura proporcional al contenedor @container-size + unidades cqb/cqh Activa la medición vertical. Componente con layout que cambia según ancho y depende de altura @container-size + @sm + cqb Los modificadores @sm/@md siguen funcionando dentro de @container-size.

La regla práctica: usa @container por defecto, y sube a @container-size solo cuando necesites unidades de altura del contenedor. Medir ambas dimensiones tiene un coste mínimo de rendimiento pero existe, por lo que no merece la pena activarlo si no lo vas a usar.

Combinándolo con los modificadores que ya conoces

Todos los modificadores que documentamos en el artículo anterior siguen funcionando dentro de @container-size:

<div class="@container-size">
  <article class="grid grid-cols-1 @sm:grid-cols-2 @max-md:gap-2 h-[60cqb]">
    <!-- 1 columna por defecto;
         2 columnas cuando el contenedor pasa de 384px;
         gap pequeño solo si el contenedor está bajo 448px;
         alto siempre al 60% del block-size del contenedor -->
  </article>
</div>

Eso permite construir componentes verdaderamente autónomos: la regla de adaptación viaja con el componente, no con la página donde se inserta.

Caso típico donde encaja

Pieza de hero con imagen de fondo que debe llenar verticalmente una sección de altura variable (porque la sección se ajusta al contenido de la página, no al viewport). Antes de @container-size, fijar la imagen a un porcentaje del alto del contenedor requería medirlo con JavaScript o usar vh/vw (que miden viewport, no contenedor). Ahora:

<section class="@container-size min-h-[400px]">
  <img class="absolute inset-0 w-full h-[100cqb] object-cover" src="...">
  <div class="relative @md:p-12 p-6">
    <!-- contenido -->
  </div>
</section>

El mismo bloque sirve igual en una landing larga, en un slot ancho de un grid y en una columna estrecha. La imagen siempre cubre el 100% del alto real del contenedor, no del viewport.

Por qué importa la simetría con los modificadores anteriores

Lo que hace útil esta adición no es el modificador en sí, sino que encaja en el modelo mental que ya tenías. @container-size sigue siendo container query: misma sintaxis, mismos breakpoints @sm/@md/@lg, mismas variantes @max-*. Solo añade una dimensión más cuando la necesitas.

Para componentes complejos —cards de producto, sidebars adaptativas, módulos de dashboard que viven en grids dinámicos— acerca a Tailwind a paridad con lo que ya se podía hacer en CSS nativo con container queries, sin obligar a escribir CSS custom. Que la API se mantenga simétrica entre max-*, @max-* y @container-size es lo que hace que el sistema escale sin convertirse en una colección de excepciones.