Fecha de publicación: 30 de abril de 2024; última actualización: 13 de febrero de 2026
El equipo de Chrome desea ver una implementación de diseños de tipo mampostería en la Web. Sin embargo, creemos que implementarlo como parte de la especificación de CSS Grid, como se propuso en la publicación reciente de WebKit, sería un error. También creemos que la publicación de WebKit argumentaba en contra de una versión de mampostería que nadie proponía.
Por lo tanto, el objetivo de esta publicación es explicar por qué en Chrome nos preocupa implementar el diseño de mampostería como parte de la especificación de diseño de cuadrícula CSS y aclarar exactamente qué permite la propuesta alternativa. En resumen:
- El equipo de Chrome tiene muchas ganas de desbloquear el diseño de mampostería, ya que sabemos que es algo que los desarrolladores quieren.
- Agregar el diseño de mampostería a la especificación de la cuadrícula es problemático por motivos distintos a si crees que el diseño de mampostería es una cuadrícula o no.
- Definir el diseño de mampostería fuera de la especificación de la cuadrícula no impide que haya varios tamaños de pista para el diseño de mampostería, ni el uso de propiedades como la alineación o los espacios, ni ninguna otra función que se use en el diseño de cuadrícula.
¿Debería el diseño de mampostería formar parte de la cuadrícula?
El equipo de Chrome cree que el diseño de mampostería debería ser un método de diseño independiente, definido con display: masonry (o con otra palabra clave si se decide un nombre mejor). Más adelante en esta publicación, podrás ver algunos ejemplos de cómo se vería eso en el código.
Existen dos motivos relacionados por los que creemos que el diseño de mampostería se define mejor fuera del diseño de cuadrícula: el potencial de problemas de rendimiento del diseño y el hecho de que tanto el diseño de mampostería como el de cuadrícula tienen características que tienen sentido en un método de diseño, pero no en el otro.
Rendimiento
La cuadrícula y el diseño de mampostería son opuestos en cuanto a la forma en que el navegador maneja el tamaño y la ubicación. Cuando se diseña una cuadrícula, todos los elementos se colocan antes del diseño, y el navegador sabe exactamente qué hay en cada pista. Esto habilita el complejo dimensionamiento intrínseco que es tan útil en la cuadrícula. Con el diseño de mampostería, los elementos se colocan tal como se disponen, y el navegador no sabe cuántos hay en cada pista. Esto no es un problema con todas las pistas de tamaño intrínseco ni con todas las pistas de tamaño fijo, pero sí lo es si mezclas pistas fijas y pistas intrínsecas. Para solucionar el problema, el navegador debe realizar un paso previo al diseño en el que se diseñe cada elemento de todas las formas posibles para obtener medidas. Con una cuadrícula grande, esto contribuiría a problemas de rendimiento del diseño.
Por lo tanto, si tenías un diseño de mampostería con una definición de pista de grid-template-columns: 200px auto 200px, algo muy común en la cuadrícula, comenzarás a tener problemas. Estos problemas se vuelven exponenciales una vez que agregas subcuadrículas.
Se puede argumentar que la mayoría de las personas no se encontrarán con este problema, pero ya sabemos que las personas tienen cuadrículas muy grandes. No queremos lanzar algo que tenga límites en cuanto a su uso cuando existe un enfoque alternativo.
¿Qué hacemos con los elementos que no tienen sentido en cada método de diseño?
Cuando Flexbox y Grid se convirtieron en parte de CSS, los desarrolladores a menudo sentían que se comportaban de manera incoherente. La incoherencia que experimentaban se debía a suposiciones arraigadas sobre cómo funcionaba el diseño, basadas en el diseño de bloques. Con el tiempo, los desarrolladores comenzaron a comprender los contextos de formato. Cuando cambiamos a un contexto de formato de cuadrícula o flexible, algunas cosas se comportan de manera diferente. Por ejemplo, sabes que, cuando estás en flexbox, no todos los métodos de alineación están disponibles, ya que flexbox es unidimensional.
Incluir el diseño de mampostería en la cuadrícula rompe este vínculo claro entre el contexto de formato y la disponibilidad de elementos como las propiedades de alineación, que se definen en la especificación de Box Alignment por contexto de formato.
Si decidimos abordar el problema de rendimiento que se describió anteriormente haciendo que las definiciones de pistas mixtas intrínsecas y fijas sean ilegales en el diseño de mampostería, deberás recordar que un patrón muy común para los diseños de cuadrícula no funciona para el diseño de mampostería.
También hay patrones que tendrían sentido en el diseño de mampostería, por ejemplo, grid-template-columns: repeat(auto-fill, max-content), porque no tienes restricciones cruzadas, pero deben seguir siendo no válidos en la cuadrícula. A continuación, se incluye una lista de propiedades que esperamos que se comporten de manera diferente o que tengan diferentes valores válidos.
grid-template-areas: En el diseño de mampostería, solo puedes especificar la fila inicial en la dirección que no es de mampostería.grid-template: La abreviatura debería tener en cuenta todas las diferencias.- Realiza un seguimiento de los valores de tamaño para
grid-template-columnsygrid-template-rowsdebido a las diferencias en los valores legales. grid-auto-flowno se aplica a la disposición en columnas ymasonry-auto-flowno se aplica a la cuadrícula. Si los combinaras, se generarían problemas con elementos que no son válidos debido al método de diseño que estás usando.- La cuadrícula tiene cuatro propiedades de posición (
grid-column-start, etcétera), mientras que la disposición en columnas solo tiene dos. - La cuadrícula puede usar las seis propiedades de
justify-*yalign-*, pero Masonry solo usa un subconjunto, como flexbox.
También se deberá especificar qué sucede en todos los casos de error nuevos causados por los desarrolladores que usan un valor que no es válido en la cuadrícula con mampostería o sin mampostería. Por ejemplo, es válido usar grid-template-columns: masonry o grid-template-rows: masonry, pero no ambos a la vez. ¿Qué sucede si usas ambos al mismo tiempo?
Estos detalles se deben especificar para que todos los navegadores hagan lo mismo.
Todo esto se complica desde el punto de vista de la especificación, tanto ahora como en el futuro. Tendremos que asegurarnos de que todo tenga en cuenta el diseño de mampostería y de que funcione o no en ese diseño. También es confuso desde el punto de vista de los desarrolladores. ¿Por qué deberías tener en cuenta que, a pesar de usar display: grid, algunas cosas no funcionan debido al uso de mampostería?
Una propuesta alternativa
Como ya se mencionó, el equipo de Chrome desea definir el diseño de mampostería fuera de la especificación de la cuadrícula. Esto no significa que se limitaría a un método de diseño muy simple con tamaños de columna idénticos. Todas las demostraciones en la publicación de WebKit seguirían siendo posibles.
Diseño clásico de mampostería
Cuando la mayoría de las personas piensan en mampostería, piensan en un diseño con varias columnas del mismo tamaño. Esto se definiría con el siguiente CSS, que necesita una línea menos de código que la versión equivalente incluida en la cuadrícula.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
gap: 1rem;
}
Usa el ajuste de tamaño de pista de tipo cuadrícula para diferentes anchos de columna
Además del problema mencionado anteriormente con el tamaño de pistas mixto intrínseco y fijo, puedes usar todos los tamaños de pistas que te encantan de la cuadrícula. Por ejemplo, el ejemplo de la entrada de blog de WebKit, un patrón de columnas estrechas y más anchas repetidas.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
gap: 1rem;
}
Tamaños de pistas adicionales para el diseño de mampostería
Hay opciones de tamaño de pista adicionales que no permitimos en la cuadrícula porque esta es un método de diseño bidimensional. Serían útiles en el diseño de mampostería, pero sería confuso si no funcionaran en la cuadrícula.
Completar automáticamente pistas de tamaño max-content
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, max-content);
gap: 1rem;
}
Completar automáticamente pistas de tamaño auto, lo que creará pistas del mismo tamaño, ajustadas automáticamente para adaptarse a la más grande
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, auto);
gap: 1rem;
}
Permite que el contenido abarque varias columnas y coloca elementos en el diseño de mampostería.
No hay motivos para no tener contenido que abarque columnas en una especificación de mampostería separada. Esto podría usar una propiedad masonry-track, que es una abreviatura de masonry-track-start y masonry-track-end, ya que solo tienes una dimensión para abarcar elementos cuando se usa un diseño de mampostería.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, auto);
}
.span-2 {
masonry-track: span 2; /* spans two columns */
}
.placed {
masonry-track: 2 / 5; /* covers tracks 2, 3, and 4 */
}
Subdiseño de mampostería o subcuadrícula que adopta pistas de mampostería
Esto se podría admitir con una especificación de mampostería independiente, nuevamente con la condición de que no se permitan pistas de tamaño fijo y de tamaño intrínseco mixto. Se deberá definir exactamente cómo se verá. No vemos motivos por los que esto no debería funcionar.
Conclusión
Nos encantaría llegar a un punto de especificación que se pueda enviar de forma interoperable. Sin embargo, queremos hacerlo de una manera que funcione bien ahora y en el futuro, y en la que los desarrolladores puedan confiar. La única forma de abordar los problemas de rendimiento descritos sería empeorar el segundo problema, es decir, el de tener partes de la cuadrícula ilegales en el diseño de mampostería. No creemos que sea una buena solución, sobre todo cuando es posible tener todas las funciones de cuadrícula que desees y mantener claramente separadas las cosas que son diferentes.
Si tienes comentarios, únete al debate en el problema 9041.
Gracias a Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick y Chris Harrelson por revisar esta publicación y los debates que la fundamentaron.