CSS3-Spaltenlayouts: Das Template Layout-Modul

Spalten-Layouts sind in Zeitungen und Print-Magazinen ein Standard, der sich im Webdesign bisher leider nur mit Biegen und Brechen simulieren lässt. Neue CSS3-Module versprechen hier Abhilfe. Teil 5 der Artikelreihe über CSS-Spalten-Layouts beleuchtet das neue Template Layout-Modul.

Während wir in den bisherigen Teilen der Serie stets Spezifikationen behandelten, die hauptsächlich von einem Browserhersteller ausgearbeitet und vorangetrieben werden, machen wir jetzt einen Schritt in die andere Richtung und schauen uns den Entwurf eines altgedienten W3C-Haudegen an. Bert Bos arbeitet seit 1996 für das W3C und kann neben Ian Hickson (Google), Tantek Çelik (früher Microsoft) und Håkon Wium Lie (Opera) als einer der CSS-Spezifikatöre angesehen werden. Lesenswert sind unter anderem seine Essays über CSS-Variabeln oder die Grundsätze für eine gelungene Spezifikation.

Das Grundprinzip

Bei Flexbox hatten wir gesehen, wie das letztliche Gesamtlayout durch jedes einzelne beteiligte Element beeinflusst wird. Der Ansatz des Template Layout-Moduls ist dagegen grundverschieden. Wie der Name schon andeutet, wird im Voraus eine Art Schablone (engl.: template) angelegt und auf ein Elternelement angewendet. Die darunterliegenden Kind-Elemente können nun in dieses feste Raster eingegliedert werden. Das Modul verschmilzt auch ein wenig mit dem Grid Layout-Modul, denn das Template kann mit verschiedenen Syntaxen angelegt beziehungsweise erweitert werden. Für das Verständnis des Template-Moduls ist die umfassende Kenntnis des Grid-Moduls aber nicht zwingend notwendig.

Bevor es gleich ans Eingemachte geht, möchte ich an dieser Stelle wieder darauf hinweisen, dass es sich auch bei der Spezifikation zu diesem Modul um einen so genannten Working Draft handelt. Das heißt, dass es jederzeit sein kann, dass Änderungen vorgenommen werden oder Teile aus der Spezifikation verworfen werden. An einigen Stellen in der derzeitigen Version der Spezifikation sind solche Stellen sogar schon markiert. Das Grundprinzip wird sich mit nahezu hundertprozentiger Sicherheit jedoch nicht mehr ändern.

Zum Einstieg ein Beispiel

Wie auch schon Flexbox erweitert das Modul die Display-Eigenschaft um neue Zuweisungen. Darüber hinaus wird die Position-Eigenschaft ebenfalls ausgebaut, um Elemente im Template verankern zu können.

Damit wir mit dem System warm werden, hier ein einfaches Beispiel, anhand dessen die grobe Funktionsweise klar wird.

    <!-- HTML-Auszug -->
    <div class="wrapper">
        <div id="eins"></div>
        <div id="zwei"></div>
        <div id="drei"></div>
        <div id="vier"></div>
    </div>

    /* CSS */
    .wrapper {
        display: "ab"
                 "cd";
    }

    #eins {
        position: c;
    }

    #zwei {
        position: a;
    }

    #drei {
        position: d;
    }

    #vier {
        position: b;
    }

Dieser Code ergibt folgendes Schema:

Hier lassen sich schon einmal syntaktische Vorgaben und prinzipielle Verhaltensweisen ableiten. Der Eigenschaft display können von nun an eine oder mehrere Zeichenketten als Werte übergeben werden, womit man dann ein Template erschaffen hätte. Eine gültige Zeichenkette besteht dabei aus den Buchstaben a-z, dem @-Zeichen oder Punkten. Diese Zeichen können beliebig oft aufeinanderfolgen, aber nie nach einer Unterbrechung nochmals erscheinen. So ist „aaabbccc“ eine valide Zeichenkette, „aabbaacc“ jedoch nicht.

Wie gesagt kann man der Display-Eigenschaft nicht nur eine, sondern beliebig viele dieser Zeichenketten übergeben. Jede dieser Zeichenketten steht für eine Zeile. Im obigen Beispiel wurden diese schon so eingerückt, dass man sich allein von der Position der Zeichen im CSS schon ein Bild vom endgültigen Layout machen kann. Erlaubt wäre es aber auch so:

    .wrapper {
        display: "ab" "cd";
    }

