Een alternatief voorstel voor CSS-metselwerk

Rachel Andrew

Gepubliceerd: 30 april 2024, Laatst bijgewerkt: 13 februari 2026

Het Chrome-team wil graag een implementatie van metselwerklay-outs op het web zien. We zijn echter van mening dat het implementeren ervan als onderdeel van de CSS Grid-specificatie, zoals voorgesteld in het recente WebKit-bericht, een vergissing zou zijn. We vinden ook dat het WebKit-bericht een versie van metselwerk afwijst die niemand voorstelde.

Dit bericht is daarom bedoeld om uit te leggen waarom wij bij Chrome bedenkingen hebben bij de implementatie van masonry als onderdeel van de CSS Grid Layout-specificatie, en om precies te verduidelijken wat het alternatieve voorstel mogelijk maakt. Kort gezegd:

• Het Chrome-team wil de blokkering van masonry graag opheffen; we weten dat ontwikkelaars hiernaar verlangen.
• Het toevoegen van metselwerk aan de rasterspecificatie is om andere redenen problematisch dan de vraag of je metselwerk al dan niet als een raster beschouwt.
• Het definiëren van metselwerk buiten de rasterspecificaties sluit het gebruik van meerdere spoorbreedtes voor metselwerk niet uit, noch het gebruik van eigenschappen zoals uitlijning of tussenruimtes, of andere kenmerken die in rasterlay-outs worden gebruikt.

Moet metselwerk deel uitmaken van het raster?

Het Chrome-team is van mening dat masonry een aparte lay-outmethode moet zijn, gedefinieerd met display: masonry (of een ander trefwoord als er een betere naam wordt gevonden). Verderop in dit bericht vind je enkele voorbeelden van hoe dat er in code uit zou kunnen zien.

Er zijn twee gerelateerde redenen waarom wij vinden dat metselwerk beter gedefinieerd is buiten een rasterindeling: de potentiële prestatieproblemen van de indeling en het feit dat zowel metselwerk als raster kenmerken hebben die in de ene indelingsmethode wel zinvol zijn, maar in de andere niet.

Prestatie

Grid en masonry verschillen in de manier waarop de browser omgaat met afmetingen en plaatsing. Bij een grid worden alle elementen geplaatst vóór de lay-out en weet de browser precies wat er in elk spoor zit. Dit maakt de complexe intrinsieke afmetingen mogelijk die zo nuttig zijn bij grids. Bij masonry worden de elementen geplaatst tijdens de lay-out en weet de browser niet hoeveel elementen er in elk spoor zitten. Dit is geen probleem bij sporen met uitsluitend intrinsieke afmetingen of sporen met uitsluitend vaste afmetingen, maar wel als je sporen met vaste en intrinsieke afmetingen combineert. Om dit probleem te omzeilen, moet de browser een stap vóór de lay-out uitvoeren waarbij elk element op elke mogelijke manier wordt geplaatst om de afmetingen te bepalen. Bij een groot grid zou dit echter leiden tot prestatieproblemen bij de lay-out.

Als je bijvoorbeeld een masonry-layout hebt met een trackdefinitie van grid-template-columns: 200px auto 200px —iets wat heel gebruikelijk is in grid-layouts— begin je problemen te ondervinden. Deze problemen worden exponentieel groter zodra je subgrids toevoegt .

Er wordt wel eens beweerd dat de meeste mensen hier niet tegenaan zullen lopen, maar we weten al dat mensen wel degelijk zeer grote grids hebben . We willen geen product op de markt brengen dat beperkingen kent in de gebruiksmogelijkheden, terwijl er een alternatieve aanpak is.

Wat doen we met de dingen die in elke lay-outmethode geen zin hebben?

Toen flexbox en grid onderdeel werden van CSS, vonden ontwikkelaars vaak dat ze zich inconsistent gedroegen. Deze inconsistentie kwam voort uit lang bestaande aannames over hoe lay-out werkte, gebaseerd op bloklay-out. Na verloop van tijd zijn ontwikkelaars de opmaakcontexten beter gaan begrijpen. Wanneer we overschakelen naar een grid- of flex-opmaakcontext, gedragen sommige dingen zich anders. Je weet bijvoorbeeld dat in flexbox niet alle uitlijnmethoden beschikbaar zijn, omdat flexbox eendimensionaal is.

Door metselwerk in een raster te integreren, wordt deze duidelijke link tussen de opmaakcontext en de beschikbaarheid van zaken zoals uitlijningseigenschappen verbroken. Deze eigenschappen zijn namelijk per opmaakcontext gedefinieerd in de Box Alignment-specificatie.

Als we besluiten het eerder geschetste prestatieprobleem aan te pakken door gemengde intrinsieke en vaste spoordefinities in metselwerk te verbieden, dan moet u er rekening mee houden dat een veelvoorkomend patroon voor rasterlay-outs niet werkt voor metselwerk.

Er zijn ook patronen die zinvol zouden zijn in een metselwerkstructuur, bijvoorbeeld grid-template-columns: repeat(auto-fill, max-content) , omdat er geen kruisbeperkingen zijn, maar die ongeldig moeten blijven in een raster. Hieronder volgt een lijst met eigenschappen waarvan we verwachten dat ze zich anders gedragen of andere geldige waarden hebben.

