alps hypertexte

Warum ein eigenes CSS-Framework?

Es gibt kein CSS-Framework, dass einen Frontend-Entwicker von der Pflicht zur eigenen Mühe entbindet. Frameworks sind keine fertigen Lösungen, sondern Baustein-Sammlungen, die von kompetenten Entwicklern verwendet und an den jeweiligen Projektbedarf angepasst werden können. Es gibt meist mehrere Lösungen für ein Darstellungsproblem; welche die Beste ist, ist eine Frage der Umstände und Anforderungen. Deshalb ist es logisch, dass man nicht immer viel mit dem Framework eines anderen Webworkers anfangen kann, so gut und professionell das Framework auch aufgezogen sein mag. Oft kritisiert wird nämlich der Faktor der Einarbeitung in den Stil eines Frameworks.

Diese Einarbeitungszeit entfällt bei einem eigenen Framework bzw. die mentale Arbeit für die Lösungen wurde schon zu früherer Zeit (im Rahmen eines alten Projektes vielleicht) geleistet. Der Hauptvorteil eines eigenen Frameworks ist jedoch, dass es an die eigene (Projekt-)Geschichte und Anforderungen angepasst ist. Es hat sich sozusagen evolutionär entwickelt, mit dem Entwickler als Selektionsmechanismus.

Die Einarbeitungszeit in fremde Frameworks ist aber nicht das größte Problem. Wenn man die Grundlagen kennt, wird man in einem (fremden) Framework nicht auf große Ãœberraschungen stoßen. Es geht mehr um den eigenen Perfektionsanspruch. Frontend-Entwickler können sich in ihrem Code-Fanatismus schon wie kleine Diven verhalten . Und wenn es schon ein Framework zur eigenen Effizienzsteigerung sein soll, dann bitte auch richtig. Oder anders herum gesagt: Wenn so ein Framework schon Effizienzsteigerung verspricht, dann nehmen Entwickler das auch sehr ernst.

Ein kleines Beispiel, für eine meiner Angewohnheiten: Ich verwende bei den ID- und Klassennamen gerne die CamelCase-Schreibweise. Viele mögen sie nicht, nehmen statt dessen lieber Binde- oder Unterstriche als Trennzeichen für zusammengesetzte Begriffe (wie etwa .sidebar-box oder sidebar_box). Viele finden das "seriöser" und die CamelCase-Schreibweise "alberner" ("Skrippt-Kiddie-mäßig" sagte man mir einmal). Dass ich sie bevorzuge hat einen praktischen Grund: Ich kann mit jedem Editor unter jedem System durch Doppelklick den vollständigen Klassennamen markieren. Bei Wörtern mit Bindestrichen ist das je nach Editor/System nicht der Fall. Und es ärgert mich jedesmal, wenn ich mehr Zeit für das Markieren und Kopieren eines Klassennamens brauche, als für einen Doppelklick. Und dass bei jeder CSS-Klasse und -ID und nur, weil einige Leute Binde- bzw. Unterstriche "seriöser" finden . Also heisst es bei mir .sidebarBox, wenn es eine Klasse ist. Ist es eine ID, dann mit beginnendem Großbuchstaben #SidebarBox. Weil ich dann an der Schreibweise alleine erkennen kann, ob es eine ID oder Klasse ist, wenn sie mal außerhalb des HTML-Kontextes auftaucht. Es verringert dadurch meine Anzahl Fehler, die ID- und Klassenverwechslungen betreffen.

Diese Konventionen sind also nach persönlichen Arbeitsweisen ausgerichtet. Nur wer ein Wort gewohnheitsmäßig per Doppelklick markiert, hat von dieser Konvention einen Vorteil. Andere "Stile" brauchen eben andere Konventionen.

Erfahrungen bestimmen, was reinkommt und was nicht

