Deja de Usar CSS Container Queries Como Media Queries — La Diferencia Real Que Nadie Te Explica

94% de Soporte, 41% de Adopción — ¿Qué Está Pasando?

¡Hola Devs! Fíjate en esto: CSS Container Queries ya tiene cerca del 94% de soporte en navegadores. Pero según la encuesta State of CSS, solo el 41.4% de los devs realmente las usa. Y eso que el 86% sabe que existen. Ese gap no es un problema de herramienta — es un problema de modelo mental.

El motivo es simple: a primera vista, @container se ve idéntico a @media. Misma sintaxis, mismo patrón (min-width: ...). Entonces el dev asume que funciona igual, copia sus hábitos de media query y termina con componentes que se rompen en sidebars, celdas de grid y cualquier contexto donde el viewport es un proxy inútil.

Este artículo va de arreglar ese modelo mental — no agregando container queries en todo, sino entendiendo qué pregunta hace cada tipo de query al navegador. Si quieres ver el argumento original, checa el material original de Smashing Magazine.

Media Queries Miran Hacia Afuera. Container Queries Miran Hacia Adentro.

Cuando escribes @media (min-width: 1024px), le preguntas una sola cosa al navegador: ¿qué tan ancha está la pantalla ahora? Eso es todo. El viewport es un proxy, y funciona hermoso — hasta que deja de funcionar.

/* Media query: dependiente del viewport */
@media (min-width: 1024px) {
  .card {
    display: flex;
  }
}

Pon ese .card en una celda de grid de 300px en un desktop de 1920px y la media query dispara igual. El card se vuelve display: flex con 300px de espacio y se deforma todo.

Las container queries hacen una pregunta distinta: ¿cuánto espacio inline tengo aquí, en este slot específico?

/* Container query: dependiente del componente */
.card-wrapper {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 450px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

Ahora el card responde al wrapper, no al viewport. Muévelo a una sidebar, un modal o un hero full-width — se adapta correctamente en cualquier contexto. ¡Vamos a darle! 🚀

Macro Layout vs. Micro Layout: El Modelo Mental Que Resuelve Todo

Deja de pensar en container queries como "media queries 2.0". Piénsalas como una capa distinta de diseño responsivo.

Un elemento no debería volverse "tamaño tablet" solo porque el viewport cruzó 768px. Debería cambiar de layout cuando él tenga espacio suficiente — sea en mobile o dentro de una sidebar en desktop. Hay más de 2,300 tamaños de viewport únicos en la web moderna. No puedes enumerarlos todos. Pero sí puedes definir qué significa "espacio suficiente" para un componente.

Tipografía Fluida, Bien Hecha

Unidades de viewport (vw) amarran el texto a la pantalla. Unidades de container (cqi, cqw, cqb) amarran el texto al componente.

/* Mal: escala con el viewport, se rompe en sidebars */
.card-title {
  font-size: clamp(100%, 1rem + 2vw, 24px);
}

/* Bien: escala con el container del componente */
.card-title {
  font-size: clamp(1rem, .5rem + 3cqi, 2rem);
}

El Truco del Flexbox Wrap

CSS no tiene pseudo-clase :wrapped. Pero puedes detectar el wrap del flex con container queries, dejando que los flex items se expandan cuando saltan de línea:

.flex-layout {
  display: flex;
  flex-wrap: wrap;
}

.flex-item {
  container-type: inline-size;
  flex: 1 1 390px; /* Crece para llenar, salta en 390px */
}

.card {
  display: flex;
  flex-direction: column;
  background: #f4f4f4;
}

/* Dispara cuando un item saltado se estira para llenar la fila */
@container (min-width: 600px) {
  .card {
    flex-direction: row;
    align-items: center;
    background: #e2f0d9;
  }
}

Cuando los items saltan, el flex-grow los estira, la container query detecta el cambio de tamaño y aplica los estilos — sin ResizeObserver. ¡Fíjate qué elegante queda! 🔥

Tres Trampas Que Rompen Implementaciones Reales

1. Un Container No Puede Consultarse a Sí Mismo

Este es el error #1. Necesitas un wrapper.

/* NO FUNCIONA — loop infinito */
.card {
  container-name: card;
  container-type: inline-size;
}
@container card (min-width: 400px) {
  .card { display: flex; }
}

/* FUNCIONA — el wrapper es el container */
.cards {
  container-name: cards;
  container-type: inline-size;
}
@container cards (min-width: 400px) {
  .card { display: flex; }
}

Las media queries no tienen ese problema — el viewport siempre está disponible. Las container queries exigen una relación padre-hijo explícita.

2. container-type: size Puede Colapsar Tu Layout

/* Colapsa a 0px de alto si no tiene altura explícita */
.hero-banner {
  container-type: size;
}

El navegador calcula las dimensiones del container sin mirar a los hijos. Sin height, min-height o aspect-ratio explícitos, se vuelve 0px. Usa inline-size por default, a menos que de verdad necesites queries de block-size.

3. Custom Properties No Son Consultables

:root { --breakpoint-lg: 1600px; }

/* NO FUNCIONA */
@container (min-width: var(--breakpoint-lg)) { /* ... */ }

Las custom properties cascadaean, y una container query que lee una podría, en teoría, mutarla — creando dependencia circular. Usa valores literales en container queries.

Cuándo Usar Cada Una

• Container queries: el componente aparece en múltiples contextos de layout (grid + sidebar + modal).
• Media queries: el componente es a nivel de página (nav principal, footer, shell de página).

Si estás construyendo un sistema más grande de UI resiliente y consciente del contexto, vale la pena combinar esto con pensamiento arquitectónico en la capa de infraestructura — por ejemplo, los principios de diseño detrás de la resiliencia de Azure IaaS aplican la misma lógica de "adaptarse al contexto" a nivel de plataforma.

La Conclusión

Las container queries no reemplazan a las media queries — son un segundo eje de responsividad. Las media queries se encargan del macro; las container queries del micro. Confundir las dos es la razón por la que tantas implementaciones se sienten frágiles.

El cambio mental es pequeño pero consecuente: deja de preguntar "¿qué tamaño tiene la pantalla?" y empieza a preguntar "¿cuánto espacio tiene realmente este componente?". Cuando eso haga clic, el código sale solo.

Limitaciones Que Vale Reconocer

• Las container queries aún requieren un wrapper extra en la mayoría de casos, lo que puede complicar markup simple.
• Las style queries (@container style(...)) siguen siendo experimentales y no deberían usarse en producción todavía.
• El debug de container queries en DevTools está mejorando, pero sigue siendo menos maduro que el de media queries.

Próximos Pasos

1. Audita tu librería de componentes buscando cualquier componente que se renderice en más de un contexto de layout. Esos son tus candidatos a container query.
2. Reemplaza tipografía fluida basada en vw por cqi dentro de esos componentes.
3. Mantén @media para preocupaciones a nivel de página — no te pases de la raya.

Si te interesa cómo principios de "adaptación al contexto" aparecen en sistemas de experimentación y medición, el framework de surrogate outcomes para A/B testing con LLMs es una lectura paralela que vale la pena.

Fuente: Stop Treating CSS Container Queries Like Traditional Media Queries