CSS Grid für WordPress-Layouts

Der 6. Dezember 2018 war ein besonderes Datum für WordPress: Es markierte die Veröffentlichung der Version 5.0 der Software, die bis heute mehr als ein Drittel des Webs antreibt. Früher betonten die Leute, die an der Plattform arbeiteten, dass Versionsnummern bei WordPress-Releases nie eine besondere Bedeutung hatten; WordPress 5.0 war somit einfach der Nachfolger von WordPress 4.9. Dennoch brachte 5.0 möglicherweise die größte Innovation seit der Einführung von Custom Post Types in Version 3.0 – das ist fast ein Jahrzehnt her, meine Damen und Herren.

Der Block-Editor – Codename „Gutenberg“ – ist nun das neue Standard-Schreibwerkzeug in WordPress. Bevor er in den Core integriert wurde, setzte unser geliebtes CMS auf den, den wir heute den Classic Editor nennen. Und übrigens, der Classic Editor ist nicht wirklich verschwunden: Sie können ihn zurückbringen, indem Sie ein Plugin installieren, das das von Ihnen seit Jahren gewohnte Standard-Bearbeitungserlebnis wiederherstellt.

Warum wurde also der Classic Editor ersetzt? Im Wesentlichen, weil er ein altes Schreibkonzept verkörperte, ein Konzept, das entwickelt wurde, als die einzige Anforderung an einen Texteditor darin bestand, HTML-Code visuell zu komponieren.

Nicht um Layouts zu erstellen. Nicht um dynamische Inhalte aus heterogenen Quellen einzubetten. Nicht um eine Darstellung dessen zu bieten, wie Ihr Beitrag oder Ihre Seite aussehen würde, wenn Sie auf den „Veröffentlichen“-Button klicken und Ihr Inhalt live geht.

Kurz gesagt, der Classic Editor bot eine sehr grundlegende Schreiberfahrung und stieß bei der Erstellung von mehr als nur Fließtext an seine Grenzen.

Der Block-Editor basiert auf der Idee von Inhalts „Blöcken“, in dem Sinne, dass alles, was wir einer Seite hinzufügen können – ein Textabsatz, ein Bild, ein Embed – technisch ein Block ist, also eine atomare Entität, die durch eine bestimmte Reihe von Eigenschaften definiert ist. Die Kombination dieser Eigenschaften bestimmt den Zustand dieses jeweiligen Blocks. Kombinieren Sie mehrere Blöcke nacheinander, und Sie erhalten den Inhalt Ihrer Seite.

In diesem Übergang von unorganisiertem Text zu rigoroser Inhaltsstruktur liegt die größte Veränderung, die der Block-Editor mit sich bringt.

Layouts vor dem Block-Editor

Bevor all das hier zum Vorschein kam, mussten Leute, die ein Layout in WordPress erstellen wollten, zwischen folgenden Optionen wählen:

1. Eine eigene Vorlage von Grund auf erstellen und sich die Hände schmutzig machen – eine edle Absicht, aber für die breite Masse nicht so ansprechend.
2. Ein Werkzeug verwenden, idealerweise ein visuelles, das ihnen beim Komponieren einer Seitenstruktur half, ohne viel Codekenntnisse zu benötigen.

So entstanden die Page Builder: Page Builder sind Plugins, die eine visuelle Möglichkeit bieten, ein Layout zu erstellen, idealerweise ohne eine einzige Codezeile anzufassen, und sie wurden aus der Notwendigkeit heraus geboren, eine Lücke zwischen visuellen Mockups und der tatsächlichen, fertigen Website zu schließen.

Page Builder hatten aus verschiedenen Gründen schon immer einen schlechten Ruf

1. Sie neigen dazu, langsam und sperrig zu sein.
2. Einige bieten eine schlechte Bearbeitungserfahrung.
3. Sie sperren Benutzer schließlich in einem Framework oder Ökosystem ein, das schwer zu ersetzen ist.

Der erste Punkt ist so offensichtlich wie unvermeidlich: Wenn Sie ein Page Builder-Autor sind (und hoffentlich davon träumen, Exemplare Ihres Produkts zu verkaufen), müssen Sie es so ansprechend wie möglich gestalten; physiologisch wurden Builder langsam zu großen Code-Suppen mit allem darin, zum Nachteil der Leistung.

