Ein alternativer Vorschlag für preiswertes Mauerwerk

Rachel Andrew

Veröffentlicht am 30. April 2024, zuletzt aktualisiert am 13. Februar 2026

Warnung :Veraltete Syntax: Die Codebeispiele in diesem Beitrag basieren auf einem frühen Entwurf des Layouts für Grid-Spalten. Die aktuelle Version der Syntax finden Sie in der css-grid-3-Spezifikation.

Das Chrome-Team würde sich freuen, wenn das Mauerwerk-Layout im Web implementiert würde. Wir sind jedoch der Meinung, dass die Implementierung als Teil der CSS-Grid-Spezifikation, wie im aktuellen WebKit-Beitrag vorgeschlagen, ein Fehler wäre. Außerdem sind wir der Meinung, dass im WebKit-Beitrag gegen eine Version von Masonry argumentiert wurde, die niemand vorgeschlagen hat.

In diesem Beitrag wird daher erläutert, warum wir bei Chrome Bedenken hinsichtlich der Implementierung von Masonry als Teil der CSS Grid Layout-Spezifikation haben, und es wird genau erläutert, was der alternative Vorschlag ermöglicht. Kurzum:

• Das Chrome-Team möchte das Problem mit dem Masonry-Layout unbedingt beheben, da wir wissen, dass Entwickler es sich wünschen.
• Das Hinzufügen von Masonry zur Gridspezifikation ist aus anderen Gründen problematisch, unabhängig davon, ob Sie Masonry für ein Grid halten oder nicht.
• Wenn Sie das Mauerwerk außerhalb der Gridspezifikation definieren, wird nicht verhindert, dass mehrere Spaltengrößen für das Mauerwerk verwendet werden oder dass Eigenschaften wie Ausrichtung oder Lücken oder andere Funktionen verwendet werden, die im Grid-Layout verwendet werden.

Soll das Mauerwerk Teil des Rasters sein?

Das Chrome-Team ist der Meinung, dass Masonry eine separate Layoutmethode sein sollte, die mit display: masonry definiert wird (oder mit einem anderen Keyword, falls ein besserer Name gefunden wird). Weiter unten in diesem Beitrag finden Sie einige Beispiele dafür, wie das im Code aussehen könnte.

Es gibt zwei zusammenhängende Gründe, warum wir der Meinung sind, dass Masonry besser außerhalb des Rasterlayouts definiert wird: das Potenzial für Probleme mit der Layoutleistung und die Tatsache, dass sowohl Masonry als auch Raster Funktionen haben, die in einer Layoutmethode sinnvoll sind, in der anderen jedoch nicht.

Hinweis :In diesem Beitrag werden die Hauptprobleme hervorgehoben, anstatt eine vollständige und detaillierte Erklärung für jedes Problem zu geben. Weitere Informationen finden Sie in den verlinkten Problemen.

Leistung

Raster und Mauerwerk sind gegensätzlich in Bezug darauf, wie der Browser mit Größe und Platzierung umgeht. Wenn ein Raster angelegt wird, werden alle Elemente vor dem Layout platziert und der Browser weiß genau, was sich in den einzelnen Spuren befindet. Dies ermöglicht die komplexe intrinsische Größenanpassung, die im Raster so nützlich ist. Bei Masonry werden die Elemente so platziert, wie sie angeordnet sind. Der Browser weiß nicht, wie viele Elemente sich in den einzelnen Spalten befinden. Das ist nicht bei allen Tracks mit intrinsischer Größe oder allen Tracks mit fester Größe der Fall, sondern nur, wenn Sie Tracks mit fester und intrinsischer Größe kombinieren. Um das Problem zu umgehen, muss der Browser einen Schritt vor dem Layout ausführen, bei dem jedes Element auf jede mögliche Weise angeordnet wird, um Messungen zu erhalten. Bei einem großen Raster kann dies zu Problemen mit der Layoutleistung führen.

