WebKit bittet um Feedback zur Standardisierung des CSS-Grid-Level-3-„Masonry“-Layouts

(webkit.org)

2 Punkte von GN⁺ 2024-04-24 | 1 Kommentare | Auf WhatsApp teilen

WebKit bittet Designer und Entwickler um Feedback zur Standardisierung des in CSS lange schwierigen Masonry-/Waterfall-Layouts als CSS Grid Level 3
Das vorgeschlagene Modell schaltet auf Basis von display: grid mit grid-template-rows: masonry die Erzeugung von Zeilen ab und füllt Inhalte wie Mauersteine in freie Lücken
Apple ist der Ansicht, dass diese Funktion in Grid liegen muss, damit sie mit bestehenden Grid-Fähigkeiten wie fr, minmax(), max-content, Spanning, expliziter Platzierung und subgrid kombiniert werden kann
Ein separater Ansatz mit display: masonry könnte Layout-Typen zwar einfach trennen, dürfte der Diskussion zufolge aber möglicherweise auf gleich breite Spalten beschränkt bleiben und die Track-Sizing-Fähigkeiten von Grid nur schwer nutzen können
Nach dem Update im Oktober 2024 kam die CSS Working Group zu dem Schluss, dass variable Track-Breiten, explizite Platzierung, Spanning und Subgrid es wert sind, in Masonry aufgenommen zu werden, und sich performant implementieren lassen; die Syntax-Diskussion läuft jedoch weiter

Aktueller Stand von CSS Grid Level 3

Nach dem Update im Oktober 2024 wurde ein offizieller W3C Working Draft für das CSS Grid Layout Module Level 3 erstellt, der das Verhalten von Masonry-Layouts dokumentiert
Mitglieder der CSS Working Group kamen zu dem Schluss, dass folgende Funktionen für Masonry-Layouts wertvoll sind und performant implementiert werden können
- Tracks mit variabler Breite
- Explizite Platzierung
- Spanning
- subgrid
Die Debatte über die Syntax ist jedoch noch offen; WebKit führt sie in einem separaten Beitrag, Help us choose the syntax for Masonry in CSS, fort

Warum Masonry-Layouts nötig sind

CSS Grid Level 1 wurde 2017 eingeführt und verringerte den Größen- und Platzierungsaufwand von Float-basierten Layouts; Grid Level 2 brachte Subgrid
Doch auch nach der Einführung von CSS Grid gab es sieben Jahre lang keine klare Antwort auf die Frage, wie man ein „Masonry-Layout in CSS“ schreibt
Ein Masonry-Layout ist ein Muster, bei dem Inhalte wie Ziegelsteine oder eine Steinmauer ineinandergreifend angeordnet werden; es wird auch Waterfall Layout genannt
Es kann Inhalte mit unterschiedlichen Seitenverhältnissen handhaben, sodass weniger Bedarf besteht, alles zuzuschneiden oder zu verkleinern, um alle Elemente in gleiche Rechtecke zu pressen
Da Inhalte über die ganze Seite verteilt werden, bleibt die Lesereihenfolge beim Scrollen natürlicher, und wenn am unteren Rand per Lazy Loading Inhalte ergänzt werden, müssen bestehende Inhalte nicht verschoben werden

Geschichte des Vorschlags und Standardisierungsdebatte

Einen Mechanismus für Masonry-Layouts in CSS schlug Mozilla im Januar 2020 erstmals als Erweiterung von CSS Grid vor; in Firefox Nightly wurde er als experimentelle Funktion hinter einem Flag implementiert
Apple begann 2022 in Safari Technology Preview damit, den Vorschlag für CSS Grid Level 3 zu implementieren; inzwischen ist er standardmäßig aktiviert
Innerhalb der CSS Working Group gab es unterschiedliche Ansichten zur Grundrichtung
- Einige sahen Masonry nicht als Teil von CSS Grid, sondern als eigenen display-Typ
- Andere waren nicht überzeugt, ob dieses Layout im Web nötig ist oder ob bekannte Websites es nutzen würden
WebKit ist der Ansicht, dass Browser vor einer Veröffentlichung dieser Funktion zunächst einen Konsens der CSS Working Group benötigen

Grundlegende Nutzung: Grid mit deaktivierten Zeilen und nur Spalten

Ein klassisches Masonry-/Waterfall-Layout wird geschrieben, indem man auf das main-Element display: grid anwendet, Spalten definiert und in Zeilenrichtung den Wert masonry angibt

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  gap: 1rem;
  grid-template-rows: masonry;
}

grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr)) erzeugt wiederholt flexible Spalten mit mindestens 14rem Breite
gap: 1rem erzeugt einen Abstand von 1rem zwischen Spalten und Elementen
grid-template-rows: masonry weist den Browser an, keine Zeilen zu erzeugen, sondern Inhalte im Masonry-/Waterfall-Muster aufzufüllen
Dieses Beispiel erzeugt mit vier CSS-Zeilen ein flexibles Layout, das ohne Media Queries oder Container Queries auf verschiedene Bildschirmgrößen reagiert
Der Wertname masonry kann sich vor der Veröffentlichung in Browsern noch ändern