Insgesamt ist nur wichtig, dass alle Bereiche, die durch gleiche Zeichen gebildet werden, stets ein eindeutiges Rechteck darstellen. Keine zwei Rechtecke und keine ausgefallenen Tetris-Formen.

Den Kindelementen weist man nun über die position-Eigenschaft eine Position in der soeben angelegten Schablone zu. Es ist egal, in welcher Reihenfolge die Elemente im HTML ursprünglich auftauchen, mit den Anweisungen lässt sich diese Ordnung komplett umkrempeln.

Eigentlich möchte ich keine bösen Assoziationen wecken, doch der Vergleich des Template Layout-Moduls mit Tabellen-Layouts liegt natürlich nahe und wird sogar in der offiziellen Spezifikation herangezogen. Die größte Parallele ist das Konzept der Unterteilung eines Blocks in Zeilen und Spalten. In Tabellen sind im Normalfall alle Zeilen so hoch wie der höchste Block und alle Spalten so breit wie der breiteste Block. Dieses Prinzip wird von Template-Layout übernommen, wenn auch in mächtigerer und dadurch komplizierterer Form.

[Hinweis (irgendwie unauffällig auffallend gestalten)]Solch ein Template erschafft ein Grid, das heißt, man kann darin mit der Grid-Einheit gr Elemente positionieren oder verschieben.

Die Display-Eigenschaft unter der Lupe

Wie wir eben gelernt haben, kann man der Display-Eigenschaft Zeichenketten, bestehend aus Buchstaben, Punkten oder @-Zeichen, übergeben. Die Buchstabenblöcke stehen für Platzhalter, in die später Inhalte gelegt werden können. Blöcke aus @-Zeichen sind der sog. Default-Slot für Inhalte, die keine gültige Positionierung erhalten haben. Blöcke aus Punkten sind Abstandshalter oder sog. Whitespace. Hierin fließt kein Inhalt. Ein Beispiel für eine komplexere Seitenstruktur könnte also wie folgt notiert werden:

    /* CSS */
    .wrapper {
        display: "aaaaa"
                 "....."
                 "b.@.c"
                 "....."
                 "ddddd"
    }

Wir haben hier einen Header (a), darunter einen Abstandshalter, gefolgt von dem Inhalt und zwei Sidebars (b und c). Es folgt wieder ein Abstandshalter und der Footer (d).

Zukunftsaussichten

Wahrscheinlich ist man erst einmal enttäuscht. Die Template-Notation erlaubt nur rechteckige und eindeutige Blöcke? Gerade hier würde doch die Stärke des Moduls liegen. So ist es austauschbar und sogar weniger flexibel als die „Konkurrenz“. Doch wahrscheinlich ist genau das Wort Konkurrenz der springende Punkt. Wären mehrere gleichnamige Blöcke erlaubt, könnte man mit dem Modul Multi-Column obsolet machen und mit nicht-rechteckige Sektoren käme man mit Float ins Gehege. Bei den vier neuen Layout-Modulen gibt es ohnehin schon zu viele Überschneidungen, muss man da noch mehr Verwirrung provozieren?

Trotzdem ist in der Spezifikation vermerkt, dass es vielleicht in zukünftigen Ausarbeitungen erlaubt sein könnte, mit unterbrochenen Bereichen oder nicht-rechteckigen Blöcken zu arbeiten.

Breiten und Höhen

Wie ich eingangs erwähnte, ist es ganz sinnvoll, die Syntax des Grid-Layouts zu kennen und verinnerlicht zu haben, wenn man mit Template umgehen möchte. Bei allen bisherigen Notationen haben sich die Breiten und Höhen der Zeilen und Spalten durch die Breiten und Höhen der beteiligten Blöcke ergeben. Vom Blick auf die Template-Notation alleine konnte man nicht erkennen, wie breit oder hoch die Spalten und Zeilen einmal werden. Folgendes Beispiel zeigt eine Situation, über die man mehr Kontrolle hat:

    .wrapper {
        display: "a   b   c" /200px
                 "d   e   f" /1*
                 "g   h   i" /100px
                  2*  50% 1*
    }

Ich gebe zu: das sieht verdammt unübersichtlich aus. Bei längerem Hinsehen erkennt man aber das System. Möchte man die Höhe einer Zeile explizit definieren, schreibt man hinter die entsprechende Zeichenkette einen beliebigen Wert. Erlaubt ist neben Pixelangaben und relativen Werten auch die schon bekannte *-Einheit. Wer die genaue Funktionsweise nochmals nachlesen möchte, kann den Artikel zum Grid Positioning-Modul herannehmen.

