Los container queries cambian una regla que llevaba quince años fija en el desarrollo web: ya no hace falta que un componente conozca el ancho de la pantalla para decidir cómo se ve, le basta con conocer el ancho de la caja que lo contiene. Antes, un mismo bloque —una ficha de producto, un panel de precios, una tarjeta de equipo— se comportaba igual estuviera donde estuviera en la página, porque las media queries solo miran el viewport. Si trabajas en un equipo técnico que mantiene una web con muchas plantillas, o coordinas un rediseño desde marketing, esto cambia cuántas líneas de CSS hacen falta para que todo encaje.
Un container query es una regla CSS que aplica estilos a un elemento según el tamaño de su contenedor, no del navegador. Es un estándar del W3C ya soportado de forma nativa en Chrome, Firefox y Safari desde 2022 y 2023, sin necesidad de JavaScript ni librerías externas.
El cambio que traen los container queries
Hasta hace pocos años, adaptar un diseño significaba escribir una media query por cada anchura de pantalla y repetirla en cada plantilla que usara ese componente. El resultado, en webs con varias plantillas —ficha de producto, listado, sidebar, footer—, eran hojas de estilo con decenas de reglas casi idénticas, cada una atada a un breakpoint del navegador. Un container query, según documenta Mozilla, aplica el estilo según el ancho real de la caja donde vive el componente, esté esa caja en una columna de 300 píxeles o en el ancho completo de la página. Chrome y Edge lo soportan desde la versión 105, Firefox desde la 110 y Safari desde la 16: en la práctica, cualquier visitante con el navegador actualizado en los últimos tres años lo renderiza sin fallback. Para un equipo que gestiona una web corporativa con varias plantillas, la diferencia se nota en menos código que mantener y menos casos donde un componente se rompe al moverlo de sitio.
Consultas de contenedor frente a media queries
La media query sigue siendo necesaria para decisiones de página completa: cuántas columnas tiene el listado, si el menú se pliega, si la barra lateral desaparece. Las consultas de contenedor no sustituyen eso: resuelven el problema que las media queries no pueden, que es lo que le pasa a un componente concreto cuando cambia de contexto. Una ficha de producto que mide 320 píxeles en el catálogo y 220 en un carrusel de recomendados necesitaba, antes, dos clases distintas mantenidas a mano. Con la propiedad container-type activada en el elemento padre, el mismo componente decide su tipografía y su distribución mirando solo su propio ancho, sin que la plantilla que lo envuelve tenga que saber nada de eso.
Una consulta de contenedor no depende del tamaño de la pantalla: depende del espacio real que el diseño le deja a ese componente en cada lugar donde se usa.
Esa independencia permite reutilizar un mismo bloque en un panel interno, en una landing y en el cuerpo de un artículo sin triplicar el CSS ni depender de JavaScript para medir contenedores, que era el único recurso disponible antes de 2022.
Sectores donde el ahorro se nota más
El beneficio no es solo técnico: se traduce en menos horas de desarrollo y menos incidencias al publicar, sobre todo en negocios cuya web repite el mismo bloque en decenas de páginas con anchos de columna muy distintos:
- Ecommerce con catálogos grandes y varios formatos de listado.
- Fabricantes con fichas técnicas por línea de producto.
- Inmobiliarias con listados de propiedades en columnas de distinto ancho.
Catálogos de producto en ecommerce
En una tienda online, la misma ficha de producto aparece en el grid principal, en el carrusel de recomendados y en el buscador con autocompletado, cada uno con un ancho distinto. Sin container queries, cada aparición necesitaba su propia variante de CSS. Con una sola definición del componente, el título pasa a dos líneas y el precio cambia de posición cuando el contenedor mide menos de 240 píxeles, sin tocar la plantilla del carrusel. Menos CSS específico por contexto también aligera la hoja de estilos, algo que pesa en cuánto vendes, como recoge nuestro análisis sobre la velocidad de carga web. Un equipo que gestiona su tienda online con varios integradores de plantillas nota la diferencia la primera vez que cambia el diseño del carrusel sin romper el grid.
Fichas técnicas en el sector industrial
Un proveedor industrial suele publicar fichas técnicas que se insertan tanto en la página de producto como en un comparador lateral de categoría. El contenedor lateral mide la mitad que la página de producto, así que el mismo bloque de características necesita apilarse en una columna en un sitio y repartirse en dos en el otro. Antes eso obligaba a mantener dos plantillas del mismo contenido; con una consulta de contenedor, el bloque decide su propia disposición según el hueco disponible, sin duplicar el componente por cada microsite del grupo.
Trabajo real para adaptar componentes existentes
Migrar un componente ya construido no exige reescribir la plantilla desde cero, pero sí revisar cómo está montado el CSS actual. El punto de partida es declarar el contenedor con la propiedad container-type en el elemento envolvente y darle un nombre con container-name si conviven varios contenedores anidados, algo habitual en páginas con widgets superpuestos.
- Auditar qué componentes se repiten en más de un contexto de ancho distinto.
- Sustituir las clases de variante fijas por reglas @container ancladas a ese componente.
- Probar el resultado en los anchos de columna reales del sitio, no solo en los tamaños de pantalla habituales.
El trabajo se concentra en los componentes reutilizados, no en toda la web de golpe: empezar por la ficha de producto o el bloque de llamada a la acción, medir el resultado y extender el patrón después reduce el riesgo de un cambio grande sin retorno claro. Un equipo sin este perfil en plantilla suele apoyarse en una consultora de desarrollo para hacer esa auditoría inicial sin parar el ritmo de publicación.
Límites que aún tienen los container queries
Las consultas de tamaño, las que miden anchura o altura, funcionan de forma estable desde 2023 y son las que resuelven la mayoría de los casos anteriores. Las consultas de estilo, que aplican reglas según el valor de una propiedad personalizada del contenedor en lugar de su tamaño, van por detrás: Chrome las soporta desde la versión 111 y Safari desde la 18, pero Interop 2026 las sigue marcando como una de sus áreas de trabajo activo, con Firefox superando el 97% de las pruebas del proyecto a principios de año y margen de mejora en el resto.
Para un proyecto que decide hoy, la recomendación práctica es empezar por consultas de tamaño, que cubren fichas, tarjetas y paneles, y dejar las de estilo para cuando el soporte esté cerrado en los tres motores. El efecto en el rendimiento percibido es otro punto a vigilar: un contenedor mal dimensionado puede disparar recálculos de layout, el mismo tipo de coste que ya mide la métrica INP en la interacción del usuario.
Preguntas frecuentes sobre container queries
¿Los container queries sustituyen a las media queries?
No. Las media queries siguen decidiendo la estructura general de la página, como el número de columnas o si el menú se pliega. Los container queries resuelven un problema distinto: cómo se comporta un componente concreto según el espacio que tiene disponible en cada lugar donde se usa, sin depender del ancho total de la pantalla.
¿Necesito un framework de CSS para usar container queries?
No, es una propiedad nativa del CSS estándar y no depende de ningún framework. Basta con declarar container-type en el elemento contenedor y escribir la regla @container correspondiente; frameworks como Tailwind o Bootstrap ya incluyen utilidades para ello, pero no son necesarios para que funcione.
¿Qué pasa en los navegadores que no lo soportan?
Los navegadores desde 2022-2023 en adelante lo soportan de forma nativa, así que el porcentaje de visitas afectado es mínimo. En una versión antigua sin soporte, el componente conserva su estilo por defecto en lugar de adaptarse, sin romperse ni generar errores visibles.
Fuente: MDN Web Docs