Warum die Spaltendefinitionen von Grid erhalten bleiben sollen

WebKit hat vier Demos erstellt, um zu zeigen, warum Masonry Teil von CSS Grid sein sollte; sie lassen sich unter webkit.org/demos/grid3 direkt ausprobieren
Die Demos sind in Browsern mit Unterstützung für Grid Level 3 zu sehen
- Safari Technology Preview
- Firefox, wenn das Feature Flag für Masonry Grid Layout aktiviert ist
CSS Grid bietet beim Definieren von Spalten viele Optionen
- Feste Größen in verschiedenen Einheiten wie px, em, rem, cqi, lh, ch, ic, cap, vw, svh
- max-content, min-content
- Die Einheit fr
- minmax()
- Größen in %
- auto
Beispielsweise können die erste und letzte Spalte auf eine feste Breite von 14ch gesetzt werden, während die mittleren Spalten flexible Spalten mit mindestens 28ch sind

main {
  display: grid;
  grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;
  grid-template-rows: masonry;
  gap: 1rem;
}

Durch die Kombination von fr-Einheiten und minmax() lässt sich eine zweistufige Flexibilität erzeugen, bei der Spalten in unterschiedlichen Phasen wachsen und schrumpfen
max-content und min-content passen Spaltengrößen an die Inhaltsgröße an und ermöglichen so Anordnungen, die sich vom Anpassen der Inhalte an Spalten unterscheiden
Mit grid-template-columns: 1fr 1fr 2fr 3fr 5fr 8fr; lässt sich etwa eine Fibonacci-Folge nutzen, um Spalten unterschiedlicher Breite zu erstellen
Das Mega-Menu-Beispiel verwendet grid-template-columns: repeat(auto-fill, minmax(max-content, 30ch));, damit jede Spalte groß genug wird, um Linktexte ohne Zeilenumbruch aufzunehmen
WebKit sieht die Diskussion um ein separates display: masonry als in eine Richtung gehend, die ähnlich dem heutigen Multicolumn Layout nur gleich große Spalten erlaubt

Spanning, View Transitions und columnar grid

CSS Grid kann Elemente über mehrere Spalten spannen lassen, wodurch auch in Masonry-Layouts vielfältige visuelle Kompositionen möglich werden
Im Beispiel lässt sich jedes fünfte Bild über zwei Spalten spannen, während die übrigen Bilder nur eine Spalte einnehmen
Auch Varianten sind möglich, bei denen Bilder mit breiterem Seitenverhältnis die Klasse wider erhalten, mehrere Spalten belegen, Ecken rechteckig werden oder Abstände auf 0 reduziert werden
Die Photos-Demo kombiniert dies mit View Transitions: Klickt oder tippt ein Nutzer auf ein Foto, wird dieses über mehrere Spalten hinweg vergrößert, und der Browser animiert den Übergang automatisch
- Diese Demo erfordert Safari Technology Preview 192 oder neuer
WebKit sieht den Kern von Grid Level 3 weniger in einem spezifischen Muster namens „Masonry“ als vielmehr in einem Mechanismus zum Abschalten von Zeilen
Dieser Ansatz erzeugt ein columnar grid, das nur aus Spalten besteht, im Gegensatz zu einem modular grid, bei dem sowohl Zeilen als auch Spalten ausgerichtet sind und das CSS Grid Level 1 gut erzeugt

Unterschied zwischen modular grid und columnar grid

Ein modular grid ist ein Grid, bei dem Inhalte sowohl an Spalten als auch an Zeilen ausgerichtet werden; CSS Grid Level 1 eignet sich für diese Art von Layout
Auch Float-basierte Layouts förderten die Nutzung modularer Grids im Web, weil Inhaltshöhen angepasst werden mussten, damit Floats korrekt bereinigt werden konnten
Auf echten Websites werden häufig Bildseitenverhältnisse vereinheitlicht, Textlängen angeglichen oder Inhalte durch CMS-Regeln beziehungsweise CSS-Zuschnitt und Ellipsen in gleiche Boxen gepresst
Ein columnar grid kann Inhalte in ihrer gewünschten Größe belassen und das Layout passend zu den Inhalten arbeiten lassen
WebKit sieht anhand eines Beispiels, bei dem der neueste Artikel vier Spalten überspannt, einige aktuelle Artikel zwei Spalten und ältere Inhalte eine Spalte belegen, dass sich auch textlastige Inhalte lebendiger anordnen lassen

Kombination von Subgrid und expliziter Platzierung