Der zweite Punkt mag zumindest bis zu einem gewissen Grad subjektiv sein. Der dritte Punkt ist jedoch eine Tatsache. Sicher, man kann mit demselben Werkzeug für jedes Projekt perfekt zurechtkommen und das Wissen über das Instrument mit der Zeit perfektionieren, aber je länger man dabei bleibt, desto schwieriger wird es, es eines Tages nicht mehr zu benutzen.

Der Block-Editor zielt darauf ab, diesen Stillstand zu überwinden: Aus Benutzersicht soll er eine bessere, reichhaltigere Schreiberfahrung bieten, während er aus Entwicklersicht eine einheitliche, gemeinsame API bereitstellt, auf der aufgebaut werden kann.

Eine kurze Geschichte der CSS-Layouts

Wenn Sie alt genug sind, kennen Sie die Geschichte wahrscheinlich schon. Wenn nicht, ist es vielleicht unterhaltsam für Sie zu hören, wie das Leben eines Front-End-Entwicklers früher war.

Die erste Version der CSS-Spezifikation stammt aus dem Jahr 1996 und erlaubte es, mit eingebetteten Stylesheets Schriftstile hinzuzufügen, Farben für Elemente auszuwählen, Ausrichtungen und Abstände von Objekten auf der Seite zu ändern. Das Problem war, dass in jenen Tagen das Konzept des semantischen HTML nicht gerade weit verbreitet war. Mit anderen Worten, es gab keine klare Trennung zwischen Inhalt und Form. Das Markup, das wir schreiben, und das Erscheinungsbild, das wir wollen, waren im selben Dokument vollständig miteinander verknüpft.

Dies führte dazu, dass HTML-Elemente eher für Präsentationszwecke verwendet wurden, als ihrer Anwesenheit auf der Seite Bedeutung zu verleihen. Was das Layout betrifft, so führte dies auch dazu, dass Tabellenelemente für die Erstellung von Layouts anstelle von tatsächlichen tabellarischen Daten verwendet wurden. Um noch komplexere Layouts zu erzielen, wurden Tabellen in andere Tabellen verschachtelt, was die Seite aus semantischer Sicht zu einem Albtraum machte, ihre Größe immer weiter anwachsen ließ und die Wartung im Laufe der Zeit sehr schwierig machte. Wenn Sie jemals HTML-E-Mails codiert haben, dann haben Sie eine gute Vorstellung davon, wie das Leben war. Und ehrlich gesagt, das passiert auch heute noch in Websites, auch wenn es sich eher um kleinere Elemente als um vollständige Seitenlayouts handelt.

Dann kam die Webstandards-Bewegung mit dem Ziel, das Bewusstsein der Entwickler dafür zu schärfen, dass wir die Dinge anders und besser machen könnten; dass Stil und Inhalt getrennt sein sollten, dass wir HTML-Elemente für ihre Bedeutung verwenden müssen und das Konzept stärken, dass eine leichtere Seite (im Hinblick auf den Code-Gewicht) eine grundlegend bessere Option ist als ein unüberschaubares Meer verschachtelter Tabellen.

Wir begannen dann, div-Elemente zu (über-)verwenden und sie mit der `float`-Eigenschaft nebeneinander zu stellen. Der Fokus der Präsentation verschob sich vom Markup auf das Stylesheet. Floats waren jahrelang das zuverlässigste Layout-Werkzeug, aber sie können etwas problematisch zu handhaben sein, da sie cleared werden müssen, damit die Seite zu ihrem Standardfluss zurückkehrt. Auch in dieser Zeit war das Seiten-Markup noch zu redundant, obwohl die Verwendung von divs anstelle von Tabellen dazu beitrug, unsere Inhalte zugänglicher zu machen.

Der Wendepunkt kam 2012 mit der Veröffentlichung der Flexbox-Spezifikation. Flexbox ermöglichte es Entwicklern, eine ganze Reihe langjähriger kleiner Layoutprobleme mit einer eleganten Syntax zu lösen, die weniger Markup für die Implementierung benötigt. Plötzlich (naja, nicht ganz plötzlich, wir müssen uns ja immer noch um die Browserunterstützung kümmern, oder?) war das zuverlässige Zentrieren von Dingen auf beiden Achsen kein Problem mehr. Es war erfrischend. Endlich konnte das Anpassen eines Layouts auf die Änderung einer einzigen Eigenschaft in unserem Stylesheet reduziert werden.