Das war vorhin ein Beispiel für die Personalisierungsnotwendigkeit von Frameworks im Kleinen. Ein größeres Beispiel wäre eine bestimmte Layout-Technik, von der ich hier schon oft geschrieben habe (Faux Absolute Positioning). Mittlerweile ist es die stabilste und auch flexibelste Layout-Lösung, die ich für Seiten-Layouts kenne. Nicht nur flexibel im technischen sondern auch im anforderungstechnischen Sinne. Stell dir mal vor, du sollst ein PSD-Mockup möglichst detailgetreu in XHTML/CSS umsetzen. Und es wird gesagt "Fix, in Pixeln bitte.". Du machst es, und fertigst schon die 6-7 wichtigsten Seiten nach deinem Layout. Nach 1-2 Monaten im Projekt heisst es dann "Lass uns mal elastisch probieren" (alles schon gehabt). Was machst du jetzt? Bastelst du ein neues Set an CSS-Layout-Klassen und ersetzt dann auf allen Seiten den entsprechenden Markup? Oder gehst du lieber auf Zeile 2 deiner layout-lib.css und änderst die Angabe von .corset { width: 980px; } nach .corset { width: 100%; } um (plus ein paar min- und max-width-Angaben, je nach dem) und hast die Änderung damit erledigt?

Wenn ein Projekt solche Anforderungen an einen Code stellt, muss sich "der Code" an diese Gegebenheit anpassen. Das heisst, mein Framework braucht einen Mechanismus, mit dem es sich auf solche wechselnden Bedingungen (anderer Layout-Typ, unentschiedene Projektleiter/Kunden) einstellen kann.

Es ist in diesem Beispiel natürlich nicht nur mit einer Wertumstellung nach 100% getan, wenn alle beinhaltenden Elemente fest in Pixeln bemaßt wurden. Um so einen Layout-Typ-Umschalter-Mechanismus zu erzeugen, muss man auch von Anfang an alles in Prozenten rechnen. Hat die Box eine Breite von 200px muss man das auf den prozentualen Wert im Umfeld umrechnen. Nur dann funktioniert der Typwechsel wie gewünscht schnell und reibungslos (also ohne Nachbesserungsarbeit im Markup).

Jede Anforderung in einem früheren Projekt schlägt sich im persönlichen Framework nieder. Anforderungen, die Flexibilität auf Seiten des Entwicklers erfordern, etwa, weil ein Projekt nicht detailliert ausspezifiziert ist und sich (manchmal grundlegende) Änderungen während der Implementationsphase ergeben können, schlagen sich in meinem persönlichen Framework als "Schalter" nieder. Wie ich hier schonmal schrieb, sind CSS-Schalter XHTML-Konstrukte mit alternativen Styles (=Darstellungen). Um mit geringstnötigem Eingriff im Markup zwischen alternativen Darstellung umzuschalten, muss man sein Set an CSS-Klassen zu diesem Konstrukt entsprechend aufsetzen. Im obigen Layout-Beispiel sind es die Breitenangaben, die bei allen layoutrelevanten Elementen in Prozenten ausgedrückt sein müssen, damit der Layout-Switch funktioniert.

Weitere CSS-Schalter

Ein anderes Beispiel wären diese Box-Typen aus meinem Framework

Beide Boxen kommen mit dem selben HTML aus bis auf einen Klassennamen. .top ist die CSS-Klasse für die simple Box, .toph für die mit der markanteren Box-Ãœberschrift.

Und so gibt es noch weitere Schalter-Konstruktionen, die die Entwicklung unter einem Motto vereinfachen sollen: Implementiere jetzt, entscheide später (wie es aussehen soll).

Weitere, trivialere Schalter wären zum Beispiel, die Schriftart und -Größe, die mit möglichst wenigen Änderungen umstellbar sein soll. Oder der Layout-Typ der Formular-Elemente:

Auch Datentabellen können innerhalb eines Projekts in verschiedener Darstellung daherkommen. Für diesen Fall separiert man die Layout-Anweisungen (margins, paddings, displays etc.) von den grafischen Anweisungen (colors, backgrounds, borders etc.) und kann so leicht mehrere Farbschemata einer Datentabelle anlegen.

Listen, in denen auf der einen Seite ein Bild und auf der anderen Seite ein bezugnehmender Text steht, kommen häufig vor. Für diese Art von (Aufzählungs)Listen braucht man verschiedene Varianten. Es wird ein Switch benötigt, der zwischen der Anordnung von Bild und Text umschaltet und einer für Bilder in verschiedenen Größen. Da dieses Konstrukt prinzipiell elastisch angelegt sein muss (siehe oben die Anforderung an einen Layout-Swich), erhält das Bild eine fixe Breite in px und ein Float. Der Text hat keine spezifische Breite, aber einen Abstand zum Bild, so dass es immer die zur Verfügung stehende Breite seines Containers ausnutzen kann (sich elastisch verhalten kann). Hier greifen also genau genommen 2 Switches aneinander. Der erste sagt, ob das Bild Links und der Text rechts oder umgekehrt dargestellt werden soll, der zweite innerhalb des ersten Switches bestimmt dann genau die Breite des Bildes in dieser Liste.

Zum Kern der Sache: Seiten-Layout

Was ein CSS-Framework spürbar vereinfachen muss, ist das Erstellen von Seitenlayouts, egal, welchen Typs. Die Float-basierten und absoluten Layouttechniken sind altbekannt, mitsamt aller IE-Anpassungen, die dafür nötig sind. Was weniger bekannt und eingesetzt wird, obwohl seine Vorteile deutlich auf der Hand liegen und eine bestimmte Eigenschaft es für den Einsatz in flexiblen Frameworks prädestiniert, ist die hier vielbesprochene Faux Absolute Positioning-Technik. Die Technik ist im Schnelldurchgang so zu beschreiben:

Du brauchst folgenden Markup:

  <div class="fapline">
    <div class="fapcol fap-00-50">
      Inhalt erste Spalte (links) ...
    </div> <!-- /fapcol -->
    <div class="fapcol fap-50-50">
      Inhalt zweite Spalte (rechts) ...
    </div> <!-- /fapcol -->
  </div> <!-- /fapline -->

... und diese Basis-Klassen:

.fapline { position: relative; float: left; width: 100%; display: block; }
.fapcol  { position: relative; float: left; left: 100%; }

Um jetzt die Eigenschaften einer crossbrowserfesten Layoutspalte zu bestimmen, benötigt man nur noch 2 Angaben:

• Wo fängt die Spalte an?
• Wie breit ist sie?

Für eine 50% breite Layoutspalte, die ganz links beginnt:

.fap-00-50 { margin-left: -100%;  width: 50%; }

Dabei muss man berücksichtigen, dass die Basisanweisung .fapcol die Layoutspalte zuvor 100% rechts aus dem Sichtbereich verschoben hat. Deshalb muss sie per margin-left: -100%; an den Anfangspunkt zurückgezogen werden.

Man erkennt ab diesem Punkt, wie einfach es ist, weitere Layoutspalten nach diesem System hinzuzufügen. Layoutspalten, die keine weiteren Hacks benötigen, ab IE5.x funktionieren, nicht von (user-generated) Content gesprengt werden können, volle Contentreihenfolgenkontrolle im Code ermöglichen und sich sogar überlappen dürfen.

Wenn du willst, dass etwas richtig gemacht wird, mach es selbst

Dass so ein Framework eine Heidenarbeit ist, braucht man nicht zu erwähnen. Aber eine Arbeit, die sich durchaus lohnt, wenn man professionell mehr als ein paar Blog-Themes erstellt. Die Leute, die Frameworks kritisieren, weil man sich 1. darin einarbeiten muss und 2. man immer noch nicht 100 prozentig damit zufrieden ist, sollten die Ärmel hochkrempeln und sich selber eins bauen. Denn ein Fakt ist nicht zu ignorieren: Ein Framework kann die eigene Arbeitsgeschwindigkeit um ein Vielfaches steigern. In der immer effizienter werdenden IT-Welt, ist der Verzicht auf ein CSS-Framework purer Luxus. Einfach kein Framework zu benutzen und sich auch noch damit zu rühmen, jedes Projekt von Grund auf neu zu coden, erscheint aus der Perspektive der materiellen Weltsicht schon fast naiv.