alps hypertexte

Zusammen mit mehreren Backendern und zwei weiteren Frontendern wurde die Code-Basis von semigator.de komplett neu implementiert. Mein Schwerpunkt lag in der grundsätzlichen Layoutumsetzung am Frontend von Semigator.

Die Layout-Lib

Eine Anforderung war, die unterschiedlichen Layouttypen, die in der Semigator-Website existieren, teamgerecht in den Griff zu kriegen. Wer mein Blog schon länger liest, wird sich nicht wundern, dass ich so gar keinen Bock auf Layout-Hacks hatte und deswegen gleich zur FAP-Methode gegriffen habe.

(Siehe frühere Einträge zu Faux Absolute Positioning: Bookmark: Faux Absolute Positioning, Realigned, Drei-Spalter, faux absolute positioniert, imedo.de Relaunch mit "Faux Absolute Positioning"-Technik)

Ein weiterer Grund für FAP war auch, dass ich die verschiedenen Layouttypen, die im Projekt benötigt wurden, sehr leicht in einer layout-lib.css vordefinieren konnte. Unter anderem gibt es folgende Layouttypen bei semigator.de:

• Ein-Spalter über die volle Breite
• Zwei-Spalter, mal im 80:20-, mal im 66:33- und mal im 20:80-Verhältnis
• Drei-Spalter, wie auf der Startseite

In der Layout-Lib sind alle Informationen dazu vorhanden. Sie beginnt mit einem ausführlichen CSSDOC-Block, in der ich auch Layout-Angaben für diverse Maße und Abstände dokumentiere. Dass ich hierbei mit Elementen wie @layout-padding-macro außerhalb der Spezifikation bin, ist mir bewusst, aber auch ziemlich egal . (Ich hätte z.B. für Eigenerfindungen zumindest 'Vendor-specific Tagnames' mit einem beginnenden - oder _ verwenden sollen.) Der Zweck ist die Dokumentation fürs Entwickler-Team, nicht etwa die parsability.

Nach den Definitionen von body, #Canvas und den fürs FAP gebräuchlichen .section und .screen-Styles, kommen die Angaben für die diversen Layouttypen. Ganz unten dann 2-3 Standard-Konstrukte für gefloatete 2- oder 3-Spalter.

Elastizität

Was mich sehr gefreut hat, war die Entscheidung der Geschäftsführung, es mit einem fluiden Layout zu versuchen. Das vorhandene, em-basierte Layout dann auf Fluid umzustellen, war dank dieses Aufbaus im CSS dann auch keine große Sache. Fluid, heisst aber nicht immer schrankenlos Fluid und so skaliert dieses Layout zwischen 980px und 1400px (in Browsern, die diese Bezeichnung verdienen), was bei einigen 3-Spaltigen Seiten oder Seiten mit vielen tabelarischen Daten für ein Atmen des Layouts bei größerem Browser-View-Port sorgt.

Bilschirmfoto: www.semigator.de Vollbild auf einem 22 Zoller.

CSS-Switches

In diesem Projekt habe ich mehr als sonst mit CSS switches (wie ich sie nenne) gearbeitet. Das heisst, dass die Styles eines HTML-Konstrukts abhängig von seiner Container-Klasse sind. Etwa wie im Formular-Mockup vom Web Interface Starter Kit (von dem bereits eine neue, überarbeitete Version in der Mache ist), wo die Anordnung der Labels zu ihren Input-Elementen von der .horiz- oder .vert-Klasse im fieldset- oder sonstigem darüber liegenden Element abhängt.

So gibt es z.B. CSS-Klassen, die entscheiden, ob der main content innerhalb von Boxen mit Schatten oder ganz pur ohne Linien und Schnickschnack in die Landschaft gesetzt wird (<-- was der häufigere Fall ist).

Bilschirmfoto: ... mit Schatten-Boxen.

Bilschirmfoto: ... und ohne alles.

Auch die grafischen Submit-Buttons (4 verschiedene Typen, die in Größe, Farbe und beinhaltendem Icon variieren) kommen mit dem selben Markup aus und lassen sich per CSS-Klasse im Anchor umswitchen.

Bilschirmfoto: Button-Typen auf Semigator.

Die oben beschriebene layout-lib.css ist selbst eine Sammlung von Schaltern. Die entsprechenden Klassen müssen nur dem FAP-.section-Element hinzugefügt werden und man hat automagisch eine crossbrowserfeste Layoutspalte mit den gewünschten Eigenschaften. Und so gibt es weitere kleine Schalter, die den Frontender in die Lage versetzen sollen, häufig wiederkehrende Markup-Konstrukte bequem zwischen vordefinierten Stilen umschalten zu können.

Diese Switches sind alle aus einer Notwendigkeit im Projekt entstanden und vielleicht nicht universell anwendbar bzw. machen nur im speziellen Fall Sinn. Sie haben alle einen großen Vorteil: Man kann erst mal das Wesentliche reinkloppen und später immer noch entschieden, ob das im Typ A- oder Typ B-Stil dargestellt werden soll [Agile und flexible Grüße an die Scrum-Ecke .... ;-)]. Und wie wir wissen, beginnt Webdesign mit dem Content, nicht mit dem Design.

Was ich aus diesem Projekt mitnehme

Nochmal hat sich gezeigt, das agile Entwicklung und Flexibilität in Relaunch-Projekten eine Frage der Vorbereitung und des Tool-Sets sind, das man als Webworker im Gepäck hat/haben sollte. Ich persönlich werde mich in Zukunft noch intensiver mit CSS-Schaltern, Parametrisierung und Wartbarkeit von Frontend-Code beschäftigen. Entwicklungen wie SASS oder CSS3 zeigen, dass es genau in diese Richtung geht.