Diseño responsive con Tailwind: container queries y estrategia de breakpoints

Introducción

Miras fijamente ese componente de tarjeta en la pantalla.

En la página de inicio se ve perfecto: imagen a la izquierda, texto a la derecha, espaciado cómodo. Pero al copiarlo a la barra lateral, el layout se colapsa como papel arrugado. La imagen queda aplastada y el texto se parte en líneas caóticas.

¿Cómo sabe este componente cómo debe verse?

El problema es que el diseño responsive tradicional solo mira el viewport: el tamaño de la ventana del navegador. El componente no sabe en qué ancho de contenedor está. Es como alguien acostumbrado a una casa grande que de repente termina en un estudio de 30 m² sin saber cómo organizar los muebles.

Las container queries de Tailwind resuelven eso: el componente percibe el tamaño de su contenedor en lugar de mirar solo la ventana.

En este artículo repasamos las dos partes donde más se tropieza con el responsive en Tailwind: cómo elegir breakpoints y cómo usar container queries. Incluimos código real, porque leer documentación cien veces no sustituye probarlo una.

La evolución del responsive: del viewport al contenedor

Media queries: el método clásico y sus límites

Usé media queries durante años y me parecían suficientes. Hasta que tuve que meter la misma tarjeta en tres sitios distintos: grid de la home, recomendaciones en la barra lateral y lista dentro de un modal.

Ahí salieron a flote sus limitaciones.

Las media queries miran el ancho del viewport, no el del contenedor padre. Si escribes:

/* Media query tradicional */
@media (min-width: 768px) {
  .card {
    flex-direction: row;
  }
}

Significa: cuando la ventana supera 768px, la tarjeta pasa a layout horizontal.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Pero si el viewport mide 1200px y la barra lateral solo 280px, la tarjeta igual se pone en horizontal y se aprieta en ese espacio estrecho.

Container queries: otro enfoque

Las container queries preguntan: ¿qué tan ancho es mi contenedor?

/* Container query */
@container (min-width: 400px) {
  .card {
    flex-direction: row;
  }
}

Aquí la tarjeta cambia a horizontal cuando el contenedor supera 400px.

La misma tarjeta en un área de 600px se ve horizontal; en una barra de 280px se apila en vertical. Sin duplicar componentes, sin props extra, sin condicionales por ubicación.

El componente por fin es reutilizable de verdad.

Soporte en navegadores

Las container queries se popularizaron hacia 2023. En 2024, Chrome, Firefox, Safari y Edge las soportan; la cobertura supera el 90%.

Si aún debes soportar navegadores muy antiguos, quizá debas esperar. En la mayoría de proyectos actuales ya puedes usarlas.

El sistema de breakpoints de Tailwind CSS

Antes de las container queries, conviene dominar los breakpoints de Tailwind.

Breakpoints por defecto

Tailwind usa mobile-first: md:flex-row significa «aplicar flex-row cuando el viewport sea >= 768px».

Mobile-first: empieza por el móvil

Escribes primero estilos para pantallas pequeñas y los amplías con breakpoints:

<!-- Enfoque mobile-first -->
<div class="flex flex-col md:flex-row lg:gap-8">
  <!-- Móvil: apilado vertical -->
  <!-- Tablet (md): fila horizontal -->
  <!-- Escritorio (lg): más separación -->
</div>

Los estilos van de simple a complejo. En dispositivos antiguos solo cargas lo básico, con mejor rendimiento.

Cuándo personalizar breakpoints

En muchos proyectos los valores por defecto bastan. Pero a veces el diseño pide otros umbrales, por ejemplo 480px, 720px, 960px y 1200px:

// tailwind.config.js
module.exports = {
  theme: {
    screens: {
      'xs': '480px',
      'sm': '640px',
      'md': '720px',
      'lg': '960px',
      'xl': '1200px',
    }
  }
}

Si necesitas un breakpoint menor que sm, añade xs:

screens: {
  'xs': '475px',
  'sm': '640px',
  // ... resto por defecto
}

Nombres semánticos

Evita nombres como mobile, tablet, desktop: con pantallas plegables o de coche quedan obsoletos. Mejor sm, md, lg: solo indican tamaño, no dispositivo.

Container queries en la práctica

Paso 1: declarar el contenedor

Añade @container al elemento que actuará como contenedor de consulta:

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

<div class="@container">
  <div class="flex flex-col @sm:flex-row">
    ...
  </div>
</div>

Los hijos pueden usar @sm, @md, etc.

Breakpoints de contenedor

Son más pequeños que los del viewport porque el contenedor vive dentro de la página.

Caso 1: tarjeta adaptable

• Contenedor < 384px: vertical, imagen a ancho completo

• = 384px: horizontal, imagen con ancho fijo

• = 512px: imagen más grande, más líneas de texto