Subgrid aus CSS Grid Level 2 wird von den meisten Browsern unterstützt
Das Beispiel einer Museumsseite listet die Metadaten von Bildkarten nicht in einer einzelnen linksbündigen Spalte auf, sondern platziert per subgrid Jahr und Katalognummer rechts in jeder Karte und richtet sie mit denselben Daten anderer Karten aus
Wenn Masonry in CSS Grid Level 3 aufgenommen wird, lassen sich auch bestehende Entwicklertools weiterverwenden
- Mit dem Grid Inspector in Safari Technology Preview kann grid-template-rows: masonry ausprobiert werden
Bei einem separaten Display-Typ gingen die Vorteile von Subgrid verloren
Auch die explizite Platzierung aus CSS Grid Level 1 kann zusammen genutzt werden; im Beispiel platziert grid-column: -3 / -1 den Header oben rechts auf der Seite in den letzten beiden Spalten
WebKit ist der Ansicht, dass sich mit wenigen Zeilen Layout-Code Funktionen aus Grid Level 1, 2 und 3 kombinieren lassen, um ohne Media Queries oder Container Queries ein Layout zu erstellen, dessen Spaltenzahl sich je nach verfügbarem Platz ändert

Streitpunkte rund um `display: masonry`

WebKit und Apple sehen Masonry als eine Funktion, die CSS Grid erweitert, sodass es nicht nur modular grids, sondern auch columnar grids erstellen kann
In dieser Richtung lassen sich Grid-Funktionen wie Spaltendefinition, Track Spanning, explizite Platzierung und subgrid zusammen nutzen
Befürworter eines separaten Display-Typs sehen darin eine saubere Trennung der Layout-Typen

display: block;
display: inline;
display: flexbox;
display: grid;
display: masonry;

Die CSS Working Group hat die Syntax eines separaten Masonry-Display-Typs noch nicht diskutiert, WebKit nennt jedoch eine Syntax ähnlich dem Multicolumn Layout oder eine eingeschränkte Grid-ähnliche Syntax als Beispiele

main {
  display: masonry;
  columns: 28ch;
}

main {
  display: masonry;
  masonry-columns: repeat(5, minmax(28ch, 1fr));
                   /* where only one repeating width is allowed */
}

Ein separater Layout-Typ könnte die Arbeit vermeiden, die nötig wäre, um Grid und Masonry dauerhaft gemeinsam funktionieren zu lassen
- Das Layout-Modell wird einfacher
- Die Browser-Implementierung wird einfacher
- Die Wahrscheinlichkeit von Performance-Fallen sinkt
- Die Funktionssets von Grid und Masonry können voneinander abweichen
Umgekehrt ist WebKit der Ansicht, dass bei verbundenen Grid-Layout-Typen die CSS Working Group künftige Funktionen sowohl für modular grids als auch für columnar grids definieren würde
Wenn etwa in CSS Grid Level 4 Funktionen wie Styling für Grid Areas und Grid Lines, Hintergrundfarben für Tracks oder Rule Lines für Gaps hinzukämen, wäre es nach dieser Sicht besser, wenn sie von Anfang an in beiden Grid-Typen funktionieren

Wie „Grid“ zu verstehen ist

Befürworter eines separaten display: masonry sehen CSS Grid teils im Kern als zweidimensionale Ausrichtung und betrachten Masonry, weil es nur in eine Richtung ausrichtet, nicht als Grid
WebKit verweist darauf, dass Grids in der Geschichte des Grafikdesigns Werkzeuge waren, um Text, Bilder und Inhalte in regelmäßigen Mustern anzuordnen und so Lesbarkeit und Nutzbarkeit zu unterstützen
Schon bevor Modernisten des 20. Jahrhunderts in Europa und den USA die Ausrichtung an Spalten und Zeilen als „proper“ Graphic Design Grid betonten, wurden verschiedene Grids genutzt
Mark Boulton sah symmetrische columnar grids als formell und langweilig an und förderte im Webdesign die Nutzung asymmetrischer compound grids
CSS Grid Level 1 machte asymmetrische Grids und compound grids leicht umsetzbar, derzeit gilt das jedoch nur, wenn dieses Grid ein modular grid ist
WebKit ist der Ansicht, dass sowohl modular grids als auch columnar grids Grids sind und dass CSS Grid auch die Fähigkeit haben sollte, columnar grids zu erstellen

Erbetenes Feedback von Entwicklern und Designern

WebKit bittet Entwickler und Designer, selbst Demos zu erstellen, Meinungen in Blogs oder sozialen Medien zu veröffentlichen und Kommentare in Issues der CSS Working Group zu hinterlassen
Die Fragen für Feedback lauten:
- Sollte „masonry“/„waterfall“ Teil von CSS Grid sein?
- Werden Funktionen für columnar grids einschließlich subgrid, Spanning, expliziter Platzierung und vielfältigem Track Sizing benötigt?
- Reicht ein klassisches Masonry-Layout mit gleich großen Spalten aus?
- Würdet ihr diese Funktion tatsächlich nutzen, und was könntet ihr damit bauen?
- Gibt es Links zu Demos, die ihr erstellt habt?
- Gibt es Dinge, die sich mit diesem Modell nicht umsetzen lassen?
Das WebKit-Team arbeitet seit anderthalb Jahren an Masonry; in Safari Technology Preview 163 wurde es im Februar 2023 standardmäßig aktiviert
WebKit möchte die Funktion bald veröffentlichen, doch Details einschließlich des Namens sowie grundlegende Fragen müssen vorher geklärt werden