So wichtig Flexbox auch bis heute ist, es ist nicht das Ende der Geschichte.

Es ist 2019! Lassen Sie uns CSS Grid verwenden.

Wenn Sie diesen Beitrag bis hierher gelesen haben, können wir wohl davon ausgehen, dass zwei Dinge sicher sind:

1. Dass wir eindeutig nicht in dieser Branche sind, um ein friedliches, ruhiges Berufsleben zu führen.
2. Dass sich die Dinge, die wir verwenden, ändern werden.

Im Jahr 2017 wurde die CSS Grid Layout Module-Spezifikation offiziell veröffentlicht, aber wie es bei CSS-Specs immer der Fall ist, waren ihre Entwürfe und vorläufigen Implementierungen bereits seit einiger Zeit vorhanden.

CSS Grid ist ein mutiger Sprung in das, was CSS leisten kann und sollte. Was wäre, wenn wir aufhören würden, unsere Seitenstile zu mikromanagen und stattdessen ganzheitlicher zu denken? Was wäre, wenn wir ein System hätten, um Elemente zuverlässig auf dem Bildschirm zu positionieren, das überhaupt nicht von dem verwendeten Markup oder der Reihenfolge der Elemente abhängt und gleichzeitig programmatisch auf kleineren Bildschirmen anwendbar ist?

Nein, das ist nicht nur ein Gedanke. Das ist eher ein Traum; einer von diesen guten Träumen, aus denen man nicht aufwachen möchte. Nur dass es im Jahr 2019 Wirklichkeit geworden ist.

Der Hauptunterschied zwischen Grid und Flexbox ist natürlich nuancierter, aber im Grunde kommt es darauf hinaus, dass Grid zweidimensional arbeitet, während Flexbox auf eine Dimension beschränkt ist. Wenn wir wissen, welche Elemente sich innerhalb der Grenzen eines Containers befinden werden, können wir genau bestimmen, wo diese Elemente landen werden, und zwar ausschließlich über Direktiven im Stylesheet.

Wollen wir das Layout später anpassen? Kein Problem, diese Änderung wirkt sich nicht auf das Markup aus.

Die Grundidee hinter Grid ist, dass Elemente in einem Raster angeordnet werden. Per Definition besteht ein Raster aus einer bestimmten Anzahl von Spalten und Zeilen, und die Grenzen zwischen Spalten und Zeilen bilden eine Reihe von Zellen, die mit Inhalten gefüllt werden können.

Die Einsparungen dieses Ansatzes hinsichtlich der Menge des zur Erzielung des gewünschten Ergebnisses verwendeten Codes sind außergewöhnlich: Wir müssen nur ein Container-Element identifizieren, ihm die `display: grid`-Regel zuweisen und dann Elemente innerhalb dieses Containers auswählen und CSS mitteilen, in welcher Spalte/Zeile sie beginnen/enden.

.my-container {
  display: grid;
  grid-template-columns: repeat( 3, 1fr );
  grid-template-rows: repeat( 2, 1fr );
}

.element-1 {
  grid-column-start: 2;
  grid-column-end: 4;
  grid-row-start: 1;
  grid-row-end: 3;
}

Das obige Beispiel erstellt ein 3×2-Raster, das dem Element `.my-container` zugeordnet ist; `.element-1` ist ein 2×2-Block, der in das Raster eingeschrieben ist, wobei seine obere linke Ecke in der zweiten Spalte der ersten Zeile des Rasters positioniert ist.

Klingt ziemlich raffiniert, oder?

Noch raffinierter an CSS Grid ist die Tatsache, dass man Vorlagenbereiche erstellen, diesen Bereichen aussagekräftige Namen geben kann (z. B. „header“ oder „main“) und diese Identifikatoren dann programmatisch verwenden kann, um Elemente in diesen Bereichen zu positionieren.

.item-a {
  grid-area: header;
}
.item-b {
  grid-area: main;
}
.item-c {
  grid-area: sidebar;
}
.item-d {
  grid-area: footer;
}

.container {
  display: grid;
  grid-template-columns: 50px 50px 50px 50px;
  grid-template-rows: auto;
  grid-template-areas: 
    "header header header header"
    "main main . sidebar"
    "footer footer footer footer";
}

