F-LOG-GE

Grid-Layouts – das neue Tabellenlayout?

Grids sind seit einiger Zeit ein beliebter Ansatz zur Erstellung von Layouts. Es gibt vehemente Befürworter, die allesamt auch attraktive Designs zur Demonstration vorlegen. Ein Grid ist ein Raster, das als Grundlage der Layouterstellung genommen wird. Es wird dabei nicht allein auf die Verteilung von Elementen auf der Seite geschaut. Das Raster soll dem Layout Dynamik verleihen, indem die bisherige Orientierung an Spalten durchbrochen wird und Seitenbereiche unabhängig von Spalten arrangiert werden können. Hinzu kommt ein verstärkter Blick auf die Typographie, das Spiel mit Zeilenhöhen.

Das Konzept von Grids

Das Konzept ist unabhängig von der tatsächlichen technischen Umsetzung. Diese war nie im Fokus. Man kann Grids genauso gut mit einem Tabellenlayout wie mit Floats erstellen. Der Grundgedanke hinter dem Konzept ist eher traditionell als modern, eher Tabellenlayout als Float. Der Seitenaufbau orientiert sich bei Grids nicht mehr primär an Semantik und Inhalt, sondern an der Optik, am Seitenaufbau. Auf dem Raster werden alle Seitenelemente platziert. Über die optimale Aufteilung des Rasters gibt es unterschiedliche Sichtweisen. Die Grundidee ist schon bei grober Betrachtung den traditionellen Layouttabellen sehr ähnlich. Es besteht ein direkter Zusammenhang zwischen HTML und Layout. Einzig die dafür zuständigen Elemente wurden getauscht.

Herkömmliches CSS-Layout geht vom Inhalt aus

Die bei herkömmlichem CSS-basierten Layouts übliche Methode geht folgenden Weg:

Das HTML liefert also Struktur und Inhalt, das CSS entscheidet über die Art und Weise der Präsentation.

Ein solcher Ansatz kann Flexibilität bringen. Nehmen wir an, wir haben ein zweispaltiges Layout mit Floats aufgebaut. Nur durch die Änderung der Float-Richtung können wir aus der linksseitigen eine rechtsseitige Navigation machen. Hierfür müssen wir zwei Eigenschaften im CSS ändern. Auch die Breiten der einzelnen Bereiche kann ich durch eine einfache Modifikation des CSS ändern.

Beim Grid-Layout steht die Optik im Vordergrund

Ein Grid-Layout, wie es Blueprint & Co umsetzen, würde diese einfache Möglichkeit nicht zulassen. Denn in diesen Grid-Frameworks erfolgt die Gliederung der Inhaltemittels der Klassen des Frameworks nicht nach ihrer Funktionen, sondern anhand ihrer späteren Position innerhalb des Rasters. Inhalte werden somit nach rein visuellen Kriterien in ein Zeilen- und Spaltenraster sortiert, ganz ähnlich dem früheren Tabellenlayout.DIV-Container mit unterschiedlichen Klassen ersetzen das gute alte .

Das Verschieben eines Elementes innerhalb des Layouts führt daher zwangsläufig (und das ist das Entscheidene) zu größeren Änderungen im Markup. Denn der zeilen- und spaltenweise Aufbau des Layouts erzwingt ein Umsortieren auch benachbarter Elemente, damit das Raster auch nach der Änderung passt. Dies erinnert stark an die alten Tage des Tabellenlayouts.

Vom Inhalt her gegliedertes HTML lässt sich per CSS deutlich freier Gestalten. Zwar kann auch hier ein Redesign mit Änderungen im Markup verbunden sein, jedoch lässt sich beispielsweise eine floatende Navigation mittels einer Zeile CSS vom linken an den rechten Rand des Layouts verschieben, ohne das Markup zu modifizieren.

Ich empfinde dieses tabellennahe Konzept zur Umsetzung eines Grids als einen Fehler. Doch der Fehler liegt in meinen Augen nicht in der Grundidee des Grid-Layouts begründet. Dirk Jesse hat gezeigt, daß man auch mit seinem YAML ein Grid-Layout erstellen kann. Offenbar liegt das Problem also bei den Entwicklern der einzelnen Grid-Frameworks. Diese vermehren sich in letzter Zeit. Offenbar haben einige Entwickler erkannt, daß die bisherigen Frameworks allesamt Einschränkungen mit sich brachten, die mit ihren persönlichen Bedürfnissen nicht in Einklang zu bringen waren.