Namensdiskussion: `masonry`, `waterfall`, `off`

WebKit hält es für sehr wahrscheinlich, dass masonry nicht der beste Name für den neuen Wert ist
CSS-Namen sind häufig einfache Wörter, die das Ergebnis direkt beschreiben, etwa center, contain, clip, wrap, smooth
masonry ist eine Metapher, die Hintergrundwissen erfordert, und kann für Entwickler, die kein Englisch sprechen, schwerer zu merken sein
In manchen Regionen wird dieses Layout häufiger waterfall genannt, sodass auch grid-template-rows: waterfall ein möglicher Kandidat sein könnte
WebKit sieht diese Funktion weniger als Pinterest-artiges Layout an sich, sondern eher als Mechanismus: „Erstelle ein Grid, aber erzeuge keine Zeilen“
grid-template-rows: none; könnte semantisch passen, ist aber nicht nutzbar, weil none bereits der Standardwert von grid-template-* ist und bedeutet: „Keine expliziten Zeilen, nur implizite Zeilen“
Als Alternative wird grid-template-rows: off; vorgeschlagen

main {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(14rem, 1fr));
  grid-template-rows: off;
}

Die CSSWG diskutiert den Namen in diesem Issue
Derzeit verwenden Safari Technology Preview und die Demos entsprechend dem Editor’s Draft den Wert masonry, der Name könnte sich künftig jedoch ändern

1 Kommentare

GN⁺ 2024-04-24

Hacker-News-Kommentare

