Pubblicato: 30 aprile 2024, ultimo aggiornamento: 13 febbraio 2026
Il team di Chrome è ansioso di vedere un'implementazione di layout di tipo muratura sul web. Tuttavia, riteniamo che implementarlo come parte della specifica CSS Grid, come proposto nel recente post di WebKit, sarebbe un errore. Riteniamo inoltre che il post di WebKit si opponga a una versione di layout a griglia che nessuno stava proponendo.
Pertanto, questo post ha lo scopo di spiegare perché noi di Chrome abbiamo dubbi sull'implementazione di masonry come parte della specifica CSS Grid Layout e di chiarire esattamente cosa consente la proposta alternativa. In breve:
- Il team di Chrome è molto interessato a sbloccare il layout a griglia, sappiamo che è qualcosa che gli sviluppatori desiderano.
- L'aggiunta di Masonry alla specifica della griglia è problematica per motivi diversi dal fatto che tu ritenga o meno che Masonry sia una griglia.
- La definizione di muratura al di fuori della specifica della griglia non impedisce più dimensioni delle tracce per la muratura, l'utilizzo di proprietà come l'allineamento o gli spazi vuoti o qualsiasi altra funzionalità utilizzata nel layout a griglia.
La muratura deve far parte della griglia?
Il team di Chrome ritiene che la muratura debba essere un metodo di layout separato, definito utilizzando display: masonry (o un'altra parola chiave se viene deciso un nome migliore). Più avanti in questo post, puoi vedere alcuni esempi di come potrebbe apparire il codice.
Esistono due motivi correlati per cui riteniamo che la muratura sia definita meglio al di fuori del layout a griglia: il potenziale di problemi di rendimento del layout e il fatto che sia la muratura sia la griglia hanno funzionalità che hanno senso in un metodo di layout, ma non nell'altro.
Rendimento
Griglia e muratura sono opposti in termini di gestione delle dimensioni e del posizionamento da parte del browser. Quando viene disposta una griglia, tutti gli elementi vengono posizionati prima del layout e il browser sa esattamente cosa contiene ogni traccia. Ciò consente il dimensionamento intrinseco complesso che è così utile nella griglia. Con il layout a griglia, gli elementi vengono posizionati così come sono disposti e il browser non sa quanti ce ne sono in ogni traccia. Questo non è un problema con tutte le tracce di dimensioni intrinseche o tutte le tracce di dimensioni fisse, ma si verifica se combini tracce fisse e intrinseche. Per risolvere il problema, il browser deve eseguire un passaggio di pre-layout di disposizione di ogni elemento in ogni modo possibile per ottenere le misurazioni. Con una griglia di grandi dimensioni, ciò contribuirebbe a problemi di prestazioni del layout.
Pertanto, se avevi un layout a griglia con una definizione di traccia di
grid-template-columns: 200px auto 200px, una cosa molto comune da fare nella griglia, inizi
a riscontrare problemi. Questi problemi diventano esponenziali una volta aggiunte
le griglie secondarie.
Si potrebbe sostenere che la maggior parte delle persone non si imbatterà in questo problema, ma sappiamo già che le persone hanno griglie molto grandi. Non vogliamo spedire qualcosa che abbia limiti di utilizzo, quando esiste un approccio alternativo.
Cosa facciamo con gli elementi che non hanno senso in ogni metodo di layout?
Quando Flexbox e Grid sono entrati a far parte di CSS, gli sviluppatori spesso hanno avuto la sensazione che si comportassero in modo incoerente. L'incoerenza che riscontravano era dovuta a presupposti di lunga data sul funzionamento del layout, basati sul layout a blocchi. Nel tempo, gli sviluppatori hanno iniziato a comprendere i contesti di formattazione. Quando passiamo a un contesto di formattazione a griglia o flessibile, alcune cose si comportano in modo diverso. Ad esempio, sai che quando utilizzi Flexbox, non tutti i metodi di allineamento sono disponibili, perché Flexbox è unidimensionale.
L'inserimento di masonry nella griglia interrompe questo collegamento chiaro tra il contesto di formattazione e la disponibilità di elementi come le proprietà di allineamento, che sono definite nella specifica di allineamento della casella per contesto di formattazione.
Se decidiamo di risolvere il problema di prestazioni descritto in precedenza rendendo illegali le definizioni di tracce intrinseche e fisse miste in muratura, dovrai ricordare che un pattern molto comune per i layout a griglia non funziona per la muratura.
Esistono anche pattern che avrebbero senso nel layout a griglia, ad esempio
grid-template-columns: repeat(auto-fill, max-content), perché non hai
vincoli incrociati, ma devono rimanere non validi nella griglia. Di seguito è riportato un elenco di proprietà che prevediamo si comportino in modo diverso o che abbiano valori validi diversi.
grid-template-areas: Nel layout a griglia puoi specificare solo la riga iniziale nella direzione non a griglia.grid-template: L'abbreviazione dovrebbe tenere conto di tutte le differenze.- Monitora i valori di dimensionamento per
grid-template-columnsegrid-template-rowsa causa delle differenze nei valori legali. grid-auto-flownon si applica al layout a griglia emasonry-auto-flownon si applica al layout a cascata. La loro unione creerebbe problemi di elementi non validi a causa del metodo di layout che stai utilizzando.- La griglia ha quattro proprietà di posizionamento (
grid-column-starte così via), la muratura ne ha solo due. - Grid può utilizzare tutte e sei le proprietà
justify-*ealign-*, ma Masonry utilizza solo un sottoinsieme come Flexbox.
Inoltre, sarà necessario specificare cosa succede in tutti i nuovi casi di errore
causati dagli sviluppatori che utilizzano un valore non valido in griglia con muratura
o griglia senza muratura. Ad esempio, è valido utilizzare
grid-template-columns: masonry o grid-template-rows: masonry,
ma non entrambi contemporaneamente. Cosa succede se li usi entrambi contemporaneamente?
Questi dettagli devono essere specificati in modo che tutti i browser
facciano la stessa cosa.
Tutto ciò diventa complicato dal punto di vista delle specifiche, ora e in futuro. Dobbiamo assicurarci che tutto tenga conto del layout a griglia e
se funziona o meno in questo layout. Inoltre, è fonte di confusione dal punto
di vista degli sviluppatori. Perché dovresti ricordare che, nonostante
l'utilizzo di display: grid, alcune cose non funzionano a causa dell'utilizzo del layout a griglia?
Una proposta alternativa
Come già accennato, il team di Chrome vorrebbe definire la muratura al di fuori della specifica della griglia. Ciò non significa che sarebbe limitato a un metodo di layout molto semplice con dimensioni delle colonne identiche. Tutte le demo nel post di WebKit sarebbero ancora possibili.
Layout a griglia classico
Quando la maggior parte delle persone pensa al layout a griglia, immagina un layout con più colonne di dimensioni uguali. Questo verrebbe definito utilizzando il seguente CSS, che richiede una riga di codice in meno rispetto alla versione raggruppata della griglia.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, minmax(14rem, 1fr));
gap: 1rem;
}
Utilizzare il dimensionamento delle tracce di tipo griglia per larghezze delle colonne diverse
A parte il problema menzionato in precedenza con il dimensionamento misto delle tracce intrinseche e fisse, puoi utilizzare tutto il dimensionamento delle tracce che preferisci della griglia. Ad esempio, l'esempio del post del blog WebKit, un pattern di colonne strette e più larghe ripetute.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, minmax(8rem, 1fr) minmax(16rem, 2fr)) minmax(8rem, 1fr);
gap: 1rem;
}
Dimensioni aggiuntive delle tracce per il layout a griglia
Esistono altre opzioni di dimensionamento delle tracce che non consentiamo nella griglia perché la griglia è un metodo di layout bidimensionale. Queste opzioni sarebbero utili nel layout a griglia, ma sarebbe fonte di confusione se non funzionassero nella griglia.
Tracce di dimensioni max-content con riempimento automatico.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, max-content);
gap: 1rem;
}
Il riempimento automatico delle tracce di dimensioni auto, che creerà tracce delle stesse dimensioni,
dimensionate automaticamente per adattarsi a quella più grande.
.masonry {
display: masonry;
masonry-template-tracks: repeat(auto-fill, auto);
gap: 1rem;
}
Consente ai contenuti di estendersi su più colonne e di posizionare gli elementi nel layout a griglia
Non c'è motivo per non avere contenuti che si estendono su più colonne in una specifica
a griglia separata. Potrebbe utilizzare una proprietà masonry-track, che è un'abbreviazione di
masonry-track-start e masonry-track-end, in quanto hai una sola dimensione da
estendere in un layout a griglia.
.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 */
}
Sub-masonry o subgrid che adottano tracce di masonry
Ciò potrebbe essere supportato da una specifica separata di muratura, sempre con la clausola che le tracce di dimensioni intrinseche e fisse miste non sono consentite. Dovrà essere definita la forma esatta. Non vediamo alcun motivo per cui non dovrebbe funzionare.
Conclusione
Ci piacerebbe arrivare a un punto in cui le specifiche possono essere spedite in modo interoperabile. Tuttavia, vogliamo farlo in modo che funzioni bene ora e in futuro e su cui gli sviluppatori possano fare affidamento. L'unico modo per risolvere i problemi di rendimento descritti sarebbe peggiorare il secondo problema, ovvero la presenza di parti della griglia illegali nel layout a griglia. Non riteniamo che sia una buona soluzione, soprattutto quando è possibile avere tutte le funzionalità della griglia che desideri mantenendo chiaramente separate le cose diverse.
Se hai feedback, partecipa alla discussione nel problema 9041.
Grazie a Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick e Chris Harrelson per la revisione di questo post e per le discussioni che lo hanno ispirato.