Expert-Input: CSS - Funktionsweise und objektorientierte CSS
7.8.2010, der CSS-Tag bei Tschitschereengreen in Dresden: Samstag, 10.30, wir sammelten uns im gemütlichen Balkonraum, draussen regnete es in Strömen. Drinnen wurde das kleine Buffet aufgebaut, entspannter House-Techno machte gute Stimmung. Allgemeines Aufwärmen, Kaffee. Wir, das waren 15 Teilnehmer mit unterschiedlichen Hintergründen: Studierende der TU Dresden, Webdesigner, Programmierer, Freelancer, Angestellte. Frauenquote: 20%.
2 Vorträge waren angekündigt: für den Anfang eine Erklärung von mir, wie CSS funktioniert und ob objektorientierte CSS ein Fortschritt in Sachen Performance, effiziente Workflows und Wartbarkeit sein könnten. Darauf aufbauend ein Vortrag von Chris Kaula über das CSS-Framework SASS.
Gut 3/4 der Teilnehmer arbeiteten direkt mit CSS und müssen sich auch mit Code herumschlagen, den sie zugeliefert bekommen oder den es für Änderungen der Website zu bearbeiten gilt. Die 2 Säulen, auf deren Basis CSS funktionieren, Vererbung und Kaskade, waren zwar bekannt, jedoch nicht in ihren tatsächlichen Unterschieden. Folglich gab es hier für die praktische Arbeit noch ein wenig zu lernen.
Vor dem Hintergrund dessen, was CSS von Haus aus als Basis-Funktionalität mitbringt, wird schnell deutlich, daß objektorientierte CSS (OOCSS) keinen wirklichen Fortschritt darstellen. Um nur einen Punkt zu nennen: die Idee ist es, sich eine Art Coding-Library wie Lego-Steine zu bauen. Damit das funktioniert, müssen die CSS-Anweisungen von den HTML-Elementen getrennt werden. Um nun eine Vererbung von übergeordneten auf untergeordnete Elemente zu realisieren, muss diese im OOCSS erneut programmiert werden. Dabei ist es gerade das Zusammenspiel von Vererbung und Kaskade, auf dem CSS basiert, das den Umgang mit dieser Technik so angenehm macht (Links zu OOCSS im Präsentations-PDF).
SASS als Framework vereinfacht vor allem das Schreiben von CSS: es muss weniger getippt werden, wiederkehrende Elemente können durch Variablen oder Mixins ersetzt werden, Workarounds für Browser-Bugs werden automatisch eingefügt. Die Steigerung der Effizienz beim Erstellen und Warten von CSS besteht vor allem darin, daß weniger Code produziert werden muss und wiederkehrende Code-Schnipsel zentral definiert und geändert werden können. Weniger Code bedeutet u. a. größere Übersichtlichkeit.
Allerdings bedeutet die Arbeit mit SASS auch, sich von der gewohnten Arbeitsweise umzustellen: neben der Voraussetzung einer Ruby-Installation dürfte vor allem die Arbeit in der Kommandozeile (CLI) abschreckend für einen Umstieg wirken. Allerdings dürfte der Aufwand für die Umgewöhnung den Benefit der Effizienzsteigerung bei weitem rechtfertigen.
Um mich in Sachen SCSS (Sassy CSS) vorzubereiten, hatte ich mich mit Nico auf ein CSS-Bierchen verabredet. Meine Skepsis gegenüber Frameworks im Allgemeinen und SASS im Besonderen war schnell ausgeräumt, ich kann keine nachteiligen Auswirkungen auf meine bisherige Arbeitsweise sehen.
Mit Dank an @Hagenburger ein paar Links zu SCSS:
3 Steps to Make Better & Faster Frontends
Authoring Stylesheets with Compass & Sass
Das bestätigte sich auch während des Treffens bei Tschitschereengreen: wer ohnehin gut strukturierte CSS erstellt, wird darin von SASS wohltuend unterstützt, da minimaler Code noch weiter minimiert wird. Es gibt auch eine Möglichkeit, CSS in SASS zu importieren.
In Sachen HTML5 und CSS3 herrschte noch weitgehende Ratlosigkeit: der Umstieg ist noch nicht interessant, weil es noch zu viele Probleme mit der Browser-Implementierung gibt. Daher war unklar, worin genau nun die Vorteile beider neuer Standards liegen könnten.
Mein Fazit: in Zukunft möchte ich mit SASS arbeiten. Es hilft auch im Umgang mit Browser-Kompatibilität für CSS3. Ein ähnlicher Tenor entwickelte sich in der Gruppe, daher ist bereits ein weiteres Treffen in Planung: um den Praxisbezug zu stärken, soll es ein "HandsOn" werden mit richtig zusammen arbeiten. Da freu ich mich schon drauf!
