CSS Masonry & CSS Grid

Ein Ansatz zum Erstellen von Mauerwerkslayouts in Vanilla CSS ist einer dieser „heiligen Gral“-Bestrebungen. Eigentlich neige ich dazu, Mauerwerk und das klassische „Holy Grail“-Layout in die gleiche allgemeine Ära des Webdesigns einzuordnen. Es handelt sich natürlich um verschiedene Arten von Layouts, aber Der Heilige Gral war beschlossene Sache, als wir CSS Grid bekamen.

Damit ist Mauerwerk möglicherweise das letzte bestehende Layout aus der CSS 3-Ära, das keine integrierte Lösung aufweist. Ich könnte argumentieren, dass es Mauerwerk nicht mehr gibt en vogue sozusagen, aber es gibt eindeutig Anwendungsfälle für das Packen von Elementen unterschiedlicher Größe in Spalten basierend auf dem verfügbaren Platz. Und Mauerwerk ist immer noch weit verbreitet.

Steam sucht nach einer formellen Lösung. Wir haben sogar eine Entwurf der CSSWG-Spezifikation dafür. Aber beachten Sie, wie der Entwurf die Dinge aufschlüsselt.

Grid-integrierte Syntax? Rasterunabhängige Syntax? Wir haben es geschafft und CSS multipliziert!

Das ist der Kontext für diese Reihe von Notizen. Zum Zeitpunkt des Verfassens dieses Artikels gibt es zwei konkurrierende Vorschläge für CSS-Mauerwerk, und es kursieren viele Meinungen, die den einen oder anderen befürworten. Ich habe persönliche Gedanken dazu, aber das ist nicht wichtig. Ich werde mit dem Konsens zufrieden sein, wie er auch immer sein mag. Beide Vorschläge haben ihre Vorzüge und bringen potenzielle Herausforderungen mit sich – es kommt darauf an, welche Prioritäten Sie setzen, was in diesem Fall meiner Meinung nach die Wahl zwischen der Nutzung vorhandener CSS-Layoutfunktionen und der Ergonomie eines neuen Ansatzes ist.

Kommen wir aber zu einigen Notizen aus bereits laufenden Diskussionen, um ein klareres Bild der Dinge zu bekommen!

Was ist ein Mauerwerksplan?

Stellen Sie sich das so vor, als würden Sie eine Mauer aus Steinen oder Ziegeln errichten.

Die Größe der Ziegel und Steine ​​spielt keine Rolle – die Spalte (oder seltener eine Reihe) entscheidet über die Größe der Dinge. Packen Sie so viele Steine ​​oder Ziegel in die nächste Säule, dass sie sich dann an die Breite der Säule anpassen. Oder genauer gesagt: Wir ordnen Elemente unterschiedlicher Größe in einer Spalte an, sodass keine ungleichmäßigen Lücken zwischen ihnen entstehen.

Beispiele, bitte?

Hier ist vielleicht das am häufigsten gesehene Beispiel in einem CodePen, mit freundlicher Genehmigung von Dave DeSandromit seinem Masonry.js Werkzeug:

Ich verwende dieses Beispiel, weil, wenn ich mich richtig erinnere, Masonry.js den Mauerwerkstrend im Jahr 2010 oder so angeheizt hat. Dave hat es auf Beyoncés Website umgesetzt, was der Maurerei sicherlich ein gut sichtbares Profil verlieh. Manchmal hört man Mauerwerk vielleicht als Layout im „Pinterest-Stil“, weil, nun ja, Das war das charakteristische Design der Website – vielleicht sogar seine Marke – seit dem ersten Tag.

Hier ist ein falsches Beispiel Jhey Mit Flexbox zusammengestellt:

Chris hat auch a zusammengetragen eine Reihe anderer Problemumgehungen im Jahr 2019, die uns unter idealen Bedingungen einigermaßen dorthin bringen. Aber keines davon basiert auf standardisierten Ansätzen oder Merkmalen. Ich meine, Säulen und Flexbox sind zwar spezifiziert, aber nicht für Mauerwerk konzipiert. Aber da Mauerwerk schon seit langem im Einsatz ist, verdient es auf jeden Fall einen Platz in den CSS-Spezifikationen.

