Autre proposition pour la maçonnerie CSS

Rachel Andrew

Publié le 30 avril 2024, dernière mise à jour le 13 février 2026

Avertissement : Syntaxe obsolète : les exemples de code de cet article sont basés sur une première version de ce qui est désormais appelé "Mise en page des voies de grille". Consultez la spécification css-grid-3 pour obtenir la dernière version de la syntaxe.

L'équipe Chrome souhaite voir des mises en page de type masonry sur le Web. Toutefois, nous pensons que l'implémenter dans la spécification CSS Grid, comme proposé dans le récent post WebKit, serait une erreur. Nous avons également l'impression que le post WebKit s'opposait à une version de masonry que personne ne proposait.

Cet article vise donc à expliquer pourquoi nous, chez Chrome, avons des inquiétudes concernant l'implémentation de la mise en page en maçonnerie dans la spécification CSS Grid Layout, et à clarifier exactement ce que permet la proposition alternative. En résumé :

• L'équipe Chrome est très désireuse de débloquer la mise en page en maçonnerie, car nous savons que c'est une fonctionnalité que les développeurs souhaitent.
• L'ajout de masonry à la spécification de grille pose problème pour d'autres raisons que celle de savoir si vous pensez que masonry est une grille ou non.
• Définir la maçonnerie en dehors de la spécification de la grille n'empêche pas d'utiliser plusieurs tailles de pistes pour la maçonnerie, ni d'utiliser des propriétés telles que l'alignement ou les espaces, ni aucune autre fonctionnalité utilisée dans la mise en page en grille.

La maçonnerie doit-elle faire partie de la grille ?

L'équipe Chrome estime que la maçonnerie devrait être une méthode de mise en page distincte, définie à l'aide de display: masonry (ou d'un autre mot clé si un meilleur nom est choisi). Vous trouverez des exemples de code plus loin dans cet article.

Il existe deux raisons connexes pour lesquelles nous pensons que la mise en page en maçonnerie est mieux définie en dehors de la mise en page en grille : le risque de problèmes de performances de mise en page et le fait que la mise en page en maçonnerie et la mise en page en grille comportent des fonctionnalités qui ont du sens dans une méthode de mise en page, mais pas dans l'autre.

Remarque : Cet article tente de mettre en évidence les problèmes principaux plutôt que de fournir une explication complète et détaillée de chacun d'eux. Pour en savoir plus, consultez les problèmes associés.

Performances

Les grilles et les mises en page en maçonnerie sont opposées en termes de dimensionnement et de placement par le navigateur. Lorsqu'une grille est mise en page, tous les éléments sont placés avant la mise en page et le navigateur sait exactement ce qui se trouve dans chaque piste. Cela permet le dimensionnement intrinsèque complexe si utile dans la grille. Avec la disposition en maçonnerie, les éléments sont placés tels qu'ils sont disposés, et le navigateur ne sait pas combien il y en a dans chaque piste. Ce problème ne se pose pas avec toutes les pistes de taille intrinsèque ni avec toutes les pistes de taille fixe, mais il se pose si vous mélangez des pistes de taille fixe et intrinsèque. Pour contourner le problème, le navigateur doit effectuer une étape de pré-mise en page en disposant chaque élément de toutes les manières possibles pour obtenir des mesures. Avec une grille de grande taille, cela contribuerait à des problèmes de performances de mise en page.

Par conséquent, si vous aviez une mise en page en maçonnerie avec une définition de piste de grid-template-columns: 200px auto 200px (ce qui est très courant dans la grille), vous commencerez à rencontrer des problèmes. Ces problèmes deviennent exponentiels une fois que vous ajoutez des sous-grilles.

On pourrait penser que la plupart des utilisateurs ne rencontreront pas ce problème, mais nous savons déjà que certains ont des grilles très grandes. Nous ne voulons pas proposer une solution dont l'utilisation est limitée, alors qu'il existe une autre approche.

Que faire des éléments qui n'ont pas de sens dans chaque méthode de mise en page ?

Lorsque flexbox et grid ont été intégrés à CSS, les développeurs ont souvent eu l'impression qu'ils se comportaient de manière incohérente. L'incohérence qu'ils rencontraient était due à des hypothèses de longue date sur le fonctionnement de la mise en page, basées sur la mise en page par blocs. Au fil du temps, les développeurs ont commencé à comprendre les contextes de mise en forme. Lorsque nous passons à un contexte de mise en forme en grille ou flexible, certains éléments se comportent différemment. Par exemple, vous savez que lorsque vous êtes dans une boîte flexible, toutes les méthodes d'alignement ne sont pas disponibles, car la boîte flexible est unidimensionnelle.

Regrouper la maçonnerie dans la grille rompt ce lien clair entre le contexte de mise en forme et la disponibilité d'éléments tels que les propriétés d'alignement, qui sont définies dans la spécification d'alignement des boîtes par contexte de mise en forme.

Si nous décidons de résoudre le problème de performances décrit précédemment en interdisant les définitions de pistes intrinsèques et fixes mixtes dans la mise en page en maçonnerie, vous devrez vous rappeler qu'un modèle très courant pour les mises en page en grille ne fonctionne pas pour la mise en page en maçonnerie.

Il existe également des modèles qui auraient du sens dans la maçonnerie, par exemple grid-template-columns: repeat(auto-fill, max-content), car vous n'avez pas de contraintes croisées, mais qui doivent rester non valides dans la grille. Vous trouverez ci-dessous la liste des propriétés dont le comportement devrait être différent ou dont les valeurs valides sont différentes.

• grid-template-areas : Dans la mise en page en maçonnerie, vous ne pouvez spécifier que la ligne initiale dans la direction autre que celle de la mise en page en maçonnerie.
• grid-template : le raccourci doit tenir compte de toutes les différences.
• Suivez les valeurs de dimensionnement pour grid-template-columns et grid-template-rows en raison des différences dans les valeurs légales.
• grid-auto-flow ne s'applique pas à la disposition en maçonnerie et masonry-auto-flow ne s'applique pas à la grille. Les fusionner créerait des problèmes d'éléments non valides en raison de la méthode de mise en page que vous utilisez.
• La grille comporte quatre propriétés d'emplacement (grid-column-start, etc.), tandis que la mise en page en maçonnerie n'en comporte que deux.
• La grille peut utiliser les six propriétés justify-* et align-*, mais la disposition en maçonnerie n'en utilise qu'un sous-ensemble, comme Flexbox.

Il sera également nécessaire de spécifier ce qui se passe dans tous les nouveaux cas d'erreur causés par les développeurs qui utilisent une valeur non valide dans grid-with-masonry ou grid-without-masonry. Par exemple, vous pouvez utiliser grid-template-columns: masonry ou grid-template-rows: masonry, mais pas les deux en même temps. Que se passe-t-il si vous utilisez les deux en même temps ? Ces détails doivent être spécifiés pour que tous les navigateurs fassent la même chose.

Tout cela devient compliqué du point de vue des spécifications, aujourd'hui et à l'avenir. Nous devrons nous assurer que tout prend en compte la maçonnerie et que tout fonctionne ou non dans la maçonnerie. C'est également déroutant du point de vue des développeurs. Pourquoi devez-vous garder à l'esprit que, malgré l'utilisation de display: grid, certaines choses ne fonctionnent pas à cause de l'utilisation de masonry ?

Une autre proposition

Comme déjà mentionné, l'équipe Chrome souhaite définir la maçonnerie en dehors de la spécification de la grille. Cela ne signifie pas qu'il serait limité à une méthode de mise en page très simple avec des tailles de colonnes identiques. Toutes les démos du post WebKit seraient toujours possibles.

Remarque : Les exemples utilisent les propriétés display: masonry et masonry-*. Un problème distinct se pose quant à savoir si masonry est le meilleur nom à utiliser.

Mise en page en maçonnerie classique

Lorsque la plupart des gens pensent à la maçonnerie, ils pensent à une mise en page avec plusieurs colonnes de taille égale. Cela serait défini à l'aide du code CSS suivant, qui nécessite une ligne de code de moins que la version groupée de la grille équivalente.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
}

