Desbordamiento seguro y la llegada de align-content al bloque

Las dos incorporaciones más recientes del módulo de alineación resuelven problemas viejos que la gente había aprendido a rodear. safe corrige la pérdida de contenido que produce cualquier centrado cuando el contenido no cabe, un fallo silencioso que solo se manifiesta con textos largos o con la fuente ampliada. Y align-content en layout de bloque elimina la razón más frecuente para convertir un contenedor perfectamente normal en flex, con todos los efectos secundarios que eso arrastra.

El problema de la pérdida de datos

Un contenedor centrado con contenido más ancho que él reparte el sobrante a partes iguales por los dos lados. La mitad que sobresale por el lado del final se puede alcanzar desplazándose; la que sobresale por el lado del inicio, no: los contenedores de desplazamiento no permiten ir por detrás del origen.

.menu {
  display: flex;
  justify-content: center;
  overflow-x: auto;
  gap: 1rem;
}

Con seis enlaces cortos, perfecto. Con doce enlaces, o con la fuente al 200%, el primero y parte del segundo quedan fuera de alcance para siempre. Es un bug de accesibilidad de manual y no aparece en ninguna captura de pantalla del diseño original, porque solo se manifiesta en condiciones que nadie prueba.

El módulo llama a esto pérdida de datos y le dedica dos palabras clave.

safe y unsafe

safe se antepone al valor posicional y significa: alinea así mientras quepa; en cuanto haya desbordamiento, cambia a start para que nada quede detrás del origen.

.menu { display: flex; justify-content: safe center; overflow-x: auto; gap: 1rem; }

Con eso, los enlaces siguen centrados cuando sobra espacio y se pegan al inicio cuando falta, con lo que el desbordamiento entero queda accesible desplazándose hacia adelante. unsafe es la palabra opuesta y hace explícito el comportamiento por defecto: alinea así aunque se pierda contenido.

Merece la pena entender por qué el valor por defecto no es safe. La razón es la compatibilidad: cambiar el comportamiento de center habría movido píxeles en millones de páginas existentes. Así que el módulo dejó el comportamiento antiguo como predeterminado y añadió la corrección como opción explícita, lo que en la práctica significa que eres tú quien tiene que acordarse.

align-content en layout de bloque

Hasta 2024, centrar verticalmente el contenido de un contenedor de altura fija obligaba a convertirlo en flex o en grid. Eso funciona, pero tiene consecuencias que no siempre quieres: los hijos pasan a ser ítems de flex con sus reglas de dimensionado, deja de haber colapso de márgenes, los elementos en línea generan cajas anónimas de flex y cualquier float deja de tener efecto.

align-content en layout de bloque evita todo eso. Distribuye las cajas en flujo dentro del espacio sobrante del eje de bloque, sin cambiar el modo de layout:

.banda {
  block-size: 20rem;
  align-content: center;   /* el contenido, centrado en vertical. Sigue siendo bloque */
  padding-inline: 2rem;
}

Sigue siendo un contenedor de bloque: los párrafos siguen siendo párrafos, los márgenes siguen colapsando entre hermanos, y un text-align sigue haciendo lo de siempre. Solo se ha rellenado el espacio vertical sobrante de otra forma.

Los valores de distribución también funcionan, lo que abre casos que antes eran incómodos:

.pie-de-tarjeta { block-size: 12rem; align-content: space-between; }

Dos avisos importantes. El primero: como toda distribución, necesita espacio sobrante, así que solo hace algo si el contenedor tiene una altura definida mayor que la de su contenido. El segundo: justify-content no se aplica a contenedores de bloque. Para el eje en línea sigues teniendo margin-inline: auto en el hijo y text-align para el contenido en línea, que es lo que ya usabas.

Soporte y fallback

La alineación de bloque llegó a Chrome 123, Firefox 125 y Safari 17.4, todos en la primera mitad de 2024. En agosto de 2026 la cobertura ronda el 86% del tráfico global: es una función madura pero todavía no universal, sobre todo por navegadores integrados en aplicaciones y móviles sin actualizar.

Como la propiedad simplemente se ignora donde no se soporta, el fallback natural es que el contenido quede arriba en lugar de centrado, que casi siempre es aceptable. Si el diseño no lo tolera, la detección es directa:

.banda { block-size: 20rem; }

@supports (align-content: center) {
  .banda { align-content: center; }
}

@supports not (align-content: center) {
  .banda { display: grid; align-content: center; }
}

Cuidado con esa detección: align-content: center es válido desde hace años en Grid y en Flexbox, así que @supports devuelve verdadero en navegadores que no implementan la variante de bloque. La comprobación de soporte de una propiedad no distingue el contexto en el que se aplica, y este es uno de los pocos casos donde eso importa de verdad. En la práctica, o aceptas el fallback natural, o usas Grid directamente si el centrado es innegociable.