<div class="@container p-4">
  <article class="flex flex-col @sm:flex-row @lg:gap-6 bg-white rounded-lg shadow">
    <img
      src="https://example.com/image.jpg"
      alt="Imagen del artículo"
      class="w-full @sm:w-32 @lg:w-48 h-48 @sm:h-32 @lg:h-36 object-cover rounded-t-lg @sm:rounded-l-lg @sm:rounded-tr-none"
    />
    <div class="p-4 @sm:py-2 @lg:py-4 flex-1">
      <h3 class="text-base @lg:text-lg font-semibold mb-2">
        Guía de container queries en Tailwind
      </h3>
      <p class="text-sm text-gray-600 line-clamp-2 @lg:line-clamp-3">
        Cómo usar container queries en Tailwind CSS para que tus componentes se adapten de verdad al espacio disponible...
      </p>
      <div class="mt-3 flex items-center text-xs text-gray-400">
        <span>2026-03-27</span>
        <span class="mx-2">·</span>
        <span>5 min de lectura</span>
      </div>
    </div>
  </article>
</div>

En una barra de 280px queda compacta y vertical; en 600px se expande en horizontal. Sin cambiar código.

Caso 2: barra de navegación reutilizable

La misma navegación puede ir en header ancho, barra lateral estrecha o menú móvil:

<nav class="@container">
  <ul class="flex flex-col @lg:flex-row @lg:items-center gap-2 @lg:gap-6">
    <li>
      <a href="/" class="block py-2 px-3 rounded hover:bg-gray-100">
        Inicio
      </a>
    </li>
    <li>
      <a href="/posts" class="block py-2 px-3 rounded hover:bg-gray-100">
        Artículos
      </a>
    </li>
    <li>
      <a href="/about" class="block py-2 px-3 rounded hover:bg-gray-100">
        Acerca de
      </a>
    </li>
  </ul>
</nav>

Con contenedor >= 512px (@lg), los ítems se alinean en fila.

Limitaciones

1. Sin consulta de altura — solo ancho por ahora.

2. El ancestro debe ser contenedor de tamaño — las consultas apuntan al contenedor ancestro más cercano, no siempre al padre directo.

3. Poco anidamiento — más de 2-3 niveles puede afectar rendimiento.

Estrategia de breakpoints: media vs container

Pregunta clave: ¿de qué depende este estilo?

Flujo de decisión

¿El estilo depende del viewport o del contenedor?

├─ Viewport → media queries (md:, lg:)
│   ├─ Layout de página
│   ├─ Navegación global, header, footer
│   ├─ Hero, anuncios a pantalla completa
│   └─ Elementos fijos al viewport
│
└─ Contenedor → container queries (@sm:, @lg:)
    ├─ Componentes reutilizables (tarjetas, listas)
    ├─ Widgets de barra lateral
    ├─ Contenido de modales
    └─ Componentes anidados

Cuándo usar media queries

Layout de página:

<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
  <!-- tarjetas -->
</div>

Navegación global:

<header class="flex items-center justify-between px-4 py-3">
  <div class="logo">Logo</div>
  <nav class="hidden md:flex gap-6">
    <a href="/">Inicio</a>
    <a href="/posts">Artículos</a>
    <a href="/about">Acerca de</a>
  </nav>
  <button class="md:hidden">
    <span class="sr-only">Abrir menú</span>
  </button>
</header>

Cuándo usar container queries

Tarjetas que aparecen en home (~300-400px), recomendaciones (~250px) o barra lateral (~280px).

Componentes anidados:

<div class="@container w-full md:w-80">
  <div class="@container">
    <div class="@sm:flex-row @lg:gap-4">
      ...
    </div>
  </div>
</div>

Uso combinado

<div class="grid grid-cols-1 md:grid-cols-3 gap-6">
  <main class="md:col-span-2">
    <div class="@container">
      <article class="flex flex-col @sm:flex-row">
        <!-- contenido de tarjeta -->
      </article>
    </div>
  </main>
  <aside class="@container">
    <div class="@sm:grid-cols-2">
      <!-- widgets -->
    </div>
  </aside>
</div>

La página se adapta al dispositivo; los componentes, al espacio real.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Rendimiento y buenas prácticas

Costo de rendimiento

El navegador calcula tamaños de contenedor y escucha cambios. El impacto es bajo salvo anidamiento excesivo.

Evita @container en cada ítem de una lista con varias capas internas.

No abuses de container queries

Un hero que solo vive en la home no las necesita; media queries bastan.

Regla: úsalas cuando el componente deba vivir en contenedores de distinto ancho.

Depuración

DevTools → Elements → elemento con @container → Styles → reglas @container. También busca container-type en Computed.

Checklist

1. Máximo 2-3 niveles de @container
2. Solo en componentes reutilizables
3. Nombres por tamaño (sm/md/lg), no por dispositivo
4. Selectores simples dentro de container queries
5. Evita animaciones que dependan del tamaño del contenedor si cambia con frecuencia

Prueba el componente en contenedores de distintos anchos, no solo en el layout por defecto.

Resumen

Container queries permiten adaptar el layout al tamaño real del contenedor, no solo al viewport. Los componentes se vuelven reutilizables.

Principio:

• Layout de página → media queries (md:, lg:)
• Componentes reutilizables → container queries (@sm:, @lg:)

Rendimiento: poco anidamiento, uso moderado.

Si tienes componentes que repites en varios sitios, empieza por una tarjeta. Verás que dejas de duplicar estilos por ubicación.

Más detalle en Container Queries (Tailwind) y CSS Container Queries (MDN).