Der Hintergrund ist, dass die Developer-Relations-Verantwortlichen der Browser-Anbieter in der CSSWG darüber diskutiert haben, wie Masonry-Layouts offiziell in CSS aufgenommen werden sollen. Diese Diskussion läuft mindestens seit 2020, als Firefox den ersten Vorschlag gemacht hat.
Die Neuigkeit ist, dass WebKit diese Diskussion öffentlich gemacht und Designer sowie Entwickler zu konkretem Handeln aufgefordert hat, etwa „postet in sozialen Medien, schreibt Blogbeiträge“.
Oberflächlich kann das wie ein formaler Prozess wirken, aber es könnte einen wichtigen Präzedenzfall schaffen. Der Kernpunkt ist, ob alle Layout-Optionen als Teil von CSS Grid behandelt werden sollen oder ob man bei Bedarf immer wieder neue CSS-Display-Eigenschaften hinzufügt.
Ersteres macht die ohnehin schon komplexe CSS-Grid-Spezifikation noch komplexer, Letzteres könnte die CSS-Spezifikation mit neuen Eigenschaften und Untereigenschaften aufblähen. Keine der beiden Optionen ist so einfach, wie sie aussieht.
- Der Grund, warum es Spannungen gibt, Masonry auf Grid aufzusetzen, ist, dass beide grundsätzlich unterschiedlich funktionieren.
  Grid platziert zunächst alle Elemente im Raster, etwa als col:2,row:3, und bestimmt anschließend die Rastergröße. Masonry möchte idealerweise zuerst die Track-Größen festlegen und dann die Elemente in diese Tracks platzieren.
  Die erste Implementierung in Firefox und die damalige Spezifikation besagten im Wesentlichen, dass Masonry-Elemente – abgesehen von der ersten Zeile und einigen komplizierten Regeln – nicht in die Berechnung der Track-Größen einbezogen werden. Dadurch war es sehr leicht, dass Elemente über ihre Tracks hinausragten.
  Die aktuelle Spezifikation verlangt, jedes Element in jedem möglichen Track auszuprobieren. Im schlimmsten und zugleich ziemlich häufigen Fall ergibt das eine quadratische Performance von O(N_tracks * N_items), und quadratische Performance ist schlecht[1]; in anderen Layout-Algorithmen gibt es so etwas praktisch nicht.
  Mit Verschachtelung verschlechtert sich die Performance quasi exponentiell, und auch schnelle CPUs machen das nicht gut. Man könnte sagen, solche Fälle seien nicht häufig, aber bei CSS-Layout-Modi testen Menschen immer die Grenzen aus, daher müssen sie grundsätzlich schnell sein.
  Bei Grid bestimmt ein Element seine eigene Größe unterschiedlich, je nachdem, in welchem Track es liegt; deshalb muss man jede mögliche Position ausprobieren. Um dieses Problem zu entschärfen, könnte Masonry einen anderen Algorithmus für die Track-Größenberechnung benötigen, aber der Blogbeitrag behandelt diesen Punkt nicht ausreichend. Es hätte vielleicht eine Version der Grid-Größenberechnung ohne Abhängigkeit von der Elementposition geben können, aber dieser Zug ist bereits abgefahren.
  [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
- Ein Grid „ohne Zeilen“ passt derzeit ziemlich gut in die CSS-Grid-Spezifikation. Der Grund ist, dass sich die leistungsfähigen Eigenschaften zur Spaltendefinition und Subgrid wiederverwenden lassen, und die Beispiele zeigen überzeugend, wie orthogonal diese Features zueinander sind.
  Im Wesentlichen reicht grid-row-template: masonry, und der Rest funktioniert weiterhin gut. Das ist positiv, und meiner Ansicht nach macht es Grid-Layouts nicht schwieriger nutzbar als heute.
  Die Nachteile liegen vor allem bei den Autoren von Browser-Engines. Denn die Messlatte für „vollständige CSS-Grid-Unterstützung“ wird höher. Außerdem heißt es, man könne dadurch Performance-Fallen vermeiden, bei denen Implementierungen, die alle Grid-Funktionen unterstützen müssen, in manchen Grid-Layouts langsamer werden als zu einer Zeit, als die Spezifikation noch einfacher war.
  Gäbe es einen separaten Display-Modus, müsste man die grid-column-Spezifikation für Masonry-Layouts wiederholen, und das wäre schade.
- Es ist nicht das erste Mal, dass so etwas an Community-Feedback übergeben wird. Bei verschachtelten CSS-Selektoren lief es genauso, und in Sachen Feedback hat das ziemlich gut funktioniert: https://webkit.org/blog/13607/help-choose-from-options-for-c...
- Beim Ausloten von Kompromissen kann es passieren, dass man die ursprüngliche Präferenz noch einmal überdenkt.
  Das hat nicht direkt mit CSS Masonry zu tun, aber ich habe kürzlich eine zweite Iteration einer Schnittstelle prototypisiert, in der es eine ähnliche Spannung gab. Es ging um die Frage, ob man im Datenmodell ähnliche, aber unterschiedliche Typen vermehrt oder ob man innerhalb bestehender Typen mehr feine Nuancen einführt, um Verfeinerung zu ermöglichen.
  Zu Beginn bevorzugte ich stark Letzteres, aber als ich die Optionen tatsächlich durchgespielt habe, war es am Ende deutlich einfacher, die „aufgeblähte“ Schnittstelle zu konsumieren und den Anwendungscode daraus herzuleiten.
  Zu CSS Masonry habe ich keine starke Position, aber es könnte eine ähnliche Überraschung zwischen der intuitiv wahrgenommenen Spannung und dem tatsächlichen Nutzungserlebnis geben. Gerade bei CSS dürfte es schwer sein, „Aufblähung“, also eine Zunahme an anwendungsfallspezifischer Bedeutung, zu rechtfertigen; zugleich könnten Nutzer aber dazu neigen, dichte APIs wie Grid als schwieriger zu empfinden.
- Es ist gut, dass das so öffentlich abläuft. Ich habe seit letztem Jahr bei allen Beteiligten immer wieder darauf gedrängt. Chrome liegt am weitesten zurück und hat noch keine Unterstützung. Firefox hat Unterstützung hinter einem Flag.
  Ich teste seit letztem Jahr in Firefox und Safari und habe an der Implementierung nichts auszusetzen. Es gibt Leute, die über die Position und die Namen der Eigenschaften meckern, aber man muss wohl anerkennen, dass es keine perfekte Lösung gibt, und pragmatisch implementieren.
  JavaScript als Ersatzimplementierung lehne ich ab. Deshalb enthält der Fallback viel unschönes CSS, das die Reihenfolge nicht korrekt hinbekommt, aber für das Projekt, an dem ich arbeite, ist das kein großes Problem. Im Moment werden die meisten wohl JavaScript als Fallback nutzen, aber wenn JavaScript die Lösung für Layout ist, hat man im Grunde schon verloren.
Die Mega-Menü-Demo <https://webkit.org/demos/grid3/megamenu/> gefällt mir überhaupt nicht, und Masonry dort einzusetzen wirkt völlig unangebracht. Es bringt die Flussrichtung durcheinander und bricht die Erwartungen stark
Erwartete Lesereihenfolge: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2....
Reihenfolge, die die tatsächliche Demo vermittelt: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... Das beeinflusst die korrekte Lesereihenfolge und den Tabindex. Sehende Nutzer lesen praktisch immer in der „falschen“ Reihenfolge
Am Ende zeigt es nur, dass es keine Struktur gibt, sondern bloß eine unstrukturierte Tasche voller Links ist. Wenn man der Nummerierung folgt, wirkt es aber so, als hätte es eine ziemlich logische Reihenfolge gegeben, die durch die unpassende Masonry-Behandlung komplett zerstört wurde
Im Screenshot war „Elementnummern anzeigen“ aktiviert. Normalerweise sieht es wie gewöhnliche Spalten ohne Hintergrund aus
Die Implementierung hätte Spalten verwenden und jedem Abschnitt break-inside: avoid hinzufügen sollen. In der Demo wurde das übersehen
Die Zeitungs-Demo ist aus ähnlichen Gründen ebenfalls etwas fragwürdig, aber ein deutlich kleineres Problem
Bei unabhängigeren Blöcken, etwa Medien wie Bildern, bei denen die Lesereihenfolge nicht so tief verankert ist, passt ein Masonry-Layout besser. Rund um den Tabindex gibt es zwar immer noch etwas Unklarheit, aber es ist nicht mehr offensichtlich falsch
- Wenn damit gemeint ist, dass der Accessibility Tree und die Tab-Reihenfolge die tatsächliche Inhaltsreihenfolge umgehen und Spalte für Spalte durchlaufen, würde ich das als Bug betrachten
  Die Erwartung sehender Nutzer bei einem Masonry-Layout ist nicht, dass es eine Kontinuität zwischen den Spalten gibt, sondern dass sie den visuellen Zeilen folgt. Auch die als „unerwartet“ dargestellte Reihenfolge folgt genau dem
  Das Problem scheint darin zu liegen, dass die Tab-Reihenfolge die ursprüngliche Inhaltsreihenfolge ignoriert und versucht, das Visuelle nachzuahmen; sehr wahrscheinlich ist das ein Überbleibsel der aktuellen Implementierung
- Nur aus Sicht sehender Nutzer wirkt die aktuelle Reihenfolge plausibel. Bei der vorgeschlagenen Variante müsste man häufig nach oben und unten scrollen, um die Elemente der Reihe nach anzusehen, und wenn weitere Elemente hinzukommen, kann es zu großen Layout Shifts kommen
- Könnte man für den Masonry-Effekt nicht einfach das breit unterstützte CSS Multi-column Layout verwenden?
- Es ist doch nur eine beliebige Demo und scheint mit dem eigentlichen Konzept, Feedback zu sammeln, nicht viel zu tun zu haben
Das Gute an dieser Funktion ist: Wenn man sich die Demo in Browsern ansieht, die sie nicht unterstützen, also in praktisch allen aktuellen stabilen Browsern ohne spezielle Flags, wird sie trotzdem in einem recht vernünftigen festen Zeilenformat angezeigt, weil sie direkt auf Grid-Layout aufgebaut wurde: https://webkit.org/demos/grid3/
In jedem Fall sähe ein richtiges Masonry-Layout deutlich besser aus, aber auch so ist es ausreichend nutzbar. Wenn einem das nicht gefällt, kann man per Feature Detection auch eine bessere Fallback-Darstellung anbieten
Mir gefällt die allgemeine Anmutung von Masonry-/Wasserfall-Layouts wirklich sehr. Vielleicht weil ich mit gedruckten Zeitungen aufgewachsen bin und sie immer noch lese, fühlt sich ein spaltenbasiertes Layout wie eine intuitive Art an, eine Seite aufzuteilen
Allerdings hätte ich gern eine Alternative zur standardmäßigen Masonry-Ausrichtung. Soweit ich weiß, lautet die Grundregel etwa: „Platziere das nächste Element in der Spalte, in die es am weitesten oben passt“, wodurch die Links-rechts-Reihenfolge ab der zweiten Zeile stark durcheinandergerät
Eine bessere Variante, wie ich sie mir vorstelle, wäre ein Layout, das den Lesefluss von links nach rechts – oder bei bevorzugter Richtung von rechts nach links entsprechend – stärker bewahrt. Zum Beispiel: „Setze das nächste Element in die Spalte rechts vom vorherigen; wenn es bereits ganz rechts ist, setze es ganz links, und wenn die neue Unterkante nicht zu weit unter die Unterkante der linken Spalte fällt, darf ein zweites Element in derselben Spalte stehen“
Das wäre flexibler als striktes Links→rechts, würde die Ausrichtung weniger stark beschädigen und zugleich die Bedeutung der Leserichtung von links nach rechts in gewissem Maß erhalten
Man kann sicher nicht jede Formel abdecken, die man sich für Masonry wünschen könnte, aber bei Inhalten, bei denen die Reihenfolge zumindest etwas wichtig ist – vielleicht nicht Pinterest, aber etwa bei einem Journal –, halte ich so etwas für einen sinnvolleren Standard als die klassischen Masonry-Regeln
- Ich würde ein Masonry-Layout nur für Dinge verwenden, die von vornherein keine klare Reihenfolge haben. Für chronologisch sortierte Bilder würde ich es vermutlich nicht nutzen
- Das Problem ist die Links→rechts-Ausrichtung selbst. Ich sehe kaum eine Möglichkeit, in diesem Layout links→rechts auszurichten, ohne ständig hin und her zu springen
  Bei einem magazinartigen Layout liest man doch erst Spalten von oben→unten und dann von links→rechts, oder? In CSS ist das bereits mit columns oder einer vertikalen Flexbox möglich
  Ein weiteres Problem dieses Masonry-Layouts ist, dass die Unterkante ungleichmäßig ist. In einem Magazin wäre sie vermutlich ausgeglichen, und auch das lässt sich mit Spalten oder Flexbox erreichen
  Im Web scheint es die unausgesprochene Annahme zu geben, dass Inhalte endlos gescrollt werden und die Form am unteren Seitenrand daher unwichtig ist. Das ist allerdings keine Annahme, die man unbedingt fördern sollte
- Wie wäre es mit so etwas:
  { /* Elemente beim Aktualisieren höchstens um 2 Spalten nach links oder rechts verschieben */ grid-template-max-horizontal-shift: 2 col; }
Angenommen, man könnte ein nicht abwärtskompatibles System schaffen, das CSS ersetzt – wie sollte man vorgehen?
Gibt es Bücher oder Papers darüber, wie man ein konsistentes Layout-System entwirft?
Wie sieht es mit Alternativen wie Qt, Tk oder SwiftUI aus? Außer CSS habe ich nie etwas verwendet. Wenn es unter den tatsächlich breit implementierten Systemen etwas Besseres gibt: Was macht es besser?
Ich wünsche mir ein System, das Entwicklern eine bessere Schnittstelle bietet, weiß aber nicht, wie man das angehen sollte. Wenn man von vorn anfangen könnte: Welche Designprinzipien sollten gelten?
- Ich bin nicht ausdrücklich anti-CSS, aber Konzepte wie Größengruppen, ein vorhersehbarer Zyklus aus Größenanforderung und -zuweisung, Breite in Abhängigkeit von der Höhe, Constraints sowie ausrichtungsbasierte Layouts könnten interessant sein. Außerdem müsste man generell das Durcheinander von in CSS nicht orthogonal miteinander verflochtenen Konzepten aufräumen.
  Eigenschaften sollten expliziter und stärker voneinander getrennt sein. Unsinn wie negative Margins sollte verschwinden, und alle Abstände sollten mehrstufig sein. Zum Beispiel in der Art von padding = max(el.paddings[]).
  Begrenzungsboxen sollten explizit sein, und Rahmen sollten zu echten Elementen werden. Das Box-Modell an sich ist nicht schlecht; CSS hat seine Umsetzung nur furchtbar gemacht. Es ist voller fragiler Zaubersprüche und absurder Einschränkungen, bei denen bei jeder Berührung zu 99 % etwas kaputtgeht – und diese Einschränkungen erzeugen weitere Probleme und „Lösungen“.
- Constraint-basierte Layouts mit dem Cassowary-Algorithmus wirkten eine Zeit lang wie eine populäre Alternative: https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...
  Der Ansatz wurde dafür entworfen, Änderungen von Bildschirmgröße und -form aufzulösen. Apple ist zu SwiftUI gewechselt und hat sich möglicherweise von diesem Ansatz entfernt.
- Ein Artikel, der verschiedene Styling-/Layout-Systeme vergleicht, wäre wirklich interessant. Allerdings gibt es vermutlich nicht viele Menschen mit Erfahrung in mehreren Styling-Sprachen, die so etwas schreiben könnten.
  Flutter und XAML wären wohl ebenfalls einen Blick wert.
- Worauf man bei der Auswahl früherer Referenzfälle achten sollte: CSS legt die Messlatte für deklarative Kontrolle ziemlich hoch. Zu den genannten Dingen kann ich nicht im Detail etwas sagen, aber besser vergleichbare Vorläufer findet man vermutlich eher bei Anwendungsfällen aus dem Druckbereich.
- Ein klassisches Buch zu diesem Thema scheint "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design" zu sein. Gelesen habe ich es nicht.
Ich poste das noch einmal als Top-Level-Kommentar, damit es besser sichtbar ist.
Ich habe eine Foto-Website und verwende kein JavaScript für das Layout. Beim Bau habe ich mir JavaScript-Masonry-Bibliotheken angesehen, war mit den Ergebnissen aber nicht zufrieden.
Ein echtes Masonry-Layout, das tatsächlich den gesamten verfügbaren Raum füllt, schneidet einige Bilder zu. Wenn man nicht zuschneiden und das Seitenverhältnis beibehalten will, muss man um die Fotos herum Leerraum lassen. Die einzige Möglichkeit, das nicht zu tun, ist Infinite Scroll – das mögen die unternehmerischen Suchtmaschinen wollen, aber für meine Website will ich das nicht.
So habe ich es gebaut:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
Um dieses Ergebnis zu erzielen, habe ich display:inline-block verwendet und die Fotos im Grunde wie Text behandelt, der in eine neue Zeile umfließen soll. Mit dem Ergebnis bin ich sehr zufrieden und ziehe es der Vorgehensweise von Masonry-Bibliotheken vor.
- Dieses Layout hätte sich vermutlich mit ein paar Zeilen CSS als zeilenorientierte Flexbox umsetzen lassen, die umbricht und zentriert ausrichtet. Das wäre auch der standardmäßigere Weg.
- Ich verwende kein JavaScript für das Masonry-Layout. Für die aktuelle Masonry-CSS-Lösung gibt es eine Fallback-Darstellung mit unterstütztem CSS.
  Das Problem ist die Reihenfolge. Wenn die Reihenfolge nicht wichtig ist, funktionieren die heutigen reinen CSS-Lösungen gut. Soweit ich mich erinnere, können unten in den Spalten allerdings seltsame Formen übrig bleiben.
- Solche Layouts sind genau das, wofür Flexbox entworfen wurde, daher kann es auch hier eine Option sein.
Dazu habe ich eine interaktive Demo zu den Grid-Prinzipien gebaut:
https://cssprinciples.com/3/grid/
Es gibt bereits das alte float und außerdem moderne Layouts mit Flexbox und Grid; da fragt man sich, ob es richtig ist, CSS immer weiter um „Layout“-Optionen zu ergänzen.
Falls es immer noch Fälle gibt, die nicht abgedeckt sind, könnte es trotz zusätzlicher Komplexität die bessere Lösung sein, ein letztes Constraint-basiertes System zu haben, das alle Layout-Fälle abdeckt. Dann könnten CSS-Frameworks und Utility-Bibliotheken darauf die nächste Generation von Masonry Grids usw. aufbauen.
- Ich bin skeptisch, ob ein Constraint-System tatsächlich ernsthaft geprüft wird. CSS hat bisher stark auf die Vorhersagbarkeit der Layout-Kosten abgezielt.
  Trotzdem kommt der Houdini-Layout-Vorschlag dieser Idee am nächsten. Dabei wird das Layout an einen isolierten JavaScript-Kontext übergeben: https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
  Ehrlich gesagt haben Flexbox und Grid sowie Dinge wie Containment aber bereits viele Probleme gelöst, sodass der Verbesserungsdruck deutlich geringer ist als in der Zeit vor Flexbox.
- Der Kern dieser Bewegung ist, die alten float-Hacks oder die bald veralteten CSS-Grid-/Flexbox-Hacks nicht mehr verwenden zu müssen. Das Masonry-Layout in Firefox fügt tatsächlich eine neue Eigenschaft hinzu, die Grid-Zeilen zusammenklappt; damit ist es im Grunde so implementiert, dass es alle Layout-Fälle abdeckt.
- Das ist Grid Level 3. So kann man es machen:
  display: grid;
  grid-template-rows: masonry;
  Allerdings ist es auf WebKit beschränkt. Ich hatte es im Galerie-Modus meines persönlichen Newsfeeds implementiert und schon im Oktober 2023 wieder verworfen.
- JavaScript ist das endgültige Layout-System. Keine deklarative Sprache kann alle Anwendungsfälle abdecken. Zum Glück muss man sich seit Grid nur noch selten auf JavaScript stützen.
  Ein Constraint-basiertes System läge wohl irgendwo unbeholfen zwischen Grid und JavaScript; ich bin mir nicht sicher, ob das viel helfen würde.
- Wenn es Anforderungen gibt, die CSS-Layout nicht direkt unterstützt, kann man jederzeit ein Layout mit JavaScript erzeugen.
Ich benutze das bereits. In Firefox aktiviere ich es in den Optionen und nutze es für Lesezeichen. Auf Mobilgeräten ist es kein Problem, weil alles einfach untereinander gestapelt wird. Auf Mobilgeräten gibt es kein about:config.
Das letzte Bild zeigt den deaktivierten Zustand.
https://imgur.com/a/o7OyZEW
- So wie ich es verstanden habe, füllen die Masonry-Layout-Regeln zuerst die höchste freie Stelle zeilenweise, wodurch eine unregelmäßige Ausrichtung entsteht. Visuell wirkt es aber so, als wäre es in Spalten ausgerichtet.
  Daher wird sich beim Ändern der Fenstergröße die Reihenfolge der Lesezeichen ändern.
- Probier auf Mobilgeräten Firefox Beta aus :)
Mehr Hintergrund und die Gegenargumente, nämlich die Diskussion, warum display: masonry besser sei als display:grid + grid-template-rows: masonry, findet man ausführlich hier: https://github.com/w3c/csswg-drafts/issues/9041

WebKit bittet um Feedback zur Standardisierung des CSS-Grid-Level-3-„Masonry“-Layouts

Aktueller Stand von CSS Grid Level 3

Warum Masonry-Layouts nötig sind

Geschichte des Vorschlags und Standardisierungsdebatte

Grundlegende Nutzung: Grid mit deaktivierten Zeilen und nur Spalten

Warum die Spaltendefinitionen von Grid erhalten bleiben sollen

Spanning, View Transitions und columnar grid

Unterschied zwischen modular grid und columnar grid

Kombination von Subgrid und expliziter Platzierung

Streitpunkte rund um display: masonry

Wie „Grid“ zu verstehen ist

Erbetenes Feedback von Entwicklern und Designern

Namensdiskussion: masonry, waterfall, off

Verwandte Beiträge

1 Kommentare

Hacker-News-Kommentare

Streitpunkte rund um `display: masonry`

Namensdiskussion: `masonry`, `waterfall`, `off`