• grid-template-areas : Bij metselwerk kunt u alleen de eerste rij in de niet-metselwerkrichting specificeren.
• grid-template : De verkorte notatie moet rekening houden met alle verschillen.
• Houd de afmetingen van grid-template-columns en grid-template-rows bij vanwege verschillen in wettelijke waarden.
• grid-auto-flow is niet van toepassing op `masonry` en masonry-auto-flow is niet van toepassing op `grid`. Het samenvoegen ervan zou problemen veroorzaken die ongeldig zijn vanwege de gebruikte lay-outmethode.
• Grid heeft vier plaatsingseigenschappen ( grid-column-start enzovoort), metselwerk heeft er slechts twee.
• Grid kan alle zes eigenschappen justify-* en align-* gebruiken, maar Masonry gebruikt er slechts een subset van, net als flexbox.

Er komt ook een vereiste om te specificeren wat er gebeurt in alle nieuwe foutgevallen die worden veroorzaakt doordat ontwikkelaars een waarde gebruiken die niet geldig is in grid-with-masonry of grid-without-masonry. Het is bijvoorbeeld geldig om grid-template-columns: masonry of grid-template-rows: masonry te gebruiken, maar niet beide tegelijk. Wat gebeurt er als je ze wel tegelijk gebruikt? Deze details moeten worden gespecificeerd, zodat alle browsers hetzelfde doen.

Dit alles wordt ingewikkeld vanuit specificatieoogpunt, zowel nu als in de toekomst. We moeten ervoor zorgen dat alles rekening houdt met metselwerk en of het wel of niet werkt in metselwerk. Het is ook verwarrend vanuit het oogpunt van ontwikkelaars. Waarom moet je onthouden dat sommige dingen niet werken ondanks het gebruik van display: grid vanwege het gebruik van metselwerk?

Een alternatief voorstel

Zoals al eerder vermeld, wil het Chrome-team de masonry-layout buiten de grid-specificatie definiëren. Dit betekent niet dat het beperkt zou blijven tot een zeer eenvoudige lay-outmethode met identieke kolomgroottes. Alle demo's in het WebKit-artikel zouden nog steeds mogelijk zijn.

Klassieke plattegrond van metselwerk

Bij een lay-out met meerdere kolommen van gelijke grootte denken de meeste mensen aan een masonry-lay-out. Deze lay-out kan worden gedefinieerd met de volgende CSS, die minder regels code vereist dan de equivalente versie die standaard in het grid-pakket zit .

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

Gebruik rastertype-spoorafmetingen voor verschillende kolombreedtes.

Afgezien van het eerder genoemde probleem met gemengde intrinsieke en vaste spoorafmetingen, kunt u alle spoorafmetingen gebruiken die u in Grid prettig vindt. Zoals het voorbeeld uit de WebKit-blogpost , een patroon van herhalende smalle en bredere kolommen.

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

Extra railafmetingen voor metselwerk

Er zijn extra opties voor de spoorafmetingen die we niet toestaan ​​in Grid, omdat Grid een tweedimensionale lay-outmethode is. Deze opties zouden nuttig zijn in Masonry, maar het zou verwarrend zijn als ze dan niet zouden werken in Grid.

Automatisch vullen van tracks met max-content .

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

Automatisch invullen van auto aangepaste sporen, waardoor sporen van dezelfde grootte worden aangemaakt, automatisch aangepast aan het grootste spoor.

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

Sta toe dat inhoud zich over meerdere kolommen uitstrekt en plaats items op de metselwerklay-out.

Er is geen reden om geen inhoud over meerdere kolommen te laten lopen in een aparte specificatie voor metselwerk. Hiervoor zou een eigenschap masonry-track gebruikt kunnen worden, een afkorting voor masonry-track-start en masonry-track-end aangezien je in een metselwerklay-out maar één dimensie hebt om elementen over te laten lopen.

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

Onderlaag of onderraster met gebruikmaking van metselwerksporen

Dit zou kunnen worden ondersteund met een aparte specificatie voor metselwerk, wederom met de voorwaarde dat gemengde, intrinsieke en vaste spoorbreedtes niet zijn toegestaan. Hoe dat er precies uit zal zien, moet nog worden vastgesteld. Wij zien geen reden waarom dit niet zou werken.

Conclusie

We willen graag een specificatie ontwikkelen die interoperabel is. We willen dit echter wel op een manier doen die nu en in de toekomst goed werkt en waarop ontwikkelaars kunnen vertrouwen. De enige manier om de geschetste prestatieproblemen op te lossen, zou zijn om het tweede probleem – dat bepaalde delen van het raster niet zijn toegestaan ​​in metselwerk – te verergeren. Wij denken niet dat dit een goede oplossing is, vooral omdat het mogelijk is om alle gewenste rasterfuncties te hebben en tegelijkertijd de verschillen duidelijk te scheiden.

Als je feedback hebt, neem dan deel aan de discussie in nummer 9041 .

Met dank aan Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick en Chris Harrelson voor het nakijken van dit bericht en de discussies die eraan ten grondslag lagen.