Los overlays: grid, flex, container queries y scroll-snap
Las superposiciones que dibujan lo invisible: las líneas y áreas de una cuadrícula, el espacio libre de un contenedor flexible, qué contenedor responde a una consulta y dónde están los puntos de anclaje del scroll.
Casi todo lo que causa un bug de layout es invisible: las líneas de una cuadrícula, el espacio sobrante que Flexbox reparte, cuál de los tres antepasados es el contenedor que responde a tu consulta, dónde exactamente se ancla el scroll. Los overlays del inspector dibujan esas cosas encima de la página, y su valor no es estético: convierten una hipótesis que ibas a comprobar cambiando valores al azar en una observación directa.
- Activar y leer el overlay de cuadrícula, incluidas las líneas nombradas y las áreas.
- Interpretar el overlay de Flexbox para diagnosticar reparto de espacio.
- Identificar qué elemento es el contenedor de consulta de un componente.
- Ver los puntos de anclaje del scroll y por qué a veces no se cumplen.
Dónde va el espacio: cuadrícula y Flexbox
Cuadrícula: números de línea, nombres y áreas
Junto a cualquier elemento con display: grid aparece en el árbol del DOM un distintivo que activa el overlay. Al activarlo, el inspector dibuja sobre la página las líneas de la cuadrícula con sus números, y en el panel de layout aparecen las opciones que hacen que sea realmente útil:
Los números de línea, en los dos ejes, positivos y negativos. Es la forma más rápida de comprobar si tu grid-column: 2 / 4 cae donde crees. La numeración negativa es especialmente propensa a errores porque cuenta desde el final y cambia cuando cambia el número de pistas.
Los nombres de línea. Si has nombrado líneas o has usado grid-template-areas, el overlay muestra los nombres reales, incluidos los que el motor genera automáticamente a partir de las áreas. Recuerda que declarar un área llamada cabecera crea implícitamente las líneas cabecera-start y cabecera-end; verlas dibujadas es lo que hace que ese mecanismo deje de ser magia.
Los tamaños de pista. Muestra el tamaño resuelto de cada pista, que es la información que necesitas cuando una columna 1fr no mide lo que esperabas. Casi siempre la explicación es que 1fr significa “una fracción del espacio libre” y hay un elemento cuyo tamaño mínimo de contenido se lleva el espacio antes del reparto.
Las áreas. Dibuja los nombres de área sobre las regiones que ocupan. Si tu plantilla de áreas tiene una errata —una cadena con un número distinto de columnas que las demás— la declaración entera es inválida y no verás ninguna área dibujada; esa ausencia es el diagnóstico.
Se pueden tener varios overlays de cuadrícula activos a la vez, con colores distintos. Es lo que hace falta para depurar subgrid, donde el problema casi siempre es que las líneas del hijo no se están alineando con las del padre, y verlo dibujado lo resuelve al instante.
Flexbox: el espacio libre es lo que hay que mirar
El overlay de Flexbox dibuja los límites de cada elemento, los huecos y —lo importante— el espacio libre restante en el eje principal.
Ese dato es el que resuelve la mayoría de los bugs de Flexbox, porque flex-grow y flex-shrink reparten espacio libre y no tamaños. Si el espacio libre es cero, flex-grow no hace nada por mucho que lo subas, y verlo dibujado ahorra la media hora de probar valores.
El overlay también expone el segundo gran problema de Flexbox, el tamaño mínimo automático. Un elemento flexible tiene min-width: auto por defecto, lo que significa que no se encogerá por debajo del tamaño mínimo de su contenido, y en la práctica ese contenido suele ser una palabra larga, una imagen o un elemento con white-space: nowrap. El síntoma es un contenedor que desborda pese a tener flex-shrink positivo. Al ver el overlay, el elemento culpable es el que ocupa exactamente su ancho mínimo de contenido y no cede.
En el panel de layout aparecen además controles para probar align-items, justify-content y flex-direction con un clic. Es más rápido que editar la declaración y sirve para entender qué hace cada valor cuando no lo tienes interiorizado.
Container queries: saber quién responde
Este es el overlay que más malentendidos evita, porque la pregunta que responde no se puede contestar leyendo el CSS.
Cuando un componente tiene reglas dentro de @container, la consulta no se resuelve contra su padre: se resuelve contra el antepasado más cercano que sea un contenedor de consulta válido, es decir, que tenga container-type distinto de normal, y —si la consulta usa un nombre— que tenga ese nombre. En un árbol con varios contenedores anidados, cuál gana no es evidente.
Los inspectores marcan los elementos que son contenedores de consulta con un distintivo propio, y al seleccionar un elemento afectado por una @container permiten saltar al contenedor que la está resolviendo y ver su tamaño actual. Con eso, los dos bugs clásicos se diagnostican en segundos:
No pasa nada. Casi siempre significa que no hay ningún contenedor de consulta por encima, y las reglas de dentro de @container simplemente no se aplican nunca. El elemento que creías contenedor no tiene container-type, o lo perdió al refactorizar.
Responde al contenedor equivocado. Hay un contenedor intermedio que no esperabas, normalmente un envoltorio de layout que alguien convirtió en contenedor. Se arregla poniendo nombres y consultando por nombre, y el overlay confirma que ahora responde el correcto.
Merece recordarlo porque el overlay lo deja claro y sigue sorprendiendo: un elemento con container-type: inline-size no puede tener reglas que dependan de su propio tamaño, porque eso sería circular. Las reglas de @container afectan a sus descendientes. Si el componente entero necesita adaptarse, hace falta un envoltorio que sea el contenedor y un hijo que sea el componente.
Scroll-snap y contenedores de scroll
Los inspectores marcan los contenedores con scroll y, cuando tienen scroll-snap-type, dibujan los puntos de anclaje: dónde se detendrá el scroll y a qué borde de cada elemento corresponde.
Los tres bugs que resuelve son siempre los mismos:
No ancla en ninguna parte. Falta scroll-snap-align en los hijos. scroll-snap-type en el contenedor por sí solo no hace nada; el contenedor declara la política y cada hijo declara su punto.
Ancla en el sitio equivocado. El punto está donde dice scroll-snap-align, pero hay una cabecera fija encima que lo tapa. Se corrige con scroll-margin en los hijos o scroll-padding en el contenedor, y el overlay muestra el desplazamiento aplicado.
El contenedor de scroll no es el que crees. Muy frecuente: un antepasado con overflow: auto que alguien añadió para otra cosa se lleva el scroll, y tu contenedor nunca desplaza nada. El distintivo de contenedor con scroll en el árbol del DOM lo revela de un vistazo.
Los overlays de depuración de renderizado
Aparte de los de layout, hay un grupo en el panel de renderizado que responde preguntas distintas y conviene conocer:
Parpadeo de repintado. Resalta en verde las áreas que se repintan. Es el diagnóstico directo del problema descrito en el capítulo sobre el coste del fotograma: si al desplazarte parpadea la pantalla entera en lugar de una franja, algo está forzando repintados de área completa.
Bordes de capa. Dibuja el contorno de cada capa de compositor. Es cómo se detecta la explosión de capas descrita en el capítulo de will-change: si ves decenas de contornos donde esperabas dos, tienes un problema de memoria de GPU.
Emulación de preferencias. Permite forzar prefers-color-scheme, prefers-reduced-motion, prefers-contrast y el modo de colores forzados sin cambiar la configuración del sistema. Es la única forma práctica de probar la combinación cruzada de tema —usuario con sistema oscuro y producto en claro— que es donde aparecen los bugs de tema que nadie reproduce.
Conviene entender por qué estas herramientas tienen un valor cualitativamente distinto al de un simple atajo visual. CSS es declarativo: tú escribes restricciones, el motor ejecuta un algoritmo y produce un resultado. Lo que ves en pantalla es únicamente la salida de ese algoritmo, y a partir de una salida no se puede reconstruir en qué paso se torció el cálculo. Un elemento que aparece a la izquierda cuando lo esperabas a la derecha es compatible con veinte causas distintas —el reparto de espacio libre, un mínimo de contenido que no cede, una línea de cuadrícula mal numerada, un contenedor de consulta equivocado, un bloque contenedor inesperado— y todas producen exactamente el mismo píxel. Sin observabilidad, la única estrategia disponible es perturbar entradas y ver qué pasa, que es lo que hace la gente al cambiar valores al azar, y que es equivalente a depurar un programa sin poder poner un punto de interrupción. Los overlays son ese punto de interrupción: dibujan las estructuras intermedias que el algoritmo construye y que nunca se pintan —líneas, pistas, espacio libre, puntos de anclaje, la identidad del contenedor de consulta— y con eso el espacio de veinte causas se reduce a una observación. Por eso el orden correcto de trabajo, cuando algo no encaja, es siempre encender el overlay antes de tocar nada. Cambiar un valor para ver qué pasa destruye la evidencia y añade una variable; mirar el estado intermedio la conserva y suele terminar la investigación en el primer vistazo.