Es gibt zwei konkurrierende Vorschläge

Das sind nicht gerade Neuigkeiten. Tatsächlich können wir bekommen frühere Anklänge davon Rückblick auf das Jahr 2020. Rachel Andrew stellte das Konzept vor, Mauerwerk zu einem Untermerkmal des Rasters zu machen in einem Artikel des Smashing Magazine.

Spulen wir vor ins Jahr 2022. Wir hatten eine Herausgeberentwurf für CSS Masonry in die Spezifikation CSS Grid Layout Module 3 integriert. Jenn Simmons gewinkt dass die CSSWG es als ersten öffentlichen Arbeitsentwurf vorantreiben kann. Fünf Tage später Chromium-Ingenieur Ian Kilpatrick äußerte zwei Bedenken über die Weiterentwicklung als Teil des CSS-Raster-Layout-Moduls, wobei sich das erste auf die Größenanpassung von Spaltenspuren und den Layout-Algorithmus des Rasters bezieht:

Grid funktioniert, indem alles im Voraus im Raster platziert wird und dann die Größe der Zeilen/Spalten an die Elemente angepasst wird. Mauerwerk funktioniert auf diese Weise grundsätzlich nicht, da Sie die Größe der Zeilen/Spalten im Voraus festlegen und dann Elemente in diesen Zeilen/Spalten platzieren müssen.

Infolgedessen führt die Art und Weise, wie die aktuelle Spezifikation die Logik zur Rastergrößenbestimmung wiederverwendet, zu schlechten Ergebnissen bei der intrinsischen Dimensionierung von Spuren und wenn das Raster selbst eine intrinsische Größe hat (z. B. wenn es sich innerhalb eines Rasters/Flex/Tabelle usw. befindet).

Guter Punkt! Grid platziert Rasterelemente im Voraus, bevor die Größe angepasst wird, damit sie in den verfügbaren Platz passen. Auch hier ist es die Größe der Säule, die im Mauerwerk für Ordnung sorgt. Daraus folgt logischerweise, dass wir das Mauerwerk im Voraus deklarieren und die Säulenschienengrößen konfigurieren müssten, um die Dinge entsprechend dem Platzangebot platzieren zu können. Das andere Problem betrifft die Zugänglichkeit hinsichtlich der visuellen und Lesereihenfolge.

Das hat Jenns Antrag auf Status des ersten öffentlichen Arbeitsentwurfs Anfang 2023 gestoppt. Wenn wir auf Juli dieses Jahres vorspulen, bekommen wir es Ian weist auf einen alternativen Weg für das Mauerwerk hin. Das erhielt Unterstützung von allen möglichen CSS-Schwergewichten, darunter Rachel Andrew der die CSS Grid-Spezifikation verfasst hat.

Und heute vor gerade einmal drei Wochen fantasai hat einen Entwurf geteilt für einen alternativen Vorschlag, zusammengestellt mit Tab Atkins. Dieser Vorschlagwie Sie sehen werden, ist als eigenes Modul spezifisch für Mauerwerk.

Und somit haben wir zwei konkurrierende Vorschläge, Mauerwerk in CSS zu lösen.

Das Argument für die Verschmelzung von Mauerwerk und Gitter

Zusammenfassung der Kommentare von GitHub-Tickets und Blogbeiträgen …

Flexbox ist eigentlich darauf ausgelegt, Dinge in eine Reihe zu bringen und freien Platz zu verteilen. Das anfängliche Verhalten, alle Ihre Sachen in eine Reihe zu bringen, ist also ein guter Ausgangspunkt für alles, was Sie vielleicht tun möchten. Es kann sein alle Du musst es tun. Als Lehrer ist es dann nicht schwer herauszufinden, wie man innerhalb oder außerhalb von Elementen Platz schafft, sie ausrichtet oder sie in eine Spalte statt in eine Zeile umwandelt. Schritt für Schritt, ausgehend von den Vorgaben.

