Breakpoints: contenido antes que dispositivos

Busca una chuleta de breakpoints y encontrarás anchos de viewport bautizados con hardware: iPhone, iPad, portátil, escritorio. Esas tablas se pudren con cada ciclo de producto, y nunca fueron del todo ciertas ni siquiera recién hechas: los dispositivos reales hoy cubren casi cualquier ancho a partir de 320px. El número más famoso de todos lo demuestra: 768px es el clásico iPad informando de su viewport en vertical, 768 × 1024 píxeles CSS. Ese dispositivo es pieza de museo; el número sigue en buena parte de las hojas de estilo del mundo. La convención sobrevivió a su dispositivo.

Un breakpoint CSS es un ancho de viewport en el que cambia la maquetación, y la forma duradera de situar uno es allí donde el contenido falla, no donde apunta una tabla de dispositivos: donde la longitud de línea abandona su banda legible, donde una barra lateral asfixia al contenido que tiene al lado, donde las tarjetas se comprimen por debajo de un ancho usable. Este artículo —parte de nuestra guía de la rejilla de maquetación— repasa esas señales de fallo, por qué los valores casi estándar suelen bastar de todos modos, y cómo los breakpoints se entregan como tokens.

¿Por qué no diseñar sin más para dispositivos?

Tres razones. La tabla es inestable: cada ciclo de producto añade anchos, y un breakpoint bautizado con un dispositivo hereda ese trasiego. La media query nunca conoció el dispositivo de todos modos: solo medía el viewport, así que «iPad» siempre fue una ficción cortés para «768px de ancho». Y las ventanas reales viven entre las entradas de la tabla: tablets en pantalla partida, ventanas de escritorio redimensionadas, pantallas plegables. Una maquetación verificada solo en los anchos de la tabla aún puede fallar entre ellos; una maquetación situada por sus propios puntos de fallo no puede, porque los puntos de fallo son la definición.

¿Dónde va un breakpoint?

Donde una maquetación deja visiblemente de funcionar. Tres señales de fallo cubren la mayoría de las páginas, cada una con un síntoma observable:

• La longitud de línea abandona la banda. El texto de cuerpo supera aproximadamente los 75 caracteres por línea y el ojo empieza a perder el viaje de vuelta a la línea siguiente: líneas releídas, líneas saltadas. El corte va donde la columna de texto excedería su presupuesto.
• La barra lateral asfixia al contenido. Mantener la barra lateral y el contenido lado a lado demasiado tiempo estruja la columna de contenido por debajo de lo que necesita mientras la barra lateral está a sus anchas. El corte va donde el lado a lado deja por primera vez ambas columnas usables.
• Las tarjetas se comprimen. Una fila de tarjetas mantenida demasiado tiempo recorta sus títulos y parte sus botones en varias líneas: por debajo de unos 250–280px las tarjetas dejan de cumplir su función. El corte va donde la siguiente tarjeta cabe a su ancho de trabajo completo.

Cada síntoma nombra su propio arreglo, y el breakpoint es sencillamente el ancho donde ese arreglo se activa.

¿Cómo se ve una auditoría guiada por el contenido?

Toma una página con los tres ingredientes —una columna de artículo, una fila destacada de tres tarjetas, una barra lateral— compuesta con texto de cuerpo de 16px, donde un carácter medio ocupa ≈8px:

De aquí salen dos lecturas honestas. Primera: la auditoría aterriza cerca de los cortes estándar de todos modos —768 cubre el texto (llega un poco tarde; entre ≈632 y 768 las líneas se pasan ligeramente, algo que puedes aceptar o resolver con un max-width en la columna, el único fallo que un tope arregla sin breakpoint). Segunda: la fila de tarjetas no obtiene su propio corte: las tres en fila se vuelven posibles a ≈886px, pero ahí no falla nada —dos en fila siguen cómodas hasta los 1200—. Posible no es lo mismo que necesario.

¿Por qué persisten igualmente los breakpoints estándar?

Porque los ecosistemas convergen. Los frameworks agrupan sus valores por defecto cerca de 640, 768, 1024 y 1280; los equipos heredan esos valores, las herramientas y los entornos de pruebas los dan por hecho, y los diseñadores bocetan sobre ellos. Y eso está bien la mayor parte del tiempo: las tolerancias del contenido son rangos, no puntos. Una maquetación cuyo verdadero fallo está en 730px queda perfectamente servida por un corte en 768.

La honestidad va en ambas direcciones. No fetichices los breakpoints a medida: la ganancia sobre los valores casi estándar suele ser pequeña, y un corte hecho a medida en 743px compra sobre todo carga de explicación. Pero tampoco trates los estándares como si fueran física: el principio del contenido demuestra su valía justo cuando una maquetación falla de verdad entre los cortes estándar, que es cuando tienes derecho a mover uno.

¿Las media queries deben ser min-width o max-width?

El enfoque mobile-first —los estilos base sirven al nivel más estrecho, y cada media query min-width añade lo que un nivel más ancho se gana— se ha vuelto el estándar moderno, y por una razón estructural: la maquetación estrecha suele ser la sencilla (una sola columna), así que el caso base se mantiene limpio y los niveles más anchos son aditivos en lugar de sustractivos.

.cards {
  display: grid;
  grid-template-columns: 1fr;   /* móvil: una columna */
  gap: 16px;
}
@media (min-width: 768px) {
  .cards { grid-template-columns: repeat(2, 1fr); gap: 24px; }
}
@media (min-width: 1200px) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

Cada guarda min-width es el punto de entrada de un nivel; la sintaxis completa de las queries, incluidas las formas de rango más nuevas como (768px <= width < 1200px), está en la referencia de @media de MDN.

¿Cómo se convierten los breakpoints en design tokens?

Los breakpoints son decisiones, y las decisiones derivan cuando viven solo en las hojas de estilo: un proyecto en 768, su hermano en 780, y nadie recuerda por qué. Tratarlos como tokens los pone en el mismo flujo que el color y la tipografía: en Scale Composer, la vista de rejilla es dueña de la sección de maquetación de la exportación DTCG, donde cada breakpoint entrega su min-width, sus columnas, su ancho de columna, su medianil y su margen, junto al ancho máximo de contenedor compartido. Cambia un nivel una vez y todo consumidor del archivo de tokens lo ve. La exportación a Figma lleva la misma estructura como una colección Grid con un modo por breakpoint, de modo que un diseñador cambia de nivel igual que cambiaría entre claro y oscuro.

Ve los tres niveles como tokens de maquetación en Scale Composer —el panel de exportación de la vista de rejilla muestra los valores de cada breakpoint junto a la rejilla que los produce.

¿Cuántos breakpoints necesitas?

Tres niveles cubren la mayoría de los productos: la auditoría de arriba necesitó dos cortes para tres señales de fallo. Un cuarto se gana su sitio solo cuando una maquetación real falla entre los cortes existentes, y la auditoría muestra la disciplina en miniatura: las tres tarjetas en fila caben a partir de ≈886px, pero en 886 no falló nada, así que no hay nivel. Nombra la maquetación que falla, calcula el ancho al que falla, y solo entonces — añade un cuarto nivel con su propio número de columnas en Scale Composer.