Container Queries y @scope: El nuevo CSS que cambió cómo construimos componentes en 2026

Hay una conversación que tuvimos varias veces este año con clientes que están rediseñando su sitio: "¿Seguimos usando media queries como siempre, o es momento de migrar a container queries?"

La respuesta corta es: depende. Pero en 2026, las container queries ya no son una promesa futura. Con más del 93% de soporte global en navegadores — Chrome, Firefox, Safari y Edge — alcanzaron madurez suficiente para producción. Y trajeron consigo una pregunta más profunda: ¿cómo deberíamos pensar el diseño responsive cuando los componentes se adaptan a su contenedor, no a la pantalla?

En nuestro último proyecto migrando el sistema de diseño de una plataforma educativa — 47 componentes reutilizables, 8 breakpoints definidos en media queries, y un equipo de 6 desarrolladores — reemplazamos media queries por container queries en el 70% de los casos. Este artículo documenta lo que aprendimos: las métricas, las sorpresas, y un framework para decidir cuándo apply cada técnica.

El problema que resuelven las container queries

Las media queries fueron una revolución cuando aparecieron. Por primera vez podíamos escribir un CSS que respondiera al tamaño de la pantalla. Pero tienen una limitación fundamental: solo conocen el viewport.

Eso significa que un componente como una tarjeta de producto se ve idéntico en un sidebar de 300px y en una grid de 1200px — a menos que uses trucos como clases condicionales, estilos inline desde JavaScript, o grids con tamaños de columna fijos. Todo eso agrega complejidad y, a menudo, JavaScript innecesario.

Las container queries resuelven esto exactamente como suena: permiten que un componente consulte el tamaño de su contenedor padre y adapte su estilo en consecuencia. Es responsive a nivel de componente, no de página.

.card-container {
  container-type: inline-size;
  container-name: card;
}

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
  }
}

@container card (max-width: 399px) {
  .card {
    display: flex;
    flex-direction: column;
  }
}

Este patrón, imposible de lograr limpiamente con media queries, es directo con container queries. Y cuando lo combinas con la regla @scope, puedes además delimitar exactamente dónde se aplican esos estilos, eliminando la necesidad de convenciones de nomenclatura BEM o namespaces artificiales.

@scope: el complemento que nadie esperaba

@scope llegó a Chrome y Safari en 2025 y Firefox lo adoptó completamente en 2026. Su función es elegante: permite escribir estilos que solo se aplican dentro de un subárbol del DOM, sin necesidad de clases específicas o de aumentar la especificidad.

@scope (.card) {
  h3 {
    font-size: 1.125rem;
    margin-block-end: 0.5rem;
  }
  
  p {
    color: var(--text-secondary);
    line-height: 1.5;
  }
}

En el proyecto educativo que mencioné, combinamos @scope con container queries y eliminamos por completo la necesidad de nombrar clases como card__title--large o card__description--compact. El scope resuelve el aislamiento; el container query resuelve la adaptación.

Lo que medimos: la migración en números

Migrar 47 componentes de media queries a container queries no fue un cambio cosmético. Tomamos métricas antes y después en tres áreas:

Rendimiento de pintado CSS. Esperábamos una mejora y la obtuvimos. El navegador recalcula estilos solo dentro del contenedor afectado, no en todo el documento. En páginas con múltiples instancias del mismo componente (por ejemplo, 30 tarjetas en una grilla), el tiempo de estilo recolectado (style recalc) se redujo en un 34% en promedio.

Tamaño de CSS en producción. El código se redujo un 22%. Ya no necesitábamos selectores anidados tipo .sidebar .card { ... }, .main-content .card { ... }, .grid .card--compact { ... }. Cada componente define su variante una vez, y el contenedor decide cuál se aplica.

Complejidad del JavaScript de layout. Eliminamos aproximadamente 200 líneas de JavaScript que existían únicamente para detectar el ancho del contenedor y aplicar clases dinámicamente. Las container queries hacen eso en CSS, nativamente.

¿Hubo desventajas? Sí. El proceso de migración tomó más tiempo del esperado porque tuvimos que definir correctamente los container-type y container-name para cada contexto. No es un cambio que se haga en una tarde. Pero una vez establecido, el sistema de diseño es más mantenible y predecible.

Framework de decisión: container query vs media query

Con la experiencia acumulada, desarrollamos este criterio para decidir:

Usa container query cuando:

• El componente aparece en múltiples contextos con anchos diferentes (sidebar, main, grid)
• El componente es reutilizable y su layout depende de su contenedor inmediato
• Trabajas con un sistema de diseño basado en componentes independientes
• Quieres eliminar JavaScript que exista solo para adaptar layout al contenedor

Usa media query cuando:

• Necesitas cambiar el layout global de la página (de múltiples columnas a una sola columna)
• Ajustas elementos que no están dentro de un contenedor definido (body, header global, footer)
• Defines breakpoints de tipografía general o espaciado global
• Tu público incluye usuarios de navegadores legacy (menos del 7% global, pero puede importar según el mercado)

Usa ambas — en conjunto — cuando:

• Un componente necesita adaptarse a su contenedor Y el layout global debe cambiar en pantallas pequeñas
• La estrategia más robusta combina media queries para el esqueleto de la página y container queries para los componentes internos

Tres patrones que nos sorprendieron

Durante la migración encontramos patrones que no anticipamos:

1. Container query units (cqw, cqh, cqi). Las unidades relativas al contenedor son más útiles de lo que parecen. font-size: 5cqi escala el texto proporcionalmente al contenedor sin media queries adicionales. En cards de precios y testimonios, esto eliminó por completo la necesidad de breakpoints de tipografía.

2. Style queries para theming. @container style(--theme: dark) permite cambiar estilos basados en propiedades personalizadas del contenedor. Lo usamos para el modo oscuro a nivel de componente: una tarjeta puede estar en modo oscuro mientras el resto de la página está en modo claro, sin conflicto.

3. La intersección con View Transitions. Al combinar container queries con la View Transition API, las transiciones entre layouts de componentes se sienten nativas. Cuando una card pasa de vertical a horizontal al cambiar de contenedor, la transición es suave y no requiere JavaScript.

El elefante en la sala: ¿y Firefox?

Históricamente, Firefox fue el último en adoptar container queries completas. Para junio de 2026, Firefox 130+ soporta container queries, style queries, y @scope sin banderas. La brecha ya no existe. Si estás postergando la adopción por soporte de Firefox, es momento de reevaluar.

Lo que esto significa para tu próximo proyecto

Las container queries y @scope no son solo nuevas features de CSS. Son una señal de hacia dónde va el desarrollo frontend: componentes verdaderamente independientes que llevan su propio responsive incorporado, sin JavaScript de por medio.

Si estás por empezar un rediseño o construir un sistema de diseño nuevo, vale la pena considerar container queries desde el día uno. La migración es posible después, pero es más trabajo que diseñar con ellas desde el inicio.

En Mintec ayudamos a equipos a adoptar arquitecturas frontend modernas — desde sistemas de diseño con container queries hasta migraciones de frameworks completos. Si tu equipo está evaluando este cambio, contáctanos y conversamos.

Mientras tanto, te recomendamos leer sobre cómo la arquitectura web componible se complementa con estas técnicas, y nuestra guía sobre Core Web Vitals y rendimiento frontend para entender el contexto completo de optimización web moderna.