Utiliser le dimensionnement des pistes de type grille pour différentes largeurs de colonnes

À l'exception du problème mentionné précédemment concernant le dimensionnement mixte des pistes intrinsèques et fixes, vous pouvez utiliser tous les types de dimensionnement de piste que vous aimez dans la grille. Par exemple, l'exemple de l'article de blog WebKit, un motif de colonnes étroites et larges répétées.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
  gap: 1rem;
}

Dimensionnement supplémentaire des pistes pour la mise en page en mosaïque

Il existe d'autres options de dimensionnement des pistes que nous n'autorisons pas dans la grille, car il s'agit d'une méthode de mise en page bidimensionnelle. Ces propriétés seraient utiles dans une mise en page en maçonnerie, mais il serait déroutant qu'elles ne fonctionnent pas dans une grille.

Remplissage automatique des pistes de taille max-content.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, max-content);
  gap: 1rem;
}

Remplissage automatique des pistes de taille auto, ce qui crée des pistes de même taille, dimensionnées automatiquement pour s'adapter à la plus grande.

.masonry {
  display: masonry;
  masonry-template-tracks: repeat(auto-fill, auto);
  gap: 1rem;
}

Autoriser le contenu à s'étendre sur plusieurs colonnes et placer les éléments dans la mise en page en maçonnerie

Il n'y a aucune raison de ne pas avoir de contenu s'étendant sur plusieurs colonnes dans une spécification de maçonnerie distincte. Cela peut utiliser une propriété masonry-track, qui est un raccourci pour masonry-track-start et masonry-track-end, car vous n'avez qu'une seule dimension pour étendre les éléments dans une mise en page en maçonnerie.

.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 */
}

Sous-maçonnerie ou sous-grille adoptant des pistes de maçonnerie

Cela pourrait être pris en charge avec une spécification de maçonnerie distincte, encore une fois avec la condition que les pistes de taille intrinsèque et fixe mixtes ne sont pas autorisées. Il faudra définir exactement à quoi cela ressemble. Nous ne voyons aucune raison pour que cela ne fonctionne pas.

Conclusion

Nous aimerions atteindre un point de spécification qui puisse être expédié de manière interopérable. Toutefois, nous voulons le faire d'une manière qui fonctionne bien maintenant et à l'avenir, et sur laquelle les développeurs peuvent compter. La seule façon de résoudre les problèmes de performances décrits ci-dessus serait d'aggraver le deuxième problème, à savoir le fait d'avoir des parties de grille illégales dans la mise en page en maçonnerie. Nous ne pensons pas que ce soit une bonne solution, surtout lorsqu'il est possible d'avoir toutes les fonctionnalités de grille souhaitées tout en gardant les éléments différents clairement séparés.

Si vous avez des commentaires, rejoignez la discussion dans le problème 9041.

Merci à Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick et Chris Harrelson pour la relecture de cet article et les discussions qui l'ont inspiré.