Wenn Sie also ein Mauerwerk-Layout mit einer Track-Definition von grid-template-columns: 200px auto 200px haben, was bei Rastern sehr häufig vorkommt, treten Probleme auf. Diese Probleme werden exponentiell größer, wenn Sie Unterraster hinzufügen.

Man könnte argumentieren, dass die meisten Nutzer nicht auf dieses Problem stoßen werden. Wir wissen jedoch bereits, dass Nutzer sehr große Raster haben. Wir möchten keine Lösung anbieten, die in ihrer Verwendung eingeschränkt ist, wenn es eine Alternative gibt.

Was tun wir mit den Dingen, die bei den einzelnen Layoutmethoden keinen Sinn ergeben?

Als Flexbox und Grid Teil von CSS wurden, hatten Entwickler oft das Gefühl, dass sie sich inkonsistent verhielten. Die Inkonsistenz, die sie feststellten, beruhte auf langjährigen Annahmen zur Funktionsweise des Layouts, die auf dem Blocklayout basierten. Im Laufe der Zeit haben Entwickler begonnen, Formatierungskontexte zu verstehen. Wenn wir in einen Raster- oder Flex-Formatierungskontext wechseln, verhalten sich einige Dinge anders. Sie wissen beispielsweise, dass in Flexbox nicht alle Ausrichtungsmethoden verfügbar sind, da Flexbox eindimensional ist.

Wenn Sie Mauerwerk in Raster einfügen, wird diese klare Verbindung zwischen Formatierungskontext und Verfügbarkeit von Elementen wie Ausrichtungseigenschaften unterbrochen, die in der Box Alignment-Spezifikation pro Formatierungskontext definiert sind.

Wenn wir uns entscheiden, das oben beschriebene Leistungsproblem zu beheben, indem wir gemischte intrinsische und feste Track-Definitionen in Masonry verbieten, müssen Sie bedenken, dass ein sehr häufiges Muster für Rasterlayouts nicht für Masonry funktioniert.

Es gibt auch Muster, die im Mauerwerk sinnvoll wären, z. B. grid-template-columns: repeat(auto-fill, max-content), da es keine Cross-Constraints gibt, die im Raster jedoch ungültig bleiben müssen. Im Folgenden finden Sie eine Liste der Eigenschaften, die sich voraussichtlich anders verhalten oder andere gültige Werte haben.

• grid-template-areas: Im Masonry-Layout können Sie nur die erste Zeile in der Nicht-Masonry-Richtung angeben.
• grid-template: Die Kurzfassung müsste alle Unterschiede berücksichtigen.
• Größenwerte für grid-template-columns und grid-template-rows aufgrund von Unterschieden bei den rechtlichen Werten erfassen.
• grid-auto-flow gilt nicht für das Mauerwerk-Layout und masonry-auto-flow nicht für das Raster-Layout. Wenn Sie sie zusammenführen, entstehen Probleme mit Elementen, die aufgrund der von Ihnen verwendeten Layoutmethode ungültig sind.
• Das Raster hat vier Placement-Properties (grid-column-start usw.), das Mauerwerk nur zwei.
• Für das Grid-Layout können alle sechs justify-*- und align-*-Eigenschaften verwendet werden, für das Mauerwerk-Layout jedoch nur eine Teilmenge wie bei Flexbox.

Außerdem muss angegeben werden, was in allen neuen Fehlerfällen passiert, die dadurch entstehen, dass Entwickler einen Wert verwenden, der in „grid-with-masonry“ oder „grid-without-masonry“ nicht gültig ist. Sie können beispielsweise grid-template-columns: masonry oder grid-template-rows: masonry verwenden, aber nicht beides gleichzeitig. Was passiert, wenn Sie beide gleichzeitig verwenden? Diese Details müssen angegeben werden, damit alle Browser dasselbe tun.

Aus Sicht der Spezifikation wird das alles kompliziert, sowohl jetzt als auch in Zukunft. Wir müssen darauf achten, dass alles für die Darstellung im Mauerwerk berücksichtigt wird und ob es im Mauerwerk funktioniert oder nicht. Auch für Entwickler ist das verwirrend. Warum sollten Sie sich merken müssen, dass trotz der Verwendung von display: grid einige Dinge aufgrund der Verwendung von Masonry nicht funktionieren?

