- WebKit sollicite les retours des designers et développeurs sur la standardisation, dans CSS Grid Level 3, de la mise en page masonry/waterfall, un sujet longtemps délicat en CSS
- Le modèle proposé repose sur
display: grid avec grid-template-rows: masonry pour désactiver la génération des lignes et remplir les espaces vides avec le contenu, comme des briques
- Apple estime que cette fonctionnalité doit rester dans Grid afin de se combiner avec les capacités existantes comme
fr, minmax(), max-content, le spanning, le placement explicite et subgrid
- Une approche séparée via
display: masonry pourrait simplifier la séparation des types de mise en page, mais risquerait, dans les discussions actuelles, de se limiter à des colonnes de même largeur et de rendre plus difficile l’usage des capacités de dimensionnement des tracks de Grid
- Depuis la mise à jour d’octobre 2024, le CSS Working Group a conclu qu’il valait la peine d’intégrer à masonry les tracks à largeur variable, le placement explicite, le spanning et
subgrid, et que leur implémentation restait possible en termes de performance, mais la discussion sur la syntaxe continue
Position actuelle de CSS Grid Level 3
- Depuis la mise à jour d’octobre 2024, un Working Draft officiel du W3C pour CSS Grid Layout Module Level 3 a été publié, documentant le fonctionnement de la mise en page masonry
- Les membres du CSS Working Group ont conclu qu’il valait la peine d’inclure les fonctionnalités suivantes dans la mise en page masonry, et qu’elles pouvaient être implémentées de manière performante
- tracks à largeur variable
- placement explicite
- spanning
subgrid
- Le débat sur la syntaxe reste toutefois ouvert, et WebKit le poursuit dans un billet séparé, Help us choose the syntax for Masonry in CSS
Pourquoi une mise en page masonry est nécessaire
- CSS Grid Level 1, introduit en 2017, a réduit la complexité de dimensionnement et de placement des mises en page basées sur les floats, et Grid Level 2 a apporté Subgrid
- Mais même après l’arrivée de CSS Grid, la question « comment écrire une mise en page masonry en CSS ? » est restée sans réponse claire pendant 7 ans
- La mise en page masonry est un motif où les contenus s’imbriquent comme des briques ou un mur de pierres, d’où l’appellation waterfall layout
- Comme elle peut gérer des contenus aux ratios différents, elle réduit le besoin de rogner ou redimensionner tous les éléments pour les faire entrer dans les mêmes rectangles
- Le contenu étant réparti sur toute la page, l’ordre de lecture reste naturel au défilement, et l’ajout de contenu en lazy-load en bas de page ne nécessite pas de déplacer le contenu existant
Historique de la proposition et débat sur la standardisation
- Le mécanisme permettant de créer une mise en page masonry en CSS a été proposé pour la première fois par Mozilla en janvier 2020 comme extension de CSS Grid, puis implémenté derrière un flag expérimental dans Firefox Nightly
- Apple a commencé en 2022 à implémenter la proposition CSS Grid Level 3 dans Safari Technology Preview, où elle est désormais activée par défaut
- Au sein du CSS Working Group, il existait des divergences sur l’orientation de base
- pour certains, masonry ne devait pas faire partie de CSS Grid mais être un type de
display distinct
- d’autres doutaient de la nécessité réelle de cette mise en page sur le Web, ou de son adoption par des sites majeurs
- WebKit considère qu’avant toute sortie de cette fonctionnalité dans les navigateurs, un consensus du CSS Working Group est nécessaire
Usage de base : un Grid sans lignes, avec seulement des colonnes
- Une mise en page masonry/waterfall classique s’écrit en appliquant
display: grid à l’élément main, en définissant les colonnes, puis en assignant la valeur masonry à l’axe des lignes
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)) crée une répétition de colonnes flexibles avec une largeur minimale de 14remgap: 1rem crée un espacement de 1rem entre les colonnes et les élémentsgrid-template-rows: masonry indique au navigateur de ne pas créer de lignes et de remplir le contenu selon un motif masonry/waterfall- Cet exemple produit, avec quatre lignes de CSS et sans media queries ni container queries, une mise en page souple adaptée à différentes tailles d’écran
- Le nom de valeur
masonry pourrait encore changer avant la sortie dans les navigateurs
Pourquoi conserver la capacité de définition des colonnes de Grid
- Pour montrer pourquoi masonry devrait faire partie de CSS Grid, WebKit a créé quatre démos, testables directement sur webkit.org/demos/grid3
- Les démos sont visibles dans les navigateurs qui prennent en charge Grid Level 3
- CSS Grid offre de nombreuses options pour définir les colonnes
- tailles fixes dans diverses unités comme
px, em, rem, cqi, lh, ch, ic, cap, vw, svh
max-content, min-content- unité
fr
minmax()- tailles en
%
auto
- Par exemple, on peut fixer la première et la dernière colonne à 14ch, et faire des colonnes centrales flexibles avec un minimum de 28ch
main {
display: grid;
grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
grid-template-rows: masonry;
gap: 1rem;
}
- Combiner l’unité
fr avec minmax() permet de créer une flexibilité en deux temps, où les colonnes s’étendent et se contractent à des rythmes différents
max-content et min-content permettent d’ajuster la taille des colonnes au contenu, ouvrant la voie à des compositions différentes de celles où l’on adapte le contenu à la colonne- Il est même possible de créer des colonnes de largeurs différentes avec une suite de Fibonacci, comme
grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr;
- L’exemple de mega menu utilise
grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch)); pour que chaque colonne puisse contenir le texte des liens sans retour à la ligne
- WebKit estime que la discussion autour d’un
display: masonry séparé s’oriente aujourd’hui, comme pour le multicolumn layout, vers des colonnes de taille identique uniquement
Spanning, View Transitions et columnar grid
- CSS Grid permet aux éléments de s’étendre sur plusieurs colonnes, ce qui autorise diverses compositions visuelles dans une disposition masonry
- Dans l’exemple, chaque 5e image peut s’étendre sur deux colonnes, tandis que les autres n’en occupent qu’une
- On peut aussi attribuer une classe
wider aux images au ratio plus large pour les faire s’étendre sur plusieurs colonnes, ou encore varier la présentation en rendant les coins carrés ou en réduisant le gap à 0
- La démo Photos combine cette approche avec View Transitions : quand l’utilisateur clique ou touche une photo, celle-ci s’agrandit sur plusieurs colonnes et le navigateur anime automatiquement la transition
- cette démo nécessite Safari Technology Preview 192 ou supérieur
- WebKit considère que le cœur de Grid Level 3 n’est pas tant le motif spécifique masonry que le mécanisme de désactivation des lignes
- Cette approche crée un columnar grid, composé uniquement de colonnes, par opposition au modular grid que CSS Grid Level 1 produit très bien avec ses lignes et colonnes alignées
Différence entre modular grid et columnar grid
- Un modular grid est une grille où le contenu s’aligne à la fois sur les colonnes et sur les lignes, et CSS Grid Level 1 convient bien à ce type de disposition
- Les mises en page à base de floats encourageaient elles aussi l’usage de modular grids, car il fallait harmoniser les hauteurs de contenu pour que les floats se comportent correctement
- Sur les sites réels, on uniformise souvent les ratios des images, la longueur des textes, ou l’on fait rentrer le contenu dans des boîtes identiques via des politiques CMS, du rognage CSS ou des points de suspension
- Un columnar grid permet au contraire de laisser le contenu conserver la taille qu’il souhaite, et de faire travailler la mise en page autour de ce contenu
- WebKit estime qu’il est aussi possible de rendre un contenu textuel plus vivant, par exemple en faisant occuper quatre colonnes aux derniers articles, deux colonnes à certains articles récents, et une seule aux contenus plus anciens
Combiner subgrid et placement explicite
- Le subgrid de CSS Grid Level 2 est pris en charge par la plupart des navigateurs
- Dans l’exemple d’une page de musée, au lieu de lister les métadonnées des cartes d’œuvres dans une seule colonne alignée à gauche,
subgrid place l’année et le numéro de catalogue à droite de chaque carte tout en les alignant avec les mêmes informations des autres cartes
- Si masonry entre dans CSS Grid Level 3, les outils de développement existants continueront de fonctionner tels quels
- il est possible de tester
grid-template-rows: masonry dans le Grid Inspector de Safari Technology Preview
- Avec un type de display séparé, on perdrait les avantages de
subgrid
- On peut aussi combiner le placement explicite de CSS Grid Level 1 : dans l’exemple,
grid-column: -3 / -1 place l’en-tête en haut à droite de la page, sur les deux dernières colonnes
- WebKit estime qu’avec quelques lignes de code de mise en page, on peut combiner des fonctionnalités de Grid Level 1, 2 et 3 pour créer une disposition dont le nombre de colonnes varie selon l’espace disponible, sans media queries ni container queries
Les points de débat autour de display: masonry
- WebKit et Apple considèrent que Masonry est une extension de CSS Grid permettant de créer non seulement des modular grids mais aussi des columnar grids
- Dans cette approche, on peut utiliser les définitions de colonnes, le track spanning, le placement explicite et
subgrid avec cette mise en page
- Les partisans d’un type de display séparé estiment, eux, qu’il permet de distinguer plus proprement les types de mise en page
display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;
- Le CSS Working Group n’a pas encore discuté de la syntaxe d’un type de display Masonry séparé, mais WebKit cite comme exemples une syntaxe proche du multicolumn layout ou une syntaxe de type Grid plus limitée
main {
display: masonry;
columns: 28ch;
}
main {
display: masonry;
masonry-columns: repeat(5, minmax(28ch, 1fr));
/* where only one repeating width is allowed */
}
- Un type de mise en page séparé éviterait le travail nécessaire pour continuer à faire évoluer Grid et Masonry ensemble
- le modèle de mise en page serait plus simple
- l’implémentation navigateur serait plus facile
- les risques de pièges de performance seraient réduits
- les ensembles de fonctionnalités de Grid et de Masonry pourraient diverger
- À l’inverse, WebKit estime que relier les deux types de grille pousse le CSS Working Group à définir les futures fonctionnalités pour les modular grids comme pour les columnar grids
- Par exemple, si CSS Grid Level 4 ajoutait des fonctions comme le stylage des grid areas et des grid lines, des couleurs d’arrière-plan pour les tracks, ou des rule lines pour les gaps, il serait préférable qu’elles fonctionnent dès le départ sur les deux types de grille
Comment définir « Grid »
- Les partisans d’un
display: masonry séparé considèrent parfois que CSS Grid est fondamentalement un système d’alignement bidimensionnel, tandis que masonry n’aligne que dans une seule direction et ne serait donc pas un Grid
- WebKit rappelle que, dans l’histoire du graphisme, une grille est un outil servant à organiser texte, images et contenu selon des motifs réguliers pour améliorer lisibilité et utilisabilité
- Bien avant que les modernistes européens et américains du XXe siècle n’imposent l’alignement sur colonnes et lignes comme le « vrai » graphic design grid, de nombreuses formes de grilles existaient déjà
- Mark Boulton jugeait les columnar grids symétriques trop formels et ennuyeux, et encourageait l’usage de compound grids asymétriques en web design
- CSS Grid Level 1 a facilité la création de grilles asymétriques et de compound grids, mais aujourd’hui seulement lorsqu’il s’agit de modular grids
- WebKit considère que modular grids et columnar grids sont tous deux des grids, et que CSS Grid devrait aussi pouvoir créer des columnar grids
Les retours demandés aux développeurs et designers
- WebKit invite les développeurs et designers à créer eux-mêmes des démos, à publier leur avis sur leur blog ou les réseaux sociaux, et à commenter les issues du CSS Working Group
- Les questions posées pour recueillir des retours sont les suivantes
- la mise en page « masonry »/« waterfall » doit-elle faire partie de CSS Grid ?
- faut-il des fonctionnalités de columnar grid incluant
subgrid, le spanning, le placement explicite et divers modes de dimensionnement des tracks ?
- une mise en page masonry classique à colonnes de taille identique suffit-elle ?
- utiliseriez-vous réellement cette fonctionnalité, et pour construire quoi ?
- avez-vous un lien vers une démo que vous avez réalisée ?
- y a-t-il des choses impossibles à faire avec ce modèle ?
- L’équipe WebKit travaille sur Masonry depuis un an et demi, et la fonctionnalité a été activée par défaut dans Safari Technology Preview 163 en février 2023
- WebKit aimerait la livrer prochainement, mais les détails, y compris le nom, ainsi que certaines questions de fond, doivent d’abord être résolus
Débat sur le nom : masonry, waterfall, off
- WebKit estime que
masonry n’est probablement pas le meilleur nom pour cette nouvelle valeur
- En CSS, les noms décrivent souvent directement le résultat avec des mots simples comme
center, contain, clip, wrap, smooth
masonry est une métaphore qui demande une explication de contexte, et pourrait être difficile à retenir pour des développeurs non anglophones- Dans certaines régions, cette mise en page est davantage appelée
waterfall, ce qui ferait de grid-template-rows: waterfall un candidat possible
- WebKit considère que cette fonctionnalité se rapproche moins d’une mise en page à la Pinterest que d’un mécanisme disant « créez une Grid, mais ne créez pas de lignes »
grid-template-rows: none; serait sémantiquement adapté, mais none est déjà la valeur par défaut de grid-template-*, avec le sens « pas de lignes explicites, seulement des lignes implicites », donc elle ne peut pas être réutilisée- Comme alternative,
grid-template-rows: off; a été proposé
main {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
grid-template-rows: off;
}
- Le CSSWG discute du nom dans cette issue
- Pour l’instant, Safari Technology Preview et les démos utilisent la valeur
masonry conformément à l’Editor’s Draft, mais le nom pourrait changer à l’avenir
1 commentaires
Avis sur Hacker News
Le contexte, c’est que les responsables des relations développeurs du CSSWG discutent depuis un moment de la manière d’inclure officiellement la mise en page Masonry dans CSS. La discussion remonte au moins à 2020, quand Firefox l’a proposée pour la première fois
La nouveauté ici, c’est que WebKit a fait sortir publiquement ce débat et a demandé aux designers et développeurs de passer à l’action, en mode « publiez sur les réseaux sociaux, écrivez des billets de blog »
En apparence, cela peut ressembler à une procédure formelle, mais cela pourrait devenir un précédent important. Le point central est de savoir s’il faut traiter toutes les options de mise en page comme faisant partie de CSS Grid, ou continuer à ajouter de nouvelles propriétés CSS Display à chaque besoin
La première option complexifie encore une spécification CSS Grid déjà complexe, la seconde risque de gonfler les spécifications CSS avec de nouvelles propriétés et sous-propriétés. Dans les deux cas, ce n’est pas aussi simple que ça en a l’air
Grid place d’abord tous les éléments dans la grille, par exemple en les positionnant comme
col:2,row:3, puis détermine la taille de la grille. Masonry, idéalement, voudrait d’abord fixer la taille des pistes, puis y placer les élémentsLa première implémentation de Firefox et la spécification de l’époque disaient en gros que, sauf pour la première ligne et quelques règles complexes, les éléments Masonry n’étaient pas pris en compte dans le calcul de la taille des pistes, ce qui faisait qu’il était très facile pour les éléments de déborder des pistes
La spécification actuelle exige d’essayer de placer tous les éléments dans toutes les pistes possibles. Dans le pire cas — et il est assez courant — on obtient une complexité quadratique en O(N_tracks * N_items), et les performances quadratiques sont mauvaises[1] ; on ne voit pratiquement rien de tel dans les autres algorithmes de mise en page
Avec l’imbrication, les performances se dégradent de façon quasi exponentielle, et même avec un CPU rapide ce n’est pas bon. On peut dire que ces cas ne sont pas fréquents, mais en matière de modes de mise en page CSS, les gens testent toujours les limites, donc il faut que ce soit rapide par défaut
Dans Grid, la taille propre des éléments peut varier selon la piste dans laquelle ils sont placés, ce qui oblige à tester toutes les positions possibles. Pour atténuer ce problème dans Masonry, il pourrait falloir un autre algorithme de calcul de la taille des pistes, mais le billet de blog n’aborde pas suffisamment ce point. Il aurait peut-être pu exister une version du calcul de taille de Grid sans dépendance à la position des éléments, mais c’est trop tard maintenant
[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
En gros, il suffit d’utiliser
grid-row-template: masonryet le reste continue de bien fonctionner. C’est un bon point, et cela ne rendrait probablement pas la mise en page Grid plus difficile à utiliser qu’aujourd’huiLes inconvénients concernent surtout les auteurs de moteurs de navigateur. Le seuil pour revendiquer une « prise en charge complète de CSS Grid » devient plus élevé. On dit aussi qu’une implémentation qui doit prendre en charge toutes les fonctionnalités de Grid peut éviter certains pièges de performance qui pourraient autrement ralentir certaines mises en page Grid par rapport à une spécification plus simple
Avec un mode display séparé, il faudrait répéter la spécification de
grid-columnpour la mise en page Masonry, ce qui serait dommageCe n’est pas directement lié à CSS Masonry, mais j’ai récemment prototypé une deuxième itération d’une interface qui présentait une tension similaire. Il s’agissait de choisir entre multiplier des types similaires mais différents dans le modèle de données, ou ajouter davantage de nuances à l’intérieur des types existants pour permettre plus de raffinement
Au départ, je préférais nettement la seconde approche, mais en explorant concrètement les options, il s’est avéré qu’il était bien plus simple de consommer une interface « gonflée » et d’en déduire ensuite le code applicatif
Je n’ai pas d’opinion tranchée sur CSS Masonry, mais il pourrait y avoir une surprise comparable entre la tension que les gens perçoivent intuitivement et ce que cela donne réellement à l’usage. CSS a sans doute encore plus de mal à justifier ce « gonflement », c’est-à-dire l’ajout de sens spécifiques à chaque cas d’usage, mais les utilisateurs peuvent aussi trouver une API dense comme Grid plus difficile à appréhender
Je teste ça sur Firefox et Safari depuis l’an dernier, et je n’ai pas de reproche à faire à l’implémentation. Certains râlent sur l’emplacement et le nom de la propriété, mais il faut sans doute accepter qu’il n’existe pas de solution parfaite et avancer avec une implémentation pragmatique
J’exclus d’utiliser JavaScript pour une implémentation de remplacement. Donc la solution alternative implique beaucoup de CSS peu esthétique qui n’aligne pas correctement l’ordre, mais ce n’est pas un gros problème dans le projet sur lequel je travaille. Aujourd’hui, la plupart des gens passeraient plutôt par un remplacement en JavaScript, mais si la solution au layout est JavaScript, alors c’est déjà une défaite
La démo de méga-menu <https://webkit.org/demos/grid3/megamenu/> ne me plaît vraiment pas, et utiliser Masonry à cet endroit semble totalement inapproprié. Cela met complètement le sens de lecture en pagaille et trahit fortement les attentes
Ordre de lecture attendu : https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Ordre donné par la démo réelle : https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Cela affecte le bon ordre de lecture et l’index de tabulation. Pour les utilisateurs visuels, la lecture se fera pratiquement toujours dans le « mauvais » ordre
Au final, cela montre qu’il ne s’agit que d’un sac informe de liens sans structure. Pourtant, en suivant l’ordre numéroté, on voit qu’il y avait un ordre assez logique, complètement détruit par cette masonryisation inappropriée
Sur les captures d’écran, l’option « afficher le numéro des éléments » était activée. Normalement, cela ressemble à de simples colonnes sans arrière-plan
L’implémentation aurait dû utiliser des colonnes tout en ajoutant
break-inside: avoidà chaque section. La démo est passée à côté de ce pointLa démo du journal est elle aussi un peu discutable pour des raisons similaires, mais le problème est bien moindre
Une disposition Masonry convient mieux à des blocs plus indépendants, comme des médias de type image, où l’ordre de lecture n’est pas aussi profondément ancré. Il reste tout de même une petite zone grise autour de l’index de tabulation, mais ce n’est plus manifestement faux
Dans une disposition Masonry, l’attente d’un utilisateur visuel n’est pas une continuité entre les colonnes, mais une continuité le long des lignes visuelles. Même l’ordre présenté comme « inattendu » suit cette logique
Le problème semble venir du fait que l’ordre de tabulation essaie d’imiter le visuel en ignorant l’ordre du contenu source, et c’est presque certainement une trace de l’implémentation actuelle
Ce qu’il y a de bien avec cette fonctionnalité, c’est que même si l’on regarde les démos dans un navigateur qui ne la prend pas en charge — autrement dit, dans tous les navigateurs stables actuels sans activer de flag spécial — elles s’affichent sous une forme à lignes fixes assez raisonnable, puisqu’elles ont été construites directement sur une mise en page Grid : https://webkit.org/demos/grid3/
Dans chaque cas, une vraie disposition Masonry serait bien plus agréable visuellement, mais même sans cela, cela reste tout à fait utilisable. Et si ça ne convient pas, on peut toujours faire de la détection de fonctionnalité et proposer un affichage de repli plus adapté
J’aime vraiment l’apparence générale et le ressenti des dispositions Masonry / en cascade. J’ai grandi en lisant des journaux papier et j’en lis encore, donc une mise en page basée sur des colonnes me semble une manière intuitive de découper une page
Cela dit, j’aimerais qu’il existe une alternative à l’algorithme d’alignement Masonry par défaut. Si je comprends bien, la règle par défaut consiste à « placer l’élément suivant dans la colonne où il peut être placé le plus haut », ce qui fait qu’à partir de la deuxième rangée, l’ordre gauche-droite est fortement mélangé
La meilleure approche que j’imagine serait une disposition qui préserve davantage le flux de lecture gauche→droite — ou droite→gauche si c’est la direction préférée. Par exemple : « placer l’élément suivant dans la colonne à droite de l’élément précédent, mais si on est déjà dans la colonne la plus à droite, revenir à la plus à gauche ; et si le nouveau bas ne descend pas trop sous la limite inférieure de la colonne de gauche, on peut placer un deuxième élément dans cette même colonne »
Ce serait plus souple qu’un strict gauche→droite, cela abîmerait moins l’alignement, tout en conservant dans une certaine mesure le sens d’une lecture gauche→droite
On ne pourra pas couvrir toutes les formules qu’on pourrait souhaiter pour Masonry, mais pour des contenus où l’ordre a ne serait-ce qu’un peu d’importance — peut-être pas Pinterest, mais par exemple un journal — cela me semblerait un réglage par défaut plus raisonnable que les règles Masonry classiques
Pour une mise en page de type magazine, ne lit-on pas d’abord les colonnes de haut en bas, puis de gauche à droite ? En CSS, c’est déjà possible avec
columnsou avec une Flexbox verticaleUn autre problème de cette disposition Masonry, c’est que le bas est irrégulier. Dans un magazine, on l’aurait probablement aligné de façon uniforme, ce qu’on peut aussi faire avec des colonnes ou Flexbox
Sur le web, il semble y avoir l’hypothèse implicite d’un contenu à défilement infini, donc l’apparence du bas de page n’aurait pas d’importance. Ce n’est pas forcément une hypothèse qu’il faut encourager
{ /* lors des mises à jour, limiter le déplacement horizontal des éléments à 2 colonnes max */ grid-template-max-horizontal-shift: 2 col; }Si l’on pouvait créer un système sans compatibilité descendante pour remplacer CSS, comment faudrait-il s’y prendre ?
Existe-t-il des livres ou des articles sur la façon de concevoir un système de mise en page cohérent ?
Que valent des alternatives comme Qt, Tk ou SwiftUI ? Je n’ai rien utilisé d’autre que CSS. S’il existe des systèmes réellement largement implémentés et meilleurs, en quoi sont-ils meilleurs ?
Je veux un système qui offre une meilleure interface aux développeurs, mais je ne sais pas comment m’y prendre. Si l’on pouvait repartir de zéro, quels devraient être les principes de conception ?
Les propriétés devraient être plus explicites et mieux séparées. Il faudrait se débarrasser d’absurdités comme les marges négatives, et faire en sorte que toutes les distances soient multiniveaux. Par exemple, quelque chose comme
padding = max(el.paddings[])Les boîtes de bordure devraient être explicites, et les bordures devraient être de vrais éléments. Le modèle de boîte n’est pas mauvais en soi ; c’est CSS qui en a fait une implémentation affreuse. C’est rempli de sortilèges fragiles qui cassent à 99 % dès qu’on y touche, et de limitations absurdes qui engendrent encore plus de problèmes et de « solutions »
C’est une approche conçue pour résoudre les variations de taille et de forme de l’écran. Apple est passé à SwiftUI et a peut-être abandonné cette approche
Flutter et XAML semblent aussi valoir le détour
Je republie ceci comme commentaire de premier niveau pour que ce soit plus visible
J’ai un site de photographie, et je n’utilise pas JavaScript pour la mise en page. Au moment de le créer, j’ai examiné des bibliothèques JavaScript de type Masonry, mais les résultats ne me satisfaisaient pas
Une vraie mise en page Masonry qui remplit réellement tout l’espace disponible recadre certaines images. Si l’on veut éviter le recadrage et préserver le ratio d’aspect, il faut laisser des espaces autour des photos. La seule manière de ne pas le faire, c’est le défilement infini ; c’est peut-être ce que veulent les machines à addiction des grandes entreprises, mais ce n’est pas ce que je veux pour mon site
J’ai fait comme ceci :
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Pour obtenir ce résultat, j’ai utilisé
display:inline-block, en traitant en quelque sorte les photos comme du texte qui doit se redisposer sur une nouvelle ligne. Je suis très satisfait du résultat et je le préfère à ce que font les bibliothèques MasonryLe problème, c’est l’ordre. Si l’ordre n’a pas d’importance, les solutions actuelles uniquement en CSS fonctionnent aussi bien. Mais, si je me souviens bien, elles peuvent laisser des formes étranges en bas des colonnes
J’ai aussi créé une démo interactive sur les principes de Grid en lien avec ce sujet :
https://cssprinciples.com/3/grid/
Il existe déjà les anciens
float, ainsi que les layouts modernes Flexbox et Grid, donc on peut se demander s’il est vraiment pertinent de continuer à ajouter des options de « layout » à CSSS’il reste encore des cas non couverts, une meilleure solution serait peut-être, même au prix d’une plus grande complexité, d’avoir un dernier système à base de contraintes capable de couvrir tous les cas de figure de layout. Les frameworks CSS et les bibliothèques utilitaires pourraient alors construire par-dessus des Masonry Grid de nouvelle génération, etc.
Cela dit, la proposition de layout Houdini est ce qui se rapproche le plus de cette idée. Elle consiste à déléguer le layout à un contexte JavaScript isolé : https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
Mais honnêtement, Flexbox, Grid et des choses comme
containmentont déjà résolu beaucoup de problèmes, donc les demandes d’amélioration sont bien moins nombreuses qu’avant l’époque de Flexboxfloatou les hacks CSS Grid/Flexbox qui deviendront bientôt obsolètes. Le layout Masonry de Firefox est en fait implémenté en ajoutant une seule nouvelle propriété qui replie les lignes de Grid, ce qui fait qu’en pratique il couvre quasiment tous les cas de layoutdisplay: grid;grid-template-rows: masonry;Mais cela reste limité à WebKit. Je l’avais implémenté dans le mode galerie de mon fil d’actualité personnel, puis je l’ai déjà abandonné en octobre 2023
Un système à base de contraintes se situerait probablement de façon assez maladroite quelque part entre Grid et JavaScript, donc je ne sais pas à quel point cela aiderait vraiment
J’utilise déjà ça. Dans Firefox, je l’active dans les options et je m’en sers pour les marque-pages. Sur mobile, ils s’empilent simplement de haut en bas, donc ce n’est pas gênant. Il n’y a pas de
about:configsur mobileLa dernière image est avec l’option désactivée
https://imgur.com/a/o7OyZEW
Donc, si on redimensionne la fenêtre, l’ordre des marque-pages changera
On peut voir ici davantage de contexte et l’argument opposé, à savoir pourquoi
display: masonryserait préférable àdisplay:grid+grid-template-rows: masonry: https://github.com/w3c/csswg-drafts/issues/9041