Für diejenigen, die in der Ära der Tabellen in dieses Geschäft eingestiegen sind, ist der obige Code nichts weniger als Science-Fiction.

Mehr gute Nachrichten aber: Die Unterstützung für CSS Grid ist heute ziemlich gut.

CSS Grid in WordPress verwenden

Das ist also großartig, und zu wissen, dass wir heute so viel mehr tun können als noch vor ein paar Jahren, lässt Sie wahrscheinlich Grid endlich ausprobieren wollen.

Wenn Sie an einem WordPress-Projekt arbeiten, stehen Sie wieder vor den beiden oben genannten Optionen: Fangen wir von vorne an und kodieren manuell eine Vorlage, oder gibt es etwas, das uns ein wenig helfen kann? Glücklicherweise gibt es ein Plugin, das Sie interessieren könnte, eines, das wir mit einem doppelten Ziel im Sinn erstellt haben:

1. Eine Brücke zwischen dem Block-Editor und CSS Grid schaffen.
2. Ein Plugin erstellen, das die Leute vielleicht über den anfänglichen Skeptizismus gegenüber der Einführung des Block-Editors hinwegbringt.

Es heißt Grids und ist kostenlos im WordPress-Plugin-Repository erhältlich.

Grids kümmert sich nur um die Layoutstruktur. Es stellt Ihnen ein 12×6-Raster zur Verfügung (genannt Sektion), über das Sie die Elemente (Bereiche) ziehen und zeichnen können, die in dieser Sektion enthalten sein werden.

Das System ermöglicht es Ihnen, Abmessungen, Hintergründe und responsives Verhalten manuell mit visuellen Steuerelementen im Block-Editor festzulegen, bietet aber von vornherein keinen Inhaltsblock. Sicher, man könnte diesen Ansatz als Schwachpunkt sehen, aber wir denken, es ist tatsächlich die größte Stärke von Grids, da es dem Plugin ermöglicht, mit den unzähligen Inhaltsblöcken zu integrieren, die andere Entwickler auf der ganzen Welt erstellen. Mehr noch, Grids trägt dazu bei, diese Blöcke und WordPress als Plattform mit CSS Grid selbst in Kontakt zu bringen.

Auch wenn das Plugin nicht streng genommen Inhalte produziert, ist es unvermeidlich, es in denselben Satz mit erfolgreichen Page Buildern zu stellen und seine Funktionalität mit der von diesen angebotenen zu vergleichen. Wenn Ihnen Konzepte wie Trennung von Form und Inhalt, Seitenlast, Wartungsfreundlichkeit wichtig sind, bietet Grids eine sauberere Lösung für das Problem der Erstellung visuell ansprechender Layouts in WordPress.

Das generierte Markup ist minimal. In seiner grundlegendsten Form besteht eine Sektion (d. h. das Element mit der `display: grid`-Eigenschaft) nur aus seinem eigenen Element – natürlich einem internen Wrapper (der nicht vermieden werden konnte und für Abstände verwendet wird) – und dann einem Element pro Bereich, der zur Sektion gehört. Dies ist ein riesiger Schritt vorwärts, um unnötiges Markup zu vermeiden.

Für diejenigen unter Ihnen, die sich nicht gescheut haben, sich mit der Entwicklung von Blöcken für den Block-Editor zu beschäftigen, erfolgt die Darstellung des Blocks serverseitig, was die Hinzufügung benutzerdefinierter Klassen zu Abschnitts- und Bereichselementen über Filter ermöglicht.

Diese Wahl bestimmt auch direkt, was passiert, wenn Sie Grids in Ihrer Installation deaktivieren.
​​
Wenn Sie Ihre Seite nicht erneut speichern, besteht das, was von Grids im Frontend übrig bleibt, tatsächlich ausschließlich aus den Inhalten, die Sie in die Inhaltsbereiche eingefügt haben. Keine zusätzlichen Markup-Elemente, keine komisch aussehenden Shortcodes.
​​
Auf der Backend-Seite verfügt der Block-Editor über ein System, das Sie warnt, wenn Sie eine Seite bearbeiten, die für einen bestimmten Blocktyp vorgesehen ist, dieser Blocktyp aber derzeit nicht verfügbar ist: In diesem Fall könnten Sie Grids vorübergehend wieder aktivieren, Ihre Inhalte an einen anderen Ort verschieben und dann die Sektion vollständig entfernen.

