El inspector de grid: ver las líneas que no existen
El overlay de rejilla con todas sus opciones, cómo leer los tamaños de track reales frente a los declarados, y los cuatro bugs de grid que solo se ven con el overlay activo.
Grid es el único sistema de layout de CSS cuya estructura no es visible en la página: las líneas, los tracks, las áreas y los huecos son entidades reales que gobiernan la colocación de todo y que no dibujan ni un píxel. Depurar grid sin overlay es razonar sobre una geometría invisible a partir de sus efectos, que es exactamente igual de difícil que suena. Con el overlay activo, la mayoría de los bugs de rejilla se diagnostican de un vistazo.
- Activar el overlay de rejilla y configurar qué información muestra.
- Distinguir los tamaños de track declarados de los resueltos y leer la diferencia.
- Interpretar la numeración de líneas positiva y negativa, y los nombres de línea y de área.
- Diagnosticar los cuatro fallos de grid que el overlay hace evidentes.
Activar y configurar el overlay
Cualquier elemento con display: grid o inline-grid muestra un distintivo junto a su etiqueta en el árbol. Pulsarlo dibuja el overlay sobre la página. Además, el panel de Elements tiene una sección de layout —una pestaña lateral junto a estilos y computados— que lista todas las rejillas de la página con una casilla cada una, lo cual permite tener varias visibles a la vez y compararlas.
Esa misma sección contiene los ajustes globales del overlay, y son cuatro los que importan.
Mostrar los números de línea. Se puede elegir entre no mostrarlos, mostrar los positivos, mostrar los negativos, o mostrar los nombres si los tracks tienen nombre. La numeración negativa es la que resuelve el problema de posicionar algo al final de una rejilla cuyo número de columnas no conoces: grid-column: -2 / -1 es la penúltima columna independientemente de cuántas haya.
Mostrar los nombres de área. Dibuja el nombre de cada área declarada con grid-template-areas sobre su rectángulo. Es la forma de comprobar que el dibujo ASCII de tu declaración produce las áreas que creías.
Mostrar los tamaños de track. Escribe junto a cada línea el tamaño declarado y el resuelto, separados. Este es el ajuste más valioso de los cuatro y la razón está en el siguiente apartado.
Extender las líneas. Prolonga las líneas de la rejilla más allá del contenedor, lo que ayuda a alinear elementos con la rejilla de un contenedor hermano.
Los overlays son persistentes: siguen dibujados mientras navegas por el árbol, editas estilos o interactúas con la página. Eso permite el flujo de trabajo que de verdad rinde, que es tener la rejilla visible mientras ajustas valores con las flechas del teclado en el panel de estilos y ver los tracks moverse en tiempo real.
Declarado frente a resuelto
La distinción que hace del overlay una herramienta de diagnóstico y no un adorno. Cuando activas los tamaños de track, el overlay muestra dos valores por track: lo que escribiste y lo que el algoritmo decidió.
En un grid-template-columns: 1fr 2fr 1fr verás 1fr junto a 240px, 2fr junto a 480px y 1fr junto a 240px. Mientras esos números guarden la proporción declarada, todo va bien.
Cuando no la guardan es cuando aprendes algo. Los tres casos.
Un track 1fr que resuelve a mucho más de lo que le tocaría significa que su contenido tiene un tamaño mínimo mayor. El valor fr implica un mínimo automático, y ese mínimo es el tamaño mínimo del contenido: una palabra larga sin puntos de corte, una imagen con ancho intrínseco, un elemento con min-width explícito. La rejilla no puede encoger ese track por debajo de eso, así que roba espacio a los demás. Es la causa número uno de “mi rejilla se desborda” y el arreglo canónico es minmax(0, 1fr).
Un track auto que resuelve a cero significa que no tiene contenido, o que su contenido está posicionado de una forma que lo saca del flujo.
Un número de tracks distinto del que declaraste significa que hay tracks implícitos: elementos colocados fuera del rango declarado hacen que la rejilla cree filas o columnas nuevas, gobernadas por grid-auto-rows y grid-auto-columns. El overlay los dibuja con un estilo de línea distinto —discontinua en vez de continua— y esa distinción visual es la forma más rápida de detectar que algo se está saliendo de tu plantilla.
Subgrid
Un contenedor con grid-template-columns: subgrid hereda las líneas de su padre en vez de definir las suyas. En el overlay eso se ve como una rejilla cuyas líneas coinciden exactamente con las del ancestro, y el distintivo del árbol lo indica.
La comprobación que hay que hacer siempre con subgrid: que el hijo abarque suficientes tracks del padre. Un subgrid solo hereda las líneas del rango que ocupa, así que un elemento colocado en una sola columna del padre hereda una sola línea, lo cual casi nunca es lo que se quiere. Con los dos overlays activos a la vez —el del padre y el del subgrid— el desajuste es inmediatamente visible.
Los cuatro bugs que el overlay hace evidentes
El desbordamiento por mínimo automático. Ya descrito. Con los tamaños de track visibles, un track cuyo resuelto excede su parte proporcional lo delata al instante.
La colocación implícita inesperada. Un elemento con grid-row que apunta a una fila que no existe hace que la rejilla la cree. Sin overlay ves un hueco enorme y no entiendes de dónde sale; con overlay ves tres filas implícitas dibujadas con línea discontinua.
El desajuste de una línea. El error clásico de contar líneas como si fueran tracks. Una rejilla de tres columnas tiene cuatro líneas, y grid-column: 3 significa “empieza en la línea 3 y ocupa un track”, que es la tercera columna; pero grid-column: 1 / 3 ocupa dos columnas, no tres. Con los números de línea dibujados, este error se ve y se corrige en segundos en vez de resolverse a base de probar.
El gap que parece margen. Un espacio entre elementos puede venir del gap de la rejilla o de un margen del hijo, y visualmente son idénticos. El overlay dibuja el gap con un patrón de rayado propio, así que si el espacio que te sobra no está rayado, no es gap.
El fallo de grid que más tiempo consume y que el overlay resuelve de una forma casi cómica es este: estás editando el grid equivocado. Ocurre en cuanto hay más de una rejilla anidada, que en una aplicación real es siempre. Escribes grid-template-columns en un contenedor, no pasa nada visible, subes el valor, sigue sin pasar nada, y llevas veinte minutos convencido de que grid está roto. Lo que ocurre es que los elementos que estás mirando no son hijos directos de ese contenedor: hay un wrapper de por medio —un componente de framework que envuelve, un fragmento que se materializó como div, un elemento de accesibilidad— y por tanto son nietos, y las propiedades de rejilla solo gobiernan a los hijos directos. La rejilla que estás configurando existe perfectamente, tiene sus tracks, y contiene un único elemento que ocupa la primera celda. La sección de layout del panel resuelve esto en un segundo porque lista todas las rejillas de la página con casillas independientes: actívalas todas a la vez y verás inmediatamente cuántas hay, dónde están y cuál contiene de verdad a los elementos que quieres colocar. Si el rectángulo que se dibuja alrededor de tus elementos no es el de la rejilla que estás editando, tienes la respuesta. El mismo razonamiento vale íntegro para flex y es igual de frecuente. La lección general es que en CSS moderno la relación padre-hijo directo es carga estructural, y cualquier capa de abstracción que inserte elementos intermedios —un framework, una librería de componentes, una utilidad de layout— puede romper silenciosamente un contrato que el CSS no tiene forma de declarar.
Construye una rejilla de tres columnas 1fr 1fr 1fr y mete en una de las celdas un texto de una sola palabra muy larga, sin espacios. Activa el overlay con los tamaños de track visibles y observa cómo el resuelto se despega del declarado. Después cambia a minmax(0, 1fr) y mira los números volver a su sitio. Ese ejercicio de dos minutos vale por tres artículos sobre el dimensionado de grid.