- WebKit solicita feedback de diseñadores y desarrolladores en el proceso de estandarizar en CSS Grid Level 3 el layout masonry/waterfall, que durante mucho tiempo fue difícil de resolver en CSS
- El modelo propuesto funciona sobre
display: grid usando grid-template-rows: masonry para desactivar la generación de filas y rellenar los espacios vacíos con contenido, como ladrillos
- Apple considera que esta función debe estar dentro de Grid para poder combinarse con capacidades existentes de Grid como
fr, minmax(), max-content, spanning, posicionamiento explícito y subgrid
- El enfoque de un
display: masonry separado podría simplemente separar el tipo de layout, pero en la discusión podría quedar limitado principalmente a columnas de igual ancho y dificultar el uso de las capacidades de ajuste de tamaño de tracks de Grid
- Tras la actualización de octubre de 2024, el CSS Working Group concluyó que vale la pena incluir tracks de ancho variable, posicionamiento explícito, spanning y subgrid en masonry, y que también es posible implementarlo con buen rendimiento, pero la discusión sobre la sintaxis continúa
Situación actual de CSS Grid Level 3
- Tras la actualización de octubre de 2024, se creó el Working Draft oficial del W3C para CSS Grid Layout Module Level 3, y se documentó el comportamiento del layout masonry
- Los miembros del CSS Working Group concluyeron que vale la pena incluir las siguientes funciones en el layout masonry y que pueden implementarse con buen rendimiento
- Tracks de ancho variable
- Posicionamiento explícito
- Spanning
subgrid
- Sin embargo, el debate sobre la sintaxis sigue abierto, y WebKit lo continúa en otro artículo: Help us choose the syntax for Masonry in CSS
Por qué se necesita el layout masonry
- CSS Grid Level 1 se introdujo en 2017 y redujo la carga de tamaño y posicionamiento de los layouts basados en floats; Grid Level 2 ofrece Subgrid
- Pero incluso después de la llegada de CSS Grid, durante 7 años no hubo una respuesta clara a la pregunta “cómo escribir un layout masonry en CSS”
- El layout masonry es un patrón en el que el contenido se acomoda encajando entre sí como ladrillos o un muro de piedra, y también se conoce como waterfall layout
- Permite manejar contenido con distintas relaciones de aspecto, reduciendo la necesidad de recortar o achicar todo para convertir cada ítem en el mismo rectángulo
- Como el contenido se distribuye por toda la página, al hacer scroll se mantiene de forma natural el orden de lectura, y al agregar contenido en la parte inferior mediante lazy-load no hace falta mover el contenido existente
Historia de la propuesta y debate de estandarización
- El mecanismo para crear layouts masonry en CSS fue propuesto por primera vez por Mozilla en enero de 2020 como una extensión de CSS Grid, y se implementó en Firefox Nightly como función experimental detrás de una flag
- Apple comenzó en 2022 a implementar la propuesta de CSS Grid Level 3 en Safari Technology Preview, y actualmente está activada por defecto
- Dentro del CSS Working Group hubo diferencias sobre la dirección básica
- Algunos consideraban que masonry no debía ser parte de CSS Grid, sino un tipo de
display separado
- Otros no estaban seguros de que este layout fuera necesario para la web o de que sitios web conocidos fueran a usarlo
- WebKit considera que, para que los navegadores lancen esta función, primero se necesita consenso del CSS Working Group
Uso básico: un Grid que desactiva filas y usa solo columnas
- Un layout masonry/waterfall clásico se escribe aplicando
display: grid al elemento main, definiendo las columnas y luego especificando el valor masonry en la dirección de las filas
main {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
gap: 1rem;
grid-template-rows: masonry;
}
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) genera de forma repetida columnas flexibles con un ancho mínimo de 14remgap: 1rem crea una separación de 1rem entre columnas e ítemsgrid-template-rows: masonry le indica al navegador que no cree filas y que rellene el contenido siguiendo un patrón masonry/waterfall- Este ejemplo crea con cuatro líneas de CSS un layout flexible que se adapta a distintos tamaños de pantalla sin media queries ni container queries
- El nombre de valor actual,
masonry, podría cambiar antes del lanzamiento en navegadores
Por qué se quiere conservar la capacidad de definición de columnas de Grid
- Para mostrar por qué masonry debería formar parte de CSS Grid, WebKit creó cuatro demos que se pueden probar directamente en webkit.org/demos/grid3
- Las demos pueden verse en navegadores compatibles con Grid Level 3
- CSS Grid ofrece muchas opciones al definir columnas
- Tamaños fijos en varias unidades como
px, em, rem, cqi, lh, ch, ic, cap, vw, svh, entre otras
max-content, min-content- Unidad
fr
minmax()- Tamaños en
%
auto
- Por ejemplo, se puede dejar la primera y la última columna con un ancho fijo de 14ch y hacer que las columnas centrales sean flexibles con un mínimo de 28ch
main {
display: grid;
grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
grid-template-rows: masonry;
gap: 1rem;
}
- Al combinar la unidad
fr con minmax(), se puede crear una flexibilidad de dos etapas, en la que las columnas se expanden y contraen en etapas distintas
max-content y min-content hacen que el tamaño de las columnas se ajuste al tamaño del contenido, permitiendo una disposición distinta a la de adaptar el contenido a las columnas- También se pueden crear columnas de distintos anchos usando la secuencia de Fibonacci, como en
grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr;
- El ejemplo de mega menu usa
grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); para que cada columna crezca lo suficiente como para contener el texto de los enlaces sin saltos de línea
- WebKit considera que la discusión sobre un
display: masonry separado apunta a permitir solo columnas del mismo tamaño, como ocurre hoy con multicolumn layout
Spanning, View Transitions y columnar grid
- CSS Grid permite que los ítems abarquen varias columnas, por lo que también en una disposición masonry son posibles varias composiciones visuales
- En el ejemplo, se puede hacer que cada quinta imagen abarque dos columnas y que el resto de las imágenes ocupen solo una columna
- También es posible asignar la clase
wider a imágenes con una relación de aspecto más ancha para que ocupen varias columnas, cambiar las esquinas a rectas o reducir el espacio a 0
- La demo Photos se combina con View Transitions: cuando el usuario hace clic o toca una foto, esa foto se expande para abarcar varias columnas y el navegador anima automáticamente la transición
- Esta demo requiere Safari Technology Preview 192 o superior
- WebKit ve el núcleo de Grid Level 3 más como un mecanismo para desactivar filas que como un patrón específico llamado “masonry”
- Este enfoque crea una columnar grid compuesta solo por columnas, en contraste con la modular grid, con filas y columnas completamente alineadas, que CSS Grid Level 1 crea bien
Diferencia entre modular grid y columnar grid
- Una modular grid es una Grid en la que el contenido se ajusta tanto a columnas como a filas, y CSS Grid Level 1 es adecuado para este tipo de disposición
- Los layouts basados en floats también fomentaron el uso de modular grid en la web, porque las alturas del contenido debían coincidir para que los floats se limpiaran correctamente
- En sitios web reales, a menudo se igualan las relaciones de aspecto de las imágenes, se ajusta la longitud del texto o se fuerza el contenido dentro de cajas iguales mediante políticas del CMS o recortes y elipsis en CSS
- Una columnar grid permite que el contenido mantenga el tamaño que necesita y que el layout funcione adaptándose al contenido
- WebKit considera que también el contenido centrado en texto puede disponerse de forma más dinámica, como muestra el ejemplo en el que el artículo más reciente abarca cuatro columnas, algunos artículos recientes abarcan dos y el contenido más antiguo ocupa una columna
Combinación de Subgrid y posicionamiento explícito
- subgrid, de CSS Grid Level 2, es compatible con la mayoría de los navegadores
- El ejemplo de una página de museo, en vez de listar los metadatos de las tarjetas de pinturas en una sola columna alineada a la izquierda, usa
subgrid para colocar el año y el número de catálogo a la derecha de cada tarjeta y alinearlos con los mismos datos de otras tarjetas
- Si masonry entra en CSS Grid Level 3, también podrán aprovecharse tal cual las herramientas de desarrollo existentes
- Con el Grid Inspector de Safari Technology Preview se puede probar
grid-template-rows: masonry
- Si se convierte en un tipo de display separado, no se obtendrán los beneficios de subgrid
- También puede usarse junto con el posicionamiento explícito de CSS Grid Level 1; en el ejemplo,
grid-column: -3 / -1 coloca el encabezado en la esquina superior derecha de la página, sobre las dos últimas columnas
- WebKit considera que con unas pocas líneas de código de layout se pueden combinar funciones de Grid Level 1, 2 y 3 para crear un layout en el que la cantidad de columnas cambia según el tamaño disponible, sin media queries ni container queries
Puntos de debate frente a display: masonry
- WebKit y Apple consideran que Masonry es una función que extiende CSS Grid para poder crear no solo modular grids, sino también columnar grids
- En esta dirección, se pueden usar junto con ello funciones de Grid como definición de columnas, track spanning, posicionamiento explícito y
subgrid
- Quienes prefieren un tipo de display separado consideran que permite separar limpiamente los tipos de layout
display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;
- El CSS Working Group aún no ha discutido la sintaxis de un Masonry display type separado, pero WebKit menciona como ejemplos una sintaxis similar a Multicolumn layout o una sintaxis limitada parecida a Grid
main {
display: masonry;
columns: 28ch;
}
main {
display: masonry;
masonry-columns: repeat(5, minmax(28ch, 1fr));
/* where only one repeating width is allowed */
}
- Un tipo de layout separado podría evitar el trabajo necesario para que Grid y Masonry sigan funcionando juntos
- El modelo de layout se simplifica
- La implementación en navegadores se vuelve más fácil
- Se reduce la posibilidad de trampas de rendimiento
- Los conjuntos de funciones de Grid y Masonry podrían divergir
- En cambio, WebKit considera que si ambos tipos de layouts Grid están conectados, el CSS Working Group definirá funciones futuras tanto para modular grid como para columnar grid
- Por ejemplo, si en CSS Grid Level 4 se agregan funciones como estilos para grid areas y grid lines, colores de fondo para tracks o líneas divisorias en los gaps, WebKit considera que sería mejor que desde el inicio funcionen en ambos tipos de Grid
Cómo entender “Grid”
- Quienes apoyan un
display: masonry separado a veces consideran que CSS Grid es, por naturaleza, una alineación bidimensional, y que masonry no es Grid porque solo alinea en una dirección
- WebKit considera que, en la historia del diseño gráfico, la grid fue una herramienta para ordenar texto, imágenes y contenido en patrones regulares que ayudan a la legibilidad y la usabilidad
- Incluso antes de que los modernistas europeos y estadounidenses del siglo XX enfatizaran la alineación en columnas y filas como una “proper” graphic design grid, ya se usaban grids diversas
- Mark Boulton veía las columnar grids simétricas como formales y aburridas, y promovía el uso de compound grids asimétricas en el diseño web
- CSS Grid Level 1 hizo fácil crear grids asimétricas y compound grids, pero actualmente eso solo aplica cuando esa Grid es una modular grid
- WebKit considera que tanto las modular grids como las columnar grids son grids, y que CSS Grid también debería tener la capacidad de crear columnar grids
Feedback solicitado a desarrolladores y diseñadores
- WebKit pide a desarrolladores y diseñadores que creen sus propias demos, escriban opiniones en blogs o redes sociales y dejen comentarios en issues del CSS Working Group
- Las preguntas para el feedback son las siguientes
- Si “masonry”/“waterfall” debe formar parte de CSS Grid
- Si se necesitan capacidades de columnar grid que incluyan
subgrid, spanning, posicionamiento explícito y distintos track sizing
- Si basta con el layout masonry clásico de columnas del mismo tamaño
- Si realmente usarían esta función y qué podrían construir con ella
- Si tienen enlaces a demos que hayan creado
- Si hay algo que no se pueda hacer con este modelo
- El equipo de WebKit trabajó en Masonry durante un año y medio, y se activó por defecto en Safari Technology Preview 163 en febrero de 2023
- Quieren lanzar la función pronto, pero antes deben resolverse detalles como el nombre y preguntas fundamentales
Discusión sobre el nombre: masonry, waterfall, off
- WebKit considera muy probable que
masonry no sea el mejor nombre para el nuevo valor
- Los nombres en CSS suelen ser palabras simples que describen directamente el resultado, como
center, contain, clip, wrap o smooth
masonry es una metáfora que requiere contexto, por lo que podría ser difícil de recordar para desarrolladores que no hablan inglés- En algunas regiones, este layout se conoce más como
waterfall, así que grid-template-rows: waterfall también podría ser una opción posible
- WebKit considera que esta función se parece más a un mecanismo para “crear una Grid, pero no crear filas” que al layout estilo Pinterest en sí
grid-template-rows: none; podría ser semánticamente adecuado, pero none ya es el valor predeterminado de grid-template-* y significa “no quiero filas explícitas, solo filas implícitas”, por lo que no puede usarse- Como alternativa se propone
grid-template-rows: off;
main {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
grid-template-rows: off;
}
- CSSWG está discutiendo el nombre en este issue
- Actualmente Safari Technology Preview y las demos usan el valor
masonry de acuerdo con el Editor’s Draft, pero el nombre podría cambiar en el futuro
1 comentarios
Opiniones en Hacker News
El contexto es que los responsables de relaciones con desarrolladores del CSSWG de los proveedores de navegadores han estado discutiendo cómo incluir oficialmente el layout Masonry en CSS. Es una discusión que viene al menos desde 2020, cuando Firefox lo propuso por primera vez.
La novedad esta vez es que WebKit llevó esta discusión al ámbito público y pidió a diseñadores y desarrolladores que actuaran, con llamados del tipo “publiquen en redes sociales, escriban posts en blogs”.
Por fuera puede parecer un trámite formal, pero podría sentar un precedente importante. El punto central es si tratar todas las opciones de layout como parte de CSS Grid, o si seguir agregando nuevas propiedades de CSS Display cada vez que haga falta.
Lo primero haría aún más compleja la ya compleja especificación de CSS Grid, y lo segundo podría inflar la especificación de CSS con nuevas propiedades y subpropiedades. Ninguna de las dos opciones es tan fácil como parece.
Grid primero coloca todos los elementos en la cuadrícula, por ejemplo en
col:2,row:3, y luego determina el tamaño de la cuadrícula. Masonry, idealmente, querría primero determinar el tamaño de las pistas y luego colocar los elementos en esas pistas.La primera implementación de Firefox y la especificación de ese momento decían básicamente que, salvo la primera fila y algunas reglas complejas, los elementos Masonry no se tomaban en cuenta para calcular el tamaño de las pistas, por lo que era muy fácil que los elementos terminaran desbordando la pista.
La especificación actual exige probar colocar todos los elementos en todas las pistas posibles. En el peor caso, y además bastante común, eso produce un rendimiento cuadrático de O(N_tracks * N_items), y el rendimiento cuadrático es malo[1]; de hecho, prácticamente no existe algo así en otros algoritmos de layout.
Si además hay anidamiento, el rendimiento se degrada de forma casi exponencial, y que la CPU sea rápida no lo vuelve aceptable. Se podría decir que estos casos no son comunes, pero en los modos de layout de CSS la gente siempre prueba los límites, así que por defecto tienen que ser rápidos.
En Grid, un elemento calcula su propio tamaño de forma distinta según en qué pista quede colocado, por lo que es necesario probar todas las posiciones posibles. Para mitigar este problema, Masonry podría necesitar otro algoritmo para calcular el tamaño de las pistas, pero el post del blog no aborda suficientemente ese punto. Podría haber existido una versión del cálculo de tamaños de Grid sin dependencia de la posición de los elementos, pero ese barco ya zarpó.
[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
En general, con solo usar
grid-row-template: masonry, el resto sigue funcionando bien. Eso es positivo, y no creo que haga que Grid layout sea más difícil de usar de lo que ya es.La desventaja recae principalmente en quienes escriben motores de navegador, porque eleva el estándar de lo que significa “soporte completo de CSS Grid”. También se dice que así se pueden evitar trampas de rendimiento en las que una implementación que debe soportar todas las funciones de Grid puede volverse más lenta en algunos layouts de Grid que si la especificación hubiera sido más simple.
Si hubiera un modo
displayseparado, habría que repetir la especificación degrid-columnpara el layout Masonry, y eso sería una lástima.No está directamente relacionado con CSS Masonry, pero hace poco estuve prototipando una segunda iteración de una interfaz con una tensión similar. La cuestión era si aumentar la cantidad de tipos parecidos pero distintos en el modelo de datos, o si aumentar los matices dentro de los tipos existentes para soportar refinamientos.
Al principio prefería con fuerza lo segundo, pero al explorar opciones en la práctica resultó que consumir una interfaz más “inflada” y luego razonar sobre el código de la aplicación era mucho más simple.
No tengo una postura fuerte sobre CSS Masonry, pero puede haber una sorpresa similar entre la tensión que la gente imagina intuitivamente y cómo se siente en el uso real. En CSS, en particular, puede ser difícil justificar la “inflación”, es decir, el aumento de semánticas específicas por caso de uso, pero también puede ser que los usuarios tiendan a sentir más difíciles las API densas como Grid.
Desde el año pasado lo probé en Firefox y Safari, y no tengo quejas sobre la implementación. Hay gente que se queja de la ubicación y el nombre de las propiedades, pero hay que aceptar que probablemente no exista una solución perfecta e implementarlo de forma pragmática.
Me niego a usar JavaScript como implementación alternativa. Por eso el fallback incluye mucho CSS feo que no logra ordenar correctamente los elementos, pero para el proyecto en el que estoy trabajando no es un gran problema. Hoy la mayoría lo resolvería con JavaScript, pero si la solución para layout es JavaScript, ya estás entrando perdiendo.
La demo del megamenú <https://webkit.org/demos/grid3/megamenu/> realmente no me gusta, y usar Masonry ahí parece completamente inapropiado. Desordena la dirección del flujo y rompe fuertemente las expectativas
Orden de lectura esperado: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Orden que da la demo real: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Afecta el orden de lectura correcto y el índice de tabulación. Los usuarios visuales, en la práctica, casi siempre terminan leyendo en el orden “incorrecto”
Al final muestra que no hay estructura y que es solo una bolsa no estructurada con enlaces. Pero si se sigue el orden numérico, parece que había un orden bastante lógico, que quedó completamente arruinado por aplicar Masonry de forma inapropiada
En la captura de pantalla está activado “mostrar números de elementos”. Normalmente se ve como columnas comunes sin fondo
La implementación debería haber usado columnas y agregar
break-inside: avoida cada sección. En la demo se les pasó estoLa demo del periódico también es algo sospechosa por razones parecidas, pero es un problema mucho menor
Cuando se trata de bloques más independientes, como medios tipo imágenes, y el orden de lectura no está tan profundamente incorporado, el layout Masonry encaja mejor. Aun así, hay algo un poco ambiguo alrededor del índice de tabulación, pero ya no es claramente incorrecto
En un layout Masonry, la expectativa de los usuarios visuales no es que haya continuidad entre columnas, sino que siga las líneas visuales. El orden que presentas como “inesperado” también sigue eso
El problema parece estar en que el orden de tabulación ignora el orden original del contenido e intenta imitar lo visual, y casi con certeza será un vestigio de la forma en que está implementado actualmente
Lo bueno de esta función es que, incluso si ves la demo en un navegador que no la soporta —es decir, en todos los navegadores estables actuales sin activar flags especiales—, como está construida directamente sobre Grid layout, se muestra en un formato de filas fijas bastante razonable: https://webkit.org/demos/grid3/
En cada caso se vería mucho mejor con un layout Masonry correcto, pero aun sin eso es suficientemente usable. Si no te gusta, también puedes detectar la función y ofrecer una visualización alternativa mejor
Me gusta mucho el aspecto y la sensación general del layout Masonry/en cascada. Tal vez porque crecí leyendo periódicos en papel y todavía los leo, los layouts basados en columnas me parecen una forma intuitiva de dividir una página
Dicho eso, me gustaría que hubiera una alternativa a la alineación Masonry predeterminada. Hasta donde sé, la regla básica es algo como “colocar el siguiente elemento en la columna donde pueda quedar más arriba”, y por eso, desde la segunda fila en adelante, el orden de izquierda a derecha se mezcla bastante
Una forma mejor que imagino sería un layout que conserve más el flujo de lectura de izquierda→derecha, o de derecha→izquierda si esa es la dirección preferida. Por ejemplo: “poner el siguiente elemento en la columna a la derecha del elemento anterior; si ya está en la más a la derecha, ponerlo en la más a la izquierda; y, si el nuevo borde inferior no queda demasiado por debajo del límite inferior de la columna izquierda, se puede poner un segundo elemento en la misma columna”
Es más flexible que un izquierda→derecha estricto, así que estropea menos la alineación y también permite conservar en cierta medida el significado de la dirección de lectura izquierda→derecha
En Masonry no se pueden cubrir todas las fórmulas que alguien podría preferir, pero si el contenido tiene aunque sea un poco de importancia en el orden, quizás no para Pinterest pero sí para algo como una revista, creo que este enfoque sería un valor predeterminado más razonable que las reglas clásicas de Masonry
En un layout tipo revista, ¿no se lee primero de arriba→abajo en una columna y luego de izquierda→derecha? En CSS eso ya se puede hacer con
columnso con Flexbox en dirección verticalOtro problema de este layout Masonry es que la parte inferior queda irregular. En una revista probablemente se habría equilibrado, y eso también puede hacerse con columnas o Flexbox
En la web parece haber una suposición oculta de contenido con scroll infinito, por lo que se considera que la forma de la parte inferior de la página no importa. Si es así, no es una suposición que necesariamente haya que fomentar
{ /* al actualizar, mover el elemento como máximo 2 columnas a la izquierda o a la derecha */ grid-template-max-horizontal-shift: 2 col; }Si pudiéramos crear un sistema sin compatibilidad hacia atrás que reemplace a CSS, ¿cómo habría que hacerlo?
¿Hay algún libro o paper sobre cómo crear un sistema de layout coherente?
¿Qué tal alternativas como Qt, Tk o SwiftUI? Nunca he usado otra cosa que no sea CSS. Si entre los sistemas realmente implementados de forma amplia hay alguno mejor, ¿qué lo hace mejor?
Quiero un sistema que les dé a los desarrolladores una mejor interfaz, pero no sé cómo debería ser. Si pudiéramos empezar de cero, ¿cuáles deberían ser los principios de diseño?
Las propiedades deberían ser más explícitas y estar más separadas. Habría que eliminar tonterías como los márgenes negativos, y todas las distancias deberían hacerse en varios niveles. Por ejemplo, algo como
padding = max(el.paddings[])Las cajas de borde deberían ser explícitas, y los bordes deberían convertirse en elementos adecuados. El modelo de caja en sí no es malo; CSS lo implementó de una forma espantosa. Está lleno de hechizos frágiles que se rompen el 99% de las veces que los tocas y de restricciones absurdas, y esas restricciones generan más problemas y “soluciones”
Es un enfoque diseñado para resolver cambios de tamaño y forma de pantalla. Apple pasó a SwiftUI y puede que haya dejado atrás este enfoque
Flutter y XAML también parecen candidatos que valdría la pena revisar
Lo vuelvo a publicar como comentario de nivel superior para que se vea mejor
Tengo un sitio web de fotografía y no uso JavaScript para el layout. Cuando lo hice, evalué librerías JavaScript de Masonry, pero el resultado no me satisfizo
Un layout Masonry bien hecho que realmente llene todo el espacio disponible recorta algunas imágenes. Si quieres mantener la relación de aspecto sin recortar, tienes que dejar espacios alrededor de las fotos. La única forma de no hacer eso es con scroll infinito, que quizá sea lo que quieren esas máquinas corporativas de adicción, pero no es lo que quiero en mi sitio web
Lo hice así:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Para obtener este resultado usé
display:inline-block, tratando las fotos como si fueran texto que debe refluir a una nueva línea. Estoy muy satisfecho con el resultado y lo prefiero a la forma en que lo hacen las librerías MasonryEl problema es el orden. Si el orden no importa, las soluciones actuales solo con CSS también funcionan bien. Aunque, si no recuerdo mal, pueden dejar formas raras en la parte inferior de las columnas
Relacionado con esto, hice una demo interactiva que cubre los principios de Grid:
https://cssprinciples.com/3/grid/
Ya existen los
floattradicionales y también los layouts modernos con Flexbox y Grid, así que me pregunto si tiene sentido seguir agregando opciones de “layout” a CSS.Si todavía hay casos que no están cubiertos, quizá una mejor solución sería tener un último sistema basado en restricciones que cubra todos los casos de layout, aunque eso agregue complejidad. Así, los frameworks CSS y las bibliotecas de utilidades podrían construir encima de eso cosas como la próxima generación de Masonry Grid.
Aun así, la propuesta de layout de Houdini es lo más cercano a esta idea. Consiste en pasar el layout a un contexto de JavaScript aislado: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
Pero, honestamente, como Flexbox, Grid y cosas como
containmentya resolvieron muchos problemas, la demanda de mejoras es mucho menor que en la época previa a Flexbox.floato hacks de CSS Grid/Flexbox que pronto quedarán obsoletos. El layout Masonry de Firefox en realidad agrega una nueva propiedad que colapsa las filas de Grid, así que en la práctica está implementado de una forma que cubre todos los casos de layout.display: grid;grid-template-rows: masonry;Pero está limitado a WebKit. Lo implementé en el modo galería de mi feed de noticias personal y ya lo descarté en octubre de 2023.
Un sistema basado en restricciones probablemente quedaría en un punto incómodo entre Grid y JavaScript, así que no sé si ayudaría demasiado.
Ya estoy usando esto. En Firefox lo activo en las opciones y lo uso para los marcadores. En móvil simplemente se apilan de arriba abajo, así que no es un problema. En móvil no hay
about:config.La última imagen muestra el estado desactivado.
https://imgur.com/a/o7OyZEW
Por eso, al cambiar el tamaño de la ventana, cambiará el orden de los marcadores.
Para más contexto y los argumentos del otro lado —es decir, por qué
display: masonrysería mejor quedisplay:grid+grid-template-rows: masonry— se puede ver esta discusión en detalle: https://github.com/w3c/csswg-drafts/issues/9041