In der Horizontalen funktioniert das Ganze ähnlich. In der letzten notierten Zeile stehen eine Reihe Werte; jeder Wert gehört zu einer Spalte. Der erste Wert steht für die erste Spalte, der zweite für die zweite und so weiter.

Als Ergebnis aus dem Beispielcode bekommen wir also folgendes Bild zu sehen:

Browserunterstützung

Kein aktueller Browser unterstützt das Modul. Und kein Browserhersteller arbeitet ernsthaft an einer Implementation. Das ist schade; doch man sieht an diesem Beispiel sehr gut, welche Probleme das alte W3C hat. Die Spezifikation könnte noch so toll sein – wenn kein Browser sie unterstützt, ist alles vergebene Liebesmüh’.

Dabei erschwert es die aktuelle Spezifikation den Browser-Ingenieuren noch zusätzlich, denn es ist in dieser Form keine experimentelle Implementation möglich. Bei Flexbox oder Multi-Column – den beiden Modulen, die von nahezu jedem aktuellen Browser schon implementiert sind – werden die neuen Funktionen über Präfixe geregelt. Kein Browser unterstützt das wahre box-flex, doch der Firefox unterstützt -moz-box-flex, Chrome und Safari unterstützen -webkit-box-flex und Opera behilft sich mit -opera-box-flex. Die Möglichkeit dieser so genannten „vendor-specific prefixes“ erlaubt es den Browserentwicklern, sorgloser eine neue Technologie zu adaptieren. Bei dem Template Layout-Modul ist diese Möglichkeit syntaxbedingt nicht gegeben.

Für alle, die dennoch Gefallen an der Syntax gefunden haben, empfiehlt sich dieses jQuery-Plugin, welches das entsprechende Verhalten in JavaScript simuliert.

Fazit

Und am Ende fragt man sich: Wozu das Ganze? Das Modul kann nichts, was man nicht mit Flexbox oder Multi-Column zustande brächte. Es ist unter dem Strich nur ein Modul, das eine bestimmte Sache sehr gut kann: feste Layouts. Man erreicht gleiche Resultate mit Flexbox, aber manchmal kann es sein, dass man die Template-Notation vorzieht. Es ist also eine Geschmackssache. Und dadurch auch eine Glaubenssache, denn die Frage ist: Will man mehrere Spezifikationen haben, die das gleiche Aufgabengebiet aber verschiedene Herangehensweisen haben? Flexbox, Multi-Column, Grid-Layout, Template? Ich jedenfalls, kann diese Frage für mich noch nicht eindeutig beantworten. Während ich es bei Farbnotationen begrüße, die Freiheit zu haben, mit rgb(), hsl() oder Hexadezimalwerten zu arbeiten, bin ich mir bei komplexen Mehrspaltenlayouts nicht mehr so sicher. Verwirrung ist programmiert, sowohl bei Webdesignern als auch bei Browserentwicklern. Ich hoffe indes, ich konnte mit dieser Artikelreihe ein wenig Licht ins Dunkel des CSS3-Modul-Dickichts bringen.

(mm), ™

Weitere Beiträge:

• 5 Ideen wie Sie wiederkehrende Arbeitsschritte & Marketingprozesse gewinnbringend im Internet automatisieren! Ein Gastbeitrag von Robert Nabenhauer.
• Wachstum durch Facebook-Gewinnspiele: Wie Sie über Facebook virale Gewinnspiele & eine schnell wachsende Fangemeinde aufbauen
• Wie Sie aufmerksamkeitsstarke Prelaunch-, Launch- und Relaunch-Szenarien aufbauen und dabei Viralität, Spannung & Kaufkraft erzeugen
• Wie Sie waschechte Iphone-Apps mit PhoneGAP entwickeln, um am lukrativen App-Markt mitzumischen
• Wie Sie Ihr Shop-Sortiment so präsentieren, dass der Kunde in Zukunft mehr findet und eher kauft! Ein Gastbeitrag von Nicolas Schmidt-Voigt.
• 11 faszinierende BuddyPress-Plugins, um kostenlos aus WordPress ein soziales Netzwerk zu zaubern
• Die Vorboten einer neuen Internet-Industrie! Ein exklusiver Rückblick & Blick hinter die Kulissen der Clickbank-Exchange 2011 in New York.