Límites, soporte y el fallback

Subgrid llegó a los tres motores repartido en cuatro años: Firefox en 2019, Safari en 2022, Chrome en 2023. En 2026 está ampliamente disponible y se puede usar sin reservas en producción, pero conviene tener claro qué problemas no resuelve, por qué su coste de cálculo no es despreciable y cómo escribir una versión degradada que siga siendo usable, porque la degradación de un layout de alineación tiene que ser deliberada o queda peor que no haber alineado nada.

El soporte

Firefox lo implementó primero, en la versión 71 de diciembre de 2019, y estuvo solo durante casi tres años. Safari 16 lo trajo en septiembre de 2022. Chrome y Edge, en la 117 de septiembre de 2023. Desde ese momento está en los tres motores, y con el margen de estabilidad habitual entró en la categoría de ampliamente disponible durante 2026.

En términos prácticos: puedes usarlo directamente en cualquier proyecto nuevo. Solo necesitas un fallback si tu producto tiene una base medible de navegadores anteriores a otoño de 2023, cosa que en 2026 solo ocurre en entornos corporativos con versiones congeladas.

Lo que subgrid no hace

No es masonry. El layout tipo mampostería, donde los elementos se apilan verticalmente rellenando huecos como en un muro de piedra, no es lo que hace subgrid ni se puede construir con él. Masonry sigue siendo una discusión abierta en el grupo de trabajo, con propuestas sintácticas en competencia, y solo está disponible detrás de banderas experimentales. No cuentes con ello en producción; lo que existe hoy son grid-auto-flow: dense con sus limitaciones o una implementación en JavaScript.

No alinea elementos arbitrarios. Un subgrid solo puede alinearse con las pistas de su propio ancestro. No hay forma de alinear dos elementos de ramas distintas del árbol, ni de decir “alinéate con aquel otro”. La relación es siempre estructural, y esa restricción es intencionada.

No sobrevive al confinamiento ni a la posición absoluta. Como ya viste, contain: layout, contain: content y position: absolute fuerzan un contexto de formato independiente, y en ese caso subgrid se usa como none. Es incompatible por definición: subgrid necesita propagar información de dimensionado hacia arriba y el confinamiento existe precisamente para impedirlo.

No es gratis. Los contenidos del subgrid participan en el cálculo de tamaño de las pistas del padre, lo que crea una dependencia bidireccional que atraviesa niveles del árbol. En una rejilla con muchas filas y subgrids en todas, la diferencia con la misma rejilla sin subgrid es medible en el perfilador. No es motivo para no usarlo, pero sí para no anidarlo tres niveles sin necesidad.

display: contents, la alternativa parcial

display: contents resuelve el mismo problema de otra forma: elimina la caja del elemento intermedio y promueve a sus hijos a elementos del abuelo. Como pasan a ser hijos de verdad, se alinean.

/* Los hijos de .campo se convierten en elementos de .formulario */
.campo { display: contents; }

La comparación es directa y la decisión es fácil:

La fila decisiva es la segunda: si el elemento intermedio tiene cualquier estilo visual propio —un borde, un fondo, un radio, un relleno, una sombra— display: contents lo hace desaparecer y no hay forma de recuperarlo. Como esa es la situación de casi todas las tarjetas y casi todos los grupos de formulario, subgrid gana en la mayoría de los casos reales.

display: contents sigue siendo útil cuando el elemento intermedio es puramente estructural: un contenedor que existe por razones de componente y no tiene ninguna presencia visual. En esos casos es más barato y más simple.

Escribir el fallback

La estrategia correcta es escribir primero la versión que funciona en todas partes y mejorarla dentro de un @supports. Así el navegador antiguo no necesita entender nada y el moderno recibe la mejora.

/* Base: sin subgrid. Las tarjetas se alinean solo por abajo,
   con flex y un margen automático. Es una degradación honesta. */
.plan {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
  padding: 1.25rem;
  border: 1px solid #45475a;
  border-radius: 0.75rem;
}
.plan .cta { margin-block-start: auto; }

/* Mejora: alineación completa entre las cuatro filas */
@supports (grid-template-rows: subgrid) {
  .planes { grid-template-rows: auto auto auto auto; }
  .plan {
    display: grid;
    grid-row: span 4;
    grid-template-rows: subgrid;
  }
  .plan .cta { margin-block-start: 0; align-self: end; }
}

Dos detalles importan en este patrón.

El primero: la versión base no intenta imitar el resultado con subgrid. Alinear los botones abajo con margin-block-start: auto es un resultado distinto y perfectamente aceptable, no una imitación defectuosa. Los intentos de reproducir la alineación completa sin subgrid son los que producen recortes de texto y alturas fijas.

El segundo: el bloque @supports deshace lo que la versión base hizo, en este caso el margin-block-start: auto. Un fallback que no se limpia deja dos mecanismos de alineación compitiendo, y el resultado es peor que cualquiera de los dos por separado.

Para detectar el eje de columnas la consulta es la simétrica, y ambas dan el mismo resultado porque ningún motor implementó un eje sin el otro:

@supports (grid-template-columns: subgrid) { }