Ich möchte in der Lage sein, den gleichen Ansatz zu verfolgen display: masonry.

[…]

Mit Grid ist das aufgrund der bereits vorhandenen Anfangswerte nicht so einfach möglich. Die guten Standardeinstellungen für Raster funktionieren für Mauerwerk nicht so gut. Derzeit müssten Sie Folgendes tun:

1. Hinzufügen display: gridum ein einspaltiges Rasterlayout zu erhalten.
2. Hinzufügen grid-template-columns:und im Moment gibt es keine Möglichkeit zum automatischen Ausfüllen auto Die Größe der Spuren liegt bei Ihnen, Sie müssen also entscheiden, wie viele. Benutzen grid-template-columns: repeat(3, auto)Zum Beispiel.
3. Hinzufügen grid-template-rows: masonry.
4. Möchten Sie stattdessen Zeilen definieren? Wechseln Sie die masonry Wert, auf den angewendet werden soll grid-template-columns und definieren Sie nun Ihre Zeilen. Auch hier müssen Sie Zeilen explizit definieren.

Rachel Andrew, „Mauerwerk und gute Vorgaben“

Wie dem auch sei, Rachel hat diese Flagge geschwenkt seit mindestens 2020. Die Ergonomie von display: masonry mit Standardkonfigurationen, die die Grundfunktionalität lösen, sind klar und überzeugend. Das Standardverhalten sollte zum Zweck des Features passen und das Raster ist einfach kein guter Satz an Standardkonfigurationen, um in ein Mauerwerkslayout einzusteigen. Rachel möchte damit sagen, dass das Lehr- und Lernraster zum Verständnis des Mauerwerksverhaltens unnötigerweise zwei unterschiedliche Formatierungskontexte in einem zusammenfasst, was in gewisser Weise zur Verwirrung führt. Es fällt mir schwer, dies zu widerlegen, da ich dies auch aus pädagogischer Sicht betrachte. So gesehen könnte man sagen, dass das Zusammenführen von Funktionen eine Rolle spielt ein weiterer verlorener Einstiegspunkt in die Frontend-Entwicklung.

In den letzten Jahren haben wir zum Erstellen von Mauerwerksplänen vor allem zwei Methoden verwendet:

• Flexbox für einheitliche Reihengrößen. Wir passen das an flex-basis basierend auf dem erwarteten Prozentsatz des Elements an der gesamten Zeilenbreite.
• Raster für einheitliche Spaltengrößen. Wir legen die Zeilenspanne basierend auf dem erwarteten Seitenverhältnis des Inhalts fest, entweder serverseitig für Bilder oder clientseitig für dynamische Inhalte.

Was ich persönlich beobachtet habe, ist:

• Keiner fühlt sich als Ausgangspunkt für das Mauerwerk intuitiver an als der andere. Daher ist es ein wenig schwierig, Grid als Grundlage hervorzuheben.
• Während es Schwierigkeiten gibt, den Leuten beizubringen, wann sie eine Flexbox oder ein Grid verwenden sollen, ist es für Mitwirkende ein viel größerer Schritt, sich mit Eigenschaften auseinanderzusetzen, die das Verhalten erheblich ändern (z. B flex-wrap oder grid-auto-flow: dense).

Tyler Sticka, kommentieren auf GitHub Issue #9041

Es ist wahr! Wenn ich eine der beiden Flexboxen herausgreifen müsste oder Wenn ich das Raster als Ausgangspunkt für Mauerwerk verwende (und ich bezweifle, dass ich es so oder so tun würde), könnte ich Flexbox nur wegen des Standardverhaltens der Ausrichtung flexibler Elemente in einer Spalte verwenden.

Die Syntax und Semantik des CSS, das das Mauerwerkslayout steuert, ist ein Anliegen, das unabhängig von der eigentlichen Layoutmechanik selbst ist, die intern bei der Implementierung durch Benutzeragenten immer noch Teile der vorhandenen Mechanik für Gitter, einschließlich Untergitter, wiederverwenden kann. Für Fälle, in denen Mauerwerk in einem Gitter verschachtelt ist oder ein Gitter innerhalb von Mauerwerk, kann die Beziehung zwischen den beiden explizit gemacht werden.