Ein alternativer Vorschlag

Wie bereits erwähnt, möchte das Chrome-Team die Funktion „Masonry“ außerhalb der Grid-Spezifikation definieren. Das bedeutet nicht, dass es auf eine sehr einfache Layoutmethode mit identischen Spaltengrößen beschränkt wäre. Alle Demos im WebKit-Beitrag wären weiterhin möglich.

Hinweis :In den Beispielen werden die Eigenschaften display: masonry und masonry-* verwendet. Es gibt ein separates Problem, ob masonry der beste Name ist.

Klassisches Mauerwerk-Layout

Die meisten denken bei Masonry an ein Layout mit mehreren gleich großen Spalten. Dies wird mit dem folgenden CSS definiert, das eine Zeile weniger Code als die entsprechende Grid-Version erfordert.

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

Spaltenbreiten mit der Rastertyp-Spurgröße festlegen

Abgesehen vom oben genannten Problem mit der gemischten intrinsischen und festen Spaltengröße können Sie alle Spaltengrößen verwenden, die Sie von Grid kennen. Wie das Beispiel aus dem WebKit-Blogpost zeigt, kann es sich um ein Muster aus sich wiederholenden schmalen und breiten Spalten handeln.

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

Zusätzliche Track-Größen für Masonry

Es gibt zusätzliche Optionen für die Größe von Tracks, die wir im Raster nicht zulassen, da das Raster eine zweidimensionale Layoutmethode ist. Diese wären im Mauerwerk-Layout nützlich, es wäre aber verwirrend, wenn sie im Raster nicht funktionieren würden.

Automatisches Ausfüllen von Tracks mit der Größe max-content.

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

Automatisches Ausfüllen von Tracks mit der Größe auto, wodurch Tracks mit derselben Größe erstellt werden, die automatisch an den größten Track angepasst wird.

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

Inhalte über Spalten hinweg anzeigen und Elemente im Mauerwerk-Layout platzieren

Es gibt keinen Grund, Inhalte, die sich über Spalten erstrecken, nicht in einer separaten Mauerwerksspezifikation zu haben. Dazu kann die masonry-track-Eigenschaft verwendet werden, die eine Abkürzung für masonry-track-start und masonry-track-end ist, da in einem Mauerwerk-Layout nur eine Dimension für die Spannen von Elementen zur Verfügung steht.

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

Untergeordnete Masonry- oder Unterraster-Layouts mit Masonry-Spalten

Dies könnte mit einer separaten Masonry-Spezifikation unterstützt werden, wiederum unter der Voraussetzung, dass gemischte Tracks mit intrinsischer und fester Größe nicht zulässig sind. Wie das genau aussehen soll, muss noch definiert werden. Wir sehen keinen Grund, warum das nicht funktionieren sollte.

Fazit

Wir würden uns freuen, wenn wir eine Spezifikation erreichen könnten, die interoperabel ausgeliefert werden kann. Wir möchten das jedoch so tun, dass es jetzt und in Zukunft gut funktioniert und sich Entwickler darauf verlassen können. Die einzige Möglichkeit, die beschriebenen Leistungsprobleme zu beheben, besteht darin, das zweite Problem zu verschlimmern, nämlich dass Teile des Rasters im Mauerwerk illegal sind. Wir halten das nicht für eine gute Lösung, vor allem, wenn es möglich ist, alle gewünschten Rasterfunktionen zu nutzen und gleichzeitig die Unterschiede deutlich zu kennzeichnen.

Wenn Sie Feedback haben, beteiligen Sie sich an der Diskussion in Problem 9041.

Vielen Dank an Bramus, Tab Atkins-Bittner, Una Kravets, Ian Kilpatrick und Chris Harrelson für die Überprüfung dieses Beitrags und die Diskussionen, die ihn beeinflusst haben.