Comme promis dans un précédent article, je me propose de décortiquer au plus prêt le fameux « Masonry » (le style « mur de briques » ou Pinterest), mais version 2026. Imagine que tu veux ranger tes Lego ou tes cartes Pokémon sur une table, mais ils n’ont pas tous la même taille. Avant, c’était un vrai casse-tête pour les ordinateurs. Maintenant, on a une baguette magique appelée Grid Lanes.
Pour certains d’entre vous cela pourra sembler un peu alambiquer mais sachez que j’ai essayé d’être le plus clair possible. Des questions ? Le forum Discord est pas loin.
Genèse et évolution d’un paradigme de mise en page
Le terme « masonry » ou « waterfall » (cascade) désigne un agencement où les éléments, souvent des images ou des résumés d’articles de hauteurs variables, sont empilés dans des colonnes de manière à minimiser les espaces vides verticaux. Contrairement à une grille traditionnelle où les lignes horizontales sont alignées sur tout le conteneur, le layout masonry permet à chaque colonne de progresser de manière indépendante. (voir l’exemple dans la vidéo ci-dessous).
Cette approche a été popularisée par David DeSandro et sa bibliothèque Masonry.js, qui a défini l’esthétique du web visuel des années 2010. Cependant, cette solution logicielle imposait une charge de calcul importante au navigateur, car elle nécessitait de manipuler le positionnement absolu des éléments via JavaScript. Le besoin d’une solution native a conduit à une période de débats intenses au sein du W3C. Dès 2020, Mozilla a proposé une implémentation basée sur l’extension de la grille existante, tandis que d’autres acteurs comme Google et Apple exploraient des approches divergentes.
La guerre des syntaxes et la résolution finalisée
Entre 2020 et 2025, le CSSWG a été le théâtre d’une opposition entre deux philosophies majeures. D’un côté, le modèle « Just Use Grid », et de l’autre, le modèle « New Display », poussé par l’équipe Chromium.
| Période | Acteur Principal | Proposition de Syntaxe | Argument Clé |
| 2020 | Mozilla (Firefox) | grid-template-rows: masonry | Extension naturelle de CSS Grid. |
| 2022 | Apple (WebKit) | Intégration dans Grid Level 3 | Réutilisation des outils Grid. |
| 2024 | Google (Chromium) | display: masonry | Modèle mental plus simple. |
| Janvier 2025 | CSSWG (W3C) | display: grid-lanes | Résolution unifiée réutilisant les propriétés de grille. |
La résolution du 31 janvier 2025 a tranché pour display: grid-lanes. Ce choix évoque la métaphore d’une autoroute où les véhicules (items) de longueurs différentes circulent dans des voies parallèles sans être contraints par la position des véhicules dans les voies adjacentes.
Analyse technique : Comment ça marche ?
La mise en place de CSS Masonry via grid-lanes repose sur une hybridation des concepts de pistes (tracks) issus de la grille et de flux (flow) issus de flexbox. Plus d’information ici.
| Propriété | Rôle dans Grid Lanes | Comportement Masonry |
display: grid-lanes | Déclencheur du mode | Active le contexte de formatage masonry. |
grid-template-columns | Définition des voies | Fixe la largeur et le nombre de colonnes. |
gap | Espacement | Gère les gouttières horizontales et verticales. |
item-pack | Algorithme de remplissage | Détermine si le placement est dense ou séquentiel. |
L’algorithme de placement est dynamique. Pour chaque élément, le navigateur identifie la colonne la plus courte (shortest running position). Si l’élément s’étend sur plusieurs colonnes (via grid-column: span X), il calcule la position maximale pour éviter les chevauchements. La nouvelle position est calculée selon la formule : $Position + Taille + Gouttière$.
Le système unifié Item Flow et la tolérance
L’objectif est de regrouper les capacités de Flexbox et Grid dans un ensemble de propriétés cohérent, préfixé par item-.
item-pack: balance: À l’instar detext-wrap: balance, cette propriété demande au navigateur de répartir les items pour que les colonnes soient de longueurs égales.flow-tolerance: Pour illustrer cela, imagine le trafic routier. Par défaut, un item change de voie dès qu’il gagne un pixel. En réglant une tolérance (ex:1em), on n’autorise un changement que si le gain d’espace est significatif, préservant ainsi l’ordre de lecture.
Cas pratique : Ton blog « Zéro espace vide »
Voici le modèle de référence pour un layout masonry moderne et accessible pour un blog d’actualités ou une galerie photo.
CSS
Un contenu de qualité, sans publicité.
Vous aimez notre travail ? Soutenez notre indépendance en devenant membre sur Patreon.
Soutenir MyChromebook.fr.blog-gallery {
/* Activation du layout Masonry / Grid Lanes */
display: grid-lanes;
/* Définition des colonnes réponsives sans media queries */
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
/* Espacement uniforme */
gap: 1.5rem;
/* Correction de l'ordre de lecture pour l'accessibilité */
reading-flow: grid-columns;
/* Ajustement de la tolérance pour stabiliser l'ordre de lecture */
flow-tolerance: 1em;
/* On force le remplissage intelligent */
item-pack: dense;
}
.article-card {
/* Pour éviter les sauts de layout, on impose un ratio d'aspect */
aspect-ratio: var(--ratio, 1/1);
}
/* Un article à la "Une" qui s'étend sur deux colonnes */
.featured {
grid-column: span 2;
}
État du support et performance
En ce début 2026, le support est en phase de stabilisation rapide.
| Navigateur | Version de support (Exp.) | Flag / Configuration | Syntaxe |
| Safari | Safari TP 234+ | Activé par défaut en TP | display: grid-lanes |
| Chrome | v140+ | chrome://flags/#layout-masonry | display: grid-lanes |
| Firefox | v77+ | layout.css.grid-template-masonry-value.enabled | grid-template-rows: masonry |
Le passage au natif élimine la surcharge JavaScript (on gagne 0 ko sur la page !). Le calcul est déplacé vers le moteur C++ du navigateur, offrant une fluidité totale même sur mobile. C’est aussi une bénédiction pour le Rendu Côté Serveur (SSR) : plus de sauts visuels au chargement puisque le layout est purement déclaratif. Avec la version 143.0.7499.203 de ChromeOS, on commence à avoir quelque chose de solide qui se met en place
Défis : Accessibilité et SEO
Le masonry rompt la linéarité. L’élément numéro 6 peut se retrouver au-dessus du numéro 4. Pour régler ça, le W3C a introduit reading-flow.
| Valeur de reading-flow | Comportement pour Grid Lanes |
normal | Suit l’ordre source du DOM (par défaut). |
grid-rows | Le focus traverse les items rangée par rangée visuelle. |
grid-columns | Le focus traverse les items colonne par colonne visuelle. |
Côté SEO, l’utilisation de grid-lanes avec aspect-ratio permet de bloquer l’espace avant le chargement des images, ramenant le score CLS (Cumulative Layout Shift) à zéro. En supprimant les scripts bloquants, on améliore aussi le LCP et l’INP, ce qui booste votre classement Google.
Vers le GULP appelé aussi Grand Unified Layout Platform
L’arrivée de grid-lanes marque la fin du bricolage. Le futur se dirige vers le « Grand Unified Layout Platform » (GULP), où la distinction entre Flexbox et Grid s’estompe. Le masonry n’est plus une exception, mais un mode naturel au sein d’un moteur de rendu universel. Pour les créateurs, l’adoption de ces standards assure une performance maximale et une accessibilité exemplaire. Que pensez-vous de cette amélioration ? Etes-vous prêt à l’employer ou simplement vous allez rechercher des sites web employant ce nouveau comportement au niveau des CSS ?
FAQ (Foire Aux Questions) qui n’a pas besoin de CSS
Est-ce que je peux vraiment mettre ça en prod ou c’est encore trop risqué ?
On est en 2026, donc la réponse courte c’est « fonce », mais garde un œil sur le rétro. Les navigateurs modernes (les dernières versions de Chrome, Safari, et Firefox) mangent du grid-lanes au petit-déjeuner. Par contre, pour l’utilisateur qui n’a pas mis à jour sa tablette depuis trois ans, tu dois assurer tes arrières. La bonne pratique, c’est d’utiliser @supports. En gros, tu dis au navigateur : « Si tu piges pas le grid-lanes, affiche-moi une grille classique bien carrée« . Le site sera un peu moins « wow », mais il restera parfaitement lisible. C’est le principe de l’amélioration progressive, et franchement, c’est la base du métier.
Pourquoi je ne continuerais pas juste à utiliser Flexbox en mode colonne ?
Parce que c’est un enfer à gérer dès que tu as du contenu dynamique. Avec Flexbox en colonne (flex-direction: column), tu es obligé de forcer l’ordre des éléments verticalement. Imagine : tu as les articles 1, 2, 3 dans la première colonne, et 4, 5, 6 dans la deuxième. Si tu veux insérer une pub entre le 1 et le 2, tout ton équilibre visuel fiche le camp. grid-lanes bosse horizontalement. Il voit un trou ? Il le comble. C’est comme Tetris, mais en mode automatique. T’as plus besoin de faire des maths bizarres pour savoir où envoyer ton prochain bloc HTML.
Ça ne va pas tuer la batterie des vieux smartphones ?
C’est tout l’inverse, et c’est pour ça qu’on aime le natif. Avant, avec les solutions JavaScript type Masonry.js, le processeur du téléphone devait recalculer la position absolue de chaque image à chaque micro-scroll ou redimensionnement de la fenêtre. C’était lourd. Là, tout le calcul est délégué au moteur de rendu du navigateur (codé en C++ ou Rust, donc ultra-rapide). On a viré la couche de script par-dessus. Résultat : c’est fluide comme de l’huile, même sur un Android d’entrée de gamme qui a déjà bien vécu.
J’ai peur pour l’accessibilité, les lecteurs d’écran vont s’y retrouver ?
C’était la grosse angoisse légitime des développeurs. Si visuellement ton élément numéro 5 se retrouve coincé tout en haut à droite à cause de l’algorithme de remplissage, un lecteur d’écran risquait de le lire au mauvais moment. C’est là que la propriété reading-flow sauve la mise. Elle force la navigation au clavier et la lecture vocale à suivre la logique visuelle (ce que tes yeux voient) plutôt que l’ordre du code source. C’est une petite révolution qui rend enfin ces layouts déstructurés utilisables par tout le monde.