@jgotten, kommentieren auf GitHub Issue #9041

Diesmal wieder Rachel Ich spreche im Namen des Chrome-Teams:

Es gibt zwei zusammenhängende Gründe, weshalb wir der Meinung sind, dass Mauerwerk besser außerhalb des Rasterlayouts definiert werden kann: die Möglichkeit von Problemen bei der Layoutleistung und die Tatsache, dass sowohl Mauerwerk als auch Raster über Funktionen verfügen, die bei der einen Layoutmethode sinnvoll sind, bei der anderen jedoch nicht.

Es spricht dafür, das Mauerwerk vom Gitter zu trennen

Einer der Hauptvorteile der Integration von Mauerwerk in das Rasterlayout (wie in FALL 2) ist die Möglichkeit, vorhandene Rasterfunktionen wie Untergitter zu nutzen. Unterraster ermöglichen zusammenhängende Designs zwischen untergeordneten Elementen innerhalb eines Rasters, was auch bei vielen Mauerwerkslayouts sehr wünschenswert ist. Darüber hinaus glaube ich, dass zukünftige Verbesserungen des Rasterlayouts auch für das Mauerwerk von Vorteil sein werden und ihre Integration noch wertvoller machen werden. Durch die Behandlung von Mauerwerk als Erweiterung des Rasterlayouts könnten Entwickler sofort mit der Nutzung beginnen, ohne ein völlig neues System erlernen zu müssen.

Kokomi, kommentieren auf GitHub Issue #9041

Es wäre wirklich eine Schande, wenn die Trennung von Mauerwerk und Raster verhindern würde, dass Mauerwerk nicht so leistungsstark ist, wie es mit Zugriff auf den Funktionsumfang des Rasters möglich wäre:

Ich denke, die Argumente für ein separates display: masonry Konzentrieren Sie sich zu sehr auf die potenzielle Einfachheit auf Kosten der Funktionalität. Der Ausschluss der leistungsstarken Funktionen von Grid würde Entwickler behindern, die mehr als nur grundlegende Layouts wollen oder benötigen. Darüber hinaus könnte die Einführung eines anderen Anzeigetyps zu Verwirrung und Fragmentierung im Layout-Ökosystem führen.

Angel Ponce, kommentieren auf GitHub Issue #9041

Rachel kontert dasobwohl.

Ich möchte meine starke Unterstützung für das Hinzufügen von Mauerwerk zu display:grid zum Ausdruck bringen. Die Tatsache, dass es elegant zu einem traditionellen Raster degradiert, ist meiner Meinung nach ein großer Vorteil. Aber auch Mauerwerkslayout ist heute (mit einigen Einschränkungen) im Rasterlayout bereits möglich!

Naman Goel, Angel Ponce, kommentieren auf GitHub Issue #9041

Chris milde bekundete Interesse an einer Fusion im Jahr 2020, bevor die Debatte größer und hitziger wurde. Nicht gerade eine klingende Bestätigung, sondern eher eine Bestätigung, dass es Sinn machen könnte:

Mir gefällt das grid-template-rows: masonry; Syntax, weil ich denke, dass sie klar kommuniziert: „Sie legen diese Zeilen nicht fest. Eigentlich gibt es gar nicht mehr richtig Krach, dafür kümmern wir uns.“ Was meiner Meinung nach bedeutet, dass es im Subgrid keine Zeilen zum Vererben gibt, was auch Sinn macht.

Wo sind wir?

Feedback sammeln. Rachel, Ian und Tab einen gemeinsamen Aufruf veröffentlicht damit Leute wie du und ich unsere Gedanken in die Tasche packen können. Das war vor acht Tagen, als ich diesen Artikel schrieb. Es ist nicht nur ein Aufruf zum Handeln, sondern auch ein hervorragender Überblick über die beiden konkurrierenden Ideen und Überlegungen zu jedem einzelnen. Sie möchten Ihr Feedback hinzufügen GitHub-Problem Nr. 9041.