Das generierte CSS zum Erstellen des Grids wird ebenfalls dynamisch zur Seite hinzugefügt, als Inline-Style im ``-Bereich des Dokuments. Wir waren nicht gerade Fans von Stilen, die direkt auf der Seite geschrieben wurden, weil wir idealerweise die gesamte Formatierung an Dateien delegieren möchten, die wir unter Versionskontrolle stellen könnten. Dies ist jedoch ein Fall, in dem wir diesen Ansatz als sehr praktisch empfanden.

Eine weitere praktikable Option wäre gewesen, alle möglichen Kombinationen von Spalten-/Zeilen-Start-/Endpunkten zu identifizieren und diese programmatisch mit Klassen zu verknüpfen, die dann zur tatsächlichen Positionierung von Elementen innerhalb des Grids verwendet werden könnten. Bei einem 12×6-Raster hätte dies zu insgesamt 36 Klassenselektoren geführt, die wie folgt aussehen:

.grids-cs-1 {
  grid-column-start: 1;
}

.grids-ce-2 {
  grid-column-end: 2;
}

Was wäre, wenn wir beschließen, mehr Kontrolle darüber zu bieten, wie ein Raster zusammengesetzt wird, und den Benutzern zum Beispiel Zugriff auf Optionen geben, die bestimmen, wie viele Spalten oder Zeilen die Rasterstruktur bilden?

Wir müssten die Klassen, die wir noch nicht im Stylesheet haben, manuell zuordnen (und dafür ein Update des Plugins veröffentlichen) oder sie erneut inline generieren und dann diese Klassen zu den Grid-Elementen hinzufügen.

Obwohl dieser Ansatz vollkommen in Ordnung ist, widerspricht er irgendwie der Idee eines schlankeren, besser lesbaren Markups, weshalb wir uns entschieden haben, diesen Weg nicht zu gehen und den Preis dafür zu zahlen, dass der Stil dynamisch in den `head` des Dokuments eingefügt wird, in dem Wissen, dass er leicht gecacht werden kann.

Aufgrund des experimentellen Charakters des Plugins wird die Backend-UI, die zum Erstellen des Grids verwendet wird, mit CSS Grid und einer Reihe von CSS-Variablen erstellt, über die wir die Eigenschaften von Inhaltsbereichen steuern. Die Verwendung von Variablen hat unsere Arbeit hinter dem Grid-Creator-Prototyp immens beschleunigt – hätten wir dort einen anderen Weg gewählt, wären die Dinge nicht nur länger in Bezug auf die Entwicklungszeiten, sondern auch komplexer und weniger klar zu warten gewesen.

Feedback erwünscht!

Um die Einführung von CSS Grid weiter zu fördern, benötigen wir Werkzeuge, die den Prozess der Erstellung von Layouts damit automatisieren.

Während wir großartige Beispiele für diese Technologie in freier Wildbahn gesehen haben, wäre es kurzsichtig anzunehmen, dass jede heute veröffentlichte Website ein Team von Front-End-Entwicklern dahinter hat, die sich um dieses Problem kümmern können.

Wir brauchen Werkzeuge, die gutes Markup erzeugen, die die Wartung der Website-Stylesheets nicht behindern und, am wichtigsten in der WordPress-Welt, die sich leicht in die bestehenden Themes integrieren lassen, die die Leute gerne verwenden.

Wir denken, Grids ist ein Schritt in diese Richtung, da es ein Werkzeug ist, das auf zwei Standards aufbaut – der Block Editor API und CSS Grid – und somit ein geringeres Risiko birgt, das sprichwörtliche Rad neu zu erfinden.

Während wir auf der jüngsten WordCamp Europe in Berlin ein allgemeines Interesse an dem Plugin verzeichneten – mit Matt Mullenweg selbst, der während seiner Keynote eine kurze Demo des Plugins zeigte –, wissen wir, dass es immer noch viel Feedback benötigt, das nur in realen Szenarien gewonnen werden kann. Wenn Sie also Grids ausprobieren möchten, nutzen Sie es, testen Sie es und schlagen Sie, warum nicht, neue Funktionen vor.