Die Entstehung der CSS-Frameworks

Gehen wir mal einen Schritt zurück: was ist der Sinn eines Frameworks? Ein Framework soll dem Anwender Arbeit abnehmen. Es schafft dies, indem es immer wiederkehrende Aufgaben löst, ihre Lösung standardisiert. Auch die Standardisierung der Anwendung ist eine Problemlösung. Der Entwickler muss sich nicht wiederholt Gedanken über die Benamung immer wieder genutzter Seitenbereiche machen.

Bei aller Standardisierung sollten Frameworks den Anwender aber nie über Gebühr einschränken. Es liegt in der Natur der Sache, daß ein CSS-Framework weniger komplex ist, als eines für PHP oder Javascript. Es ist auch schwer, auf einem ähnlich hohen Abstraktionsniveau zu agieren, da CSS jegliche Dynamik und Programmierbarkeit fehlt. Dies ist sicherlich der Hauptgrund dafür, daß es sehr lange dauerte, bis ein wirkliches CSS-Framework entwickelt wurde.

Die ersten Frameworks: YAML und YUI-Grids

Die ersten waren YAML (Oktober 2005) und YUI-Grids (Februar 2006). YAML wurde lange Zeit nur im deutschen Sprachraum beachtet und genutzt, weil eine englische Übersetzung fehlte. Es war von Anfang an auf Flexibilität im Umgang ausgerichtet. Prinzipiell konnte und kann man jegliches Layout damit erstellen. Fixe, flexible und fluide Layouts mit unterschiedlicher Gesamt- oder Maximalbreite sind damit genauso möglich, wie Grid-Layouts. Yahoo hingegen entwickelte sein Framework für die eigene Anwendung. Deshalb waren die ersten Versionen sehr limitiert, flexible Layouts waren Anfangs unmöglich. Man hatte zu Beginn die Auswahl zwischen zwei Breiten. Der Name „YUI-Grids“ ist übrigens irreführend, denn die Idee der Grid-Layouts war nie Grundlage des Frameworks.

So funktionieren Grid-Frameworks

Ergänzend zu diesen beiden CSS-Frameworks entstand im Rahmen der Diskussion über Grid-Layouts ein erstes Grid-Framework. Diesem folgten viele ähnlich gestrickte in recht kurzen Abständen nach. Sie wählten bei der Umsetzung eine andere Herangehensweise, als YAML oder YUI-Grids. Die engere Verzahnung des Layouts mit HTML, wie oben beschrieben, ist eindeutig ein Schritt zurück. Erlauben YAML und YUI-Grids ein Layout beliebiger Anordnung und Breite, schränken die selbsternannten Grid-Frameworks die Umsetzung ein. Ein Grid entsteht immer aus einer mehr oder minder großen Anzahl von Spalten und Spaltenzwischenräumen (dem Grundraster).

Für eine Positionierung eines Elementes innerhalb des Rasters, stellen Grid-Frameworks wie Blueprint eine Vielzahl von Klassen bereit, mit denen sich dessen Lage innerhalb einer „Grid-Zeile“ festlegen lässt und womit bei Bedarf mehrere Spalten des Grundrasters zu einem größeren Block zusammengefasst werden können. Einige Frameworks erlauben auch die Verschachtelung von Containern, wobei dann in der Regel Helfer-Klassen benötigt werden, um die Ausrichtung innerhalb des Elternelements (Randabstände) zu korrigieren.

Dieses Konzept erfordert eine Vielzahl vordefinierter Klassen zur Festlegung von Containerbreiten und Randabständen zu benachbarten Elementen. Alle diese Werte sind jedoch abhängige Größen des Grundrasters. Ändert sich das Grundraster (Spaltenbreite oder Spaltenzwischenraum), ändern sich auch die abhängigen Größen und alle vordefinierten CSS-Klassen müssen angepasst werden.

Wer mit dem zugrunde liegenden Raster nichts anfangen kann, muss sich zwangsläufig sein eigenes Raster erstellen. So ist in meinen Augen die steigende Anzahl an Blueprint-Klonen zu erklären, deren zugrunde liegende Logik unverändert bleibt, es ändern sich nur die Zahlen und/oder Maßeinheiten.

Ein Grid-Layout mit YAML ist flexibel

Auch YAML bietet neben dem spaltenbasierten Layoutkonzept spezielle Grid-Bausteine für Grid-Layouts. Deren Funktionsprinzip ist jedoch ein anderes. Sie sind robuster, da Spaltenbreiten und Zwischenräume einerseits flexibel aber vor allem als unabhängige Größen definiert werden. Sie lassen sich zudem einfach mit dem spaltenbasierten Layoutkonzept von YAML kombinieren, womit auch die funktionale Gliederung der Inhalte wieder leichter möglich ist.

Blueprint ist der falsche Weg

Ich finde es daher schade, daß so viel Energie darauf verwendet wird, ein suboptimales Konzept, wie es Blueprint eingeführt hat, immer wieder zu modifizieren, anstatt mit neuen Ideen an die Sache heranzugehen. Es kann doch nicht unser Ziel sein, mittels Grid-Frameworks die Unflexibilität eines Tabellendesigns nachzuahmen. Vielmehr sollte darüber nachgedacht werden, wie wir Rapid Prototyping, ungewöhnliche und typographisch interessante Layouts und Flexibilität in der Anwendung miteinander kombinieren können. All den Erstellern eines Blueprint-Klons sollte klar sein, daß sie ihren eigenen Beitrag nur auf Grund der Unflexibilität des Originals geleistet haben.

Das Internet ist flexibel

Die große Stärke des Internet ist seine Flexibilität in jeglicher Hinsicht. Doch diese Flexibilität ist nur eine theoretische Größe, solange wir uns selber in der täglichen Arbeit beschränken. Die Browser werden besser, aber unsere Ansätze für moderne Designs stagnieren. Dabei wird in Zukunft die Flexibilität des Internet noch stärker gefragt sein, als es jetzt der Fall ist. Das Medium ist mittlerweile nicht nur etabliert, seine Nutzungsfomen variieren auch stärker als zuvor. Immer mehr Menschen greifen von unterwegs über Handys und Notebooks auf das Internet zu. Der Nutzungskontext ist nicht mehr allein das Büro mit dem Festrechner. Bildschirmauflösungen variieren genauso stark, wie die Fähigkeiten der Betrachtungssoftware oder die Nutzungsmöglichkeiten von Zusatzgeräten wie Mäusen.

Da wir immer weniger wissen oder antizipieren können, in welcher Art jemand eine Webseite konsumiert – von der Diskussion um Barrierefreiheit sehe ich jetzt mal ab – ist es wenig hilfreich, die Nutzungsmöglichkeiten unserer Webseiten einzuschränken.

Es geht bei solch grundlegenden Designansätzen nicht allein um die attraktive Optik. Hübsche Seiten kann man in jeglicher Art erzeugen, auch in Form eines Tabellendesigns. Entscheidend ist der Grad der Flexibilität und der Zugänglichkeit eines solchen Ansatzes. Entscheidend ist auch, mit welchen Grundannahmen an eines solches Design herangegangen wird.

Zukunftsorientiertes Webdesign sollte flexibel sein

Das Internet ist noch ganz am Anfang seiner Entwicklung, auch wenn es sich für einige von uns so anfühlt, als wären sie schon Jahrzehnte dabei. Wir sind gerade erst dabei, die richtigen Ansätze zum Umgang mit dem Web und zur Entwicklung für das Web zu finden. Deshalb muss es Menschen geben, die nicht nur an die schnelle Abarbeitung von Aufträgen, sondern auch einen Schritt weiter denken. Die derzeitigen Grid-Frameworks sind einschränkend. Deshalb sollte mehr Energie auf die Entwicklung eines flexibleren Ansatzes gesteckt werden, als zum wiederholten Mal einen Blueprint-Klon mit den altbekannten Beschränkungen zu schaffen.

Dies ist ein Archiv meines alten Weblogs, das von Oktober 2006 bis Dezember 2022 als Wordpress-Instanz existierte.