Container Queries: el cambio que hacía falta para dejar de diseñar componentes a ciegas
Durante años hicimos responsive con una idea medio limitada: mirar el viewport y reaccionar desde ahí.
Si la pantalla mide cierto ancho, cambias layout. Si baja de cierto punto, apilas columnas. Si sube, agrandas tipografía o le das más aire a los bloques. Todo eso sigue funcionando. El problema es que no siempre resuelve la pregunta correcta.
Muchas veces un componente no se rompe porque el viewport sea chico. Se rompe porque el espacio real que recibió dentro del layout no le alcanza.
Ahí entran las container queries.
No vienen a reemplazar todas las media queries. Vienen a resolver algo que llevaba rato haciendo falta: que un componente pueda reaccionar al tamaño de su propio contenedor y no solo al tamaño de la ventana.
El problema que teníamos antes
Piensa en una card reusable.
La usas en una home con grid de tres columnas, en un sidebar, en una landing con una sola columna, en un bloque destacado dentro de un CMS o en una sección de artículos relacionados.
El mismo componente puede vivir en anchos completamente distintos aunque el viewport sea el mismo.
Con media queries, ese componente solo sabe cómo está el viewport. No sabe cuánto espacio real le tocó dentro del layout. Entonces terminas haciendo una de estas dos cosas:
- lo diseñas para el caso más común y aceptas que falle en otros
- o metes variantes, clases extra y overrides por contexto hasta que el CSS empieza a oler raro
Ese era el hueco.
Qué son las container queries
Una container query permite que un componente cambie sus estilos según el tamaño de un contenedor padre marcado como contenedor.
La diferencia clave es esta:
- media query → responde al viewport
- container query → responde al espacio del contenedor
Eso cambia mucho cuando trabajas con sistemas de diseño, bloques reutilizables, layouts editoriales o componentes que aparecen en varios lugares.
Cuándo sí valen la pena
No hace falta meterlas en todo.
Tienen más sentido cuando:
- el mismo componente vive en varios contextos
- el layout cambia mucho dentro de la misma página
- trabajas con cards, módulos, widgets o bloques reusables
- no quieres depender de veinte clases utilitarias por contexto
- estás construyendo algo más orientado a componentes que a páginas fijas
Donde más brillan es en UI que realmente se reutiliza.
Un ejemplo básico
Supón una card de artículo con imagen, título y extracto.
Sin container queries, probablemente la dejas apilada en mobile y horizontal en desktop según el viewport. El detalle es que si esa misma card cae dentro de una columna angosta en desktop, igual te convendría que vuelva a su versión compacta aunque la pantalla completa sea grande.
Ahí está el punto.
Primero marcas el contenedor:
.posts-grid {
container-type: inline-size;
container-name: posts;
}Luego escribes la lógica del componente en función de ese contenedor:
.post-card {
display: grid;
gap: 16px;
}
@container posts (min-width: 480px) {
.post-card {
grid-template-columns: 160px 1fr;
align-items: start;
}
}Con eso la card deja de depender del ancho total del navegador. Ahora responde al espacio real disponible dentro de .posts-grid.
Eso la vuelve más reusable y más predecible.
Otro caso donde se nota mucho
En sidebars.
Hay componentes que en una zona principal se ven bien con imagen grande, tipografía amplia, más padding y layout horizontal.
Pero si ese mismo bloque cae en una barra lateral, ya no quieres la misma versión. Y no porque cambió el viewport, sino porque cambió el contexto real.
Con container queries puedes hacer algo así:
.widget-shell {
container-type: inline-size;
}
.widget {
padding: 16px;
border-radius: 18px;
}
@container (min-width: 420px) {
.widget {
padding: 24px;
}
.widget__title {
font-size: 1.25rem;
}
}Eso ya se siente mucho más natural que amarrar todo al ancho global de la ventana.
Lo que cambia a nivel mental
El ajuste importante es este: dejas de pensar solo en páginas y empiezas a pensar más en componentes con contexto propio.
Con media queries, el razonamiento típico era: “cuando la pantalla mida X, haz Y”.
Con container queries, el razonamiento se parece más a esto: “cuando este bloque tenga suficiente espacio, compórtate así”.
Para diseño de componentes eso está mucho mejor.
No vienen a matar las media queries
Las media queries siguen sirviendo para cosas globales:
- navegación principal
- estructura general de página
- cambios grandes de layout
- ajustes por viewport
prefers-reduced-motion- dark mode
- orientación
Container queries no reemplazan eso. Lo que hacen es cubrir una capa que antes quedaba medio parchada: la adaptación local del componente.
La combinación buena no es “una u otra”. Es usar cada una donde tiene sentido.
Qué necesitas para usarlas
La base más común es esta:
.card-wrapper {
container-type: inline-size;
}Y luego:
@container (min-width: 36rem) {
.card {
grid-template-columns: 120px 1fr;
}
}Lo más práctico para empezar es container-type: inline-size, porque evalúa el ancho disponible, que suele ser lo que más importa en responsive.
Un detalle importante
No todo elemento debería convertirse en contenedor solo porque sí.
Si empiezas a declarar contenedores por todas partes sin criterio, luego cuesta más entender quién está gobernando qué. Conviene marcarlos donde realmente exista una razón de layout o de reutilización.
Una regla práctica:
- contenedor en shells, wrappers o zonas de composición
- query en componentes que de verdad cambian según espacio disponible
Dónde las usaría hoy
Sí las usaría en:
- cards de artículos
- grids de productos
- bloques editoriales
- módulos de dashboard
- widgets
- sidebars
- componentes de design system
- módulos en CMS donde el editor los puede colocar en distintos anchos
No me apresuraría tanto en páginas estáticas simples, sitios chicos con una sola maqueta o proyectos donde el componente casi nunca cambia de contexto.
El beneficio real
Lo mejor de container queries no es que sean la novedad de CSS. Lo mejor es que te ayudan a dejar de forzar componentes con reglas pensadas para la página completa.
Eso se nota cuando un proyecto crece.
Mientras más reusable sea tu UI, más sentido tienen. Y mientras más dependas de bloques que viajan entre layouts distintos, más rápido te topas con el límite de las media queries tradicionales.
Container queries no hacen magia. Pero sí quitan una fricción bastante vieja del responsive.
En conclusión
Si trabajas con componentes reusables, vale la pena aprender container queries ya.
No porque las media queries hayan dejado de servir, sino porque había una parte del problema responsive que seguíamos resolviendo con parches. Cuando un componente necesita responder a su propio espacio y no al viewport entero, container queries encajan mucho mejor.
Lo más sensato es empezar con uno o dos componentes claros: una card, un widget o un bloque editorial. Ahí se entiende rápido si te simplifican el CSS o si todavía no las necesitas tanto.