Container queries en CSS: por qué los usamos mal y cómo corregirlo.

Hemos visto este patrón muchas veces: llega una herramienta nueva, se parece superficialmente a algo que ya conocemos y, sin querer, la usamos como si fuera lo mismo de siempre. Con los container queries de CSS está pasando exactamente eso.

Según la encuesta State of CSS, el 86% de las personas que desarrollan para la web conoce los container queries. Sin embargo, solo el 41,4% los utiliza realmente. Y de ese porcentaje, una parte significativa los está aplicando de forma incorrecta.

El problema no es técnico, es conceptual

La confusión tiene una causa clara: a primera vista, la sintaxis de un container query se parece mucho a la de una media query. Esa similitud visual lleva a asumir que funcionan igual y sirven para lo mismo. No es así.

Cuando escribimos una media query clásica, le estamos preguntando al navegador una sola cosa: ¿cómo de ancha es la ventana del navegador ahora mismo? El viewport actúa como proxy universal. Toda la lógica de adaptación parte de ese único dato.

Las media queries siempre han mirado hacia afuera. El viewport es una aproximación, no la realidad del componente.

Eso funcionó durante años porque era lo único que teníamos. Pero tiene un límite evidente: un mismo componente puede aparecer en una columna estrecha dentro de un panel lateral o ocupar el ancho completo de la página principal. En ambos casos, el viewport puede ser idéntico. La media query no distingue entre los dos contextos.

Qué hace realmente un container query

Un container query no mira el viewport. Mira el contenedor inmediato del componente. Le pregunta al elemento padre: ¿cuánto espacio tienes disponible para mí?

Esa diferencia cambia por completo la forma de pensar el diseño responsivo. En lugar de adaptar los estilos al tamaño de la pantalla, los adaptamos al espacio real que ocupa el componente en su contexto concreto.

Esto es especialmente útil en sistemas de diseño y componentes reutilizables. Una tarjeta de producto, un bloque de testimonios o un widget de estadísticas pueden comportarse de forma diferente según dónde estén colocados, sin necesidad de variantes adicionales ni clases modificadoras.

El error más habitual que hemos detectado

El fallo más común es usar container queries como si fueran media queries con otro nombre. Es decir, definir breakpoints globales basados en el tamaño de pantalla y simplemente trasladarlos al nuevo formato.

Si hacemos eso, no ganamos nada. El componente sigue dependiendo de un contexto externo que no controla. La potencia de los container queries está precisamente en lo contrario: en hacer que cada componente sea autónomo y capaz de adaptarse a su propio espacio disponible.

Kevin Powell lo señaló en SmashingConf Amsterdam 2026: la adopción de container queries ha sido decepcionante, y resulta paradójico porque durante años estuvo en la lista de deseos de muchos equipos de desarrollo.

Compatibilidad: ya no es excusa

Otro argumento que hemos escuchado para no adoptarlos es la compatibilidad con navegadores. Pero los datos actuales sitúan el soporte en torno al 94%. Es un nivel más que suficiente para usar container queries en producción en la mayoría de proyectos.

Vale la pena aclarar también que existen dos tipos de container queries. Los de tamaño, que responden a las dimensiones del contenedor, son los que tratamos aquí y están completamente disponibles. Los de estilo, que responden a los estilos calculados del contenedor, son experimentales y merecen un artículo aparte.

Cómo reorientar el enfoque

Recomendamos empezar con un cambio de pregunta. Antes de escribir ningún breakpoint, preguntarse: ¿a qué contexto debe adaptarse este componente? Si la respuesta es «al tamaño de pantalla», una media query puede ser la herramienta adecuada. Si la respuesta es «al espacio que le da su contenedor», los container queries son la elección correcta.

No se trata de sustituir un enfoque por otro. Se trata de usar cada herramienta para lo que fue diseñada. Las media queries siguen siendo válidas para cambios de layout a nivel de página. Los container queries son la respuesta correcta para componentes que necesitan ser verdaderamente portables.

El cambio conceptual es pequeño, pero las implicaciones en la arquitectura CSS de un proyecto son considerables. Componentes más autónomos, menos dependencias de contexto externo y sistemas de diseño más robustos.

Fuente original

Smashing Magazine: Stop Treating CSS Container Queries Like Traditional Media Queries