Freches CSS: Cascading Style Sheet einfacher und effizienter schreiben

CSS-Dateien eines grossen Webprojeks können schnell einmal unübersichtlich werden. Kursleiter Alex Kereszturi zeigt, wie man mit Hilfe einer CSS-Metasprache den Überblick behalten kann.

Autor Alex Kereszturi
Datum 14.05.2014
Lesezeit 9 Minuten

Wer schon einmal mittlere oder umfangreichere Webprojekte umgesetzt hat, weiss: CSS-Dateien können mit der Zeit gross und unübersichtlich werden. Viele Wiederholungen machen das Erstellen ineffizient und den Überblick über die Selektoren zu behalten, ist nicht immer einfach. Zwei dafür verantwortliche Mankos von herkömmlichem CSS sind in der Gemeinde der CSS-Schreibenden schon länger bekannt:

  • CSS kennt (noch) keine Variablen. Gleiche Werte müssen immer und immer wieder getippt werden.
  • CSS kennt das Verschachteln von Selektoren nur bedingt. Ausser bei Media-Queries können Selektoren (noch) nicht verschachtelt werden.

Schon nach wenigen Suchanfragen in Google findet man aber sogenannte CSS-Metasprachen wie LESS, Stylus oder SASS, die einem genau diese zusätzlichen Features versprechen. Mir persönlich gefällt eine SASS-Abwandlung namens SCSS am besten, die mir auch für Anfänger und Einsteiger geeignet erscheint. SCSS steht für Sassy CSS, was auf Deutsch so viel wie «Freches CSS» bedeutet.

Vorbereitungen und Installation

Wie man SCSS zu «fliegen» bringt, findet sich auf http://sass-lang.com/install in vier Schritten einfach und kompakt erklärt. Wichtig ist dabei, wirklich zuerst den «Ruby Installer» von http://www.rubyinstaller.org/ zu installieren. Hat das geklappt, ist der Rest zwar auch ein Kinderspiel, aber man muss halt immer wieder dran denken (wenn man nicht weiss, wie man sich z.B. mit Autostart u.Ä. helfen könnte).

Nach der Installation legt man sich für den Anfang am besten zwei Übungsordner auf der Festplatte an. Nennen wir sie hier einmal «C:\input-scss\» und «C:\output-css\».

Dann startet man die «Command Line mit Ruby», die nach der Installation von Ruby zur Verfügung steht und sobald man sich auf C:\ befindet, kickt man das Ganze mit folgender Zeile an:

sass --watch input-scss:output-css

Jetzt fehlt nur noch etwas Code im Input-Ordner …

Erste Gehversuche

Sobald man nun eine (ganz normale ASCII-) Datei z.B. als style.scss in den Input-Ordner speichert, wird sie automatisch analysiert und umgewandelt und das Ergebnis als style.css in den Output-Ordner gelegt. Einfach, oder?

Werfen wir kurz einen Blick auf die zwei oben erwähnten Mankos von herkömmlichem CSS und wie SCSS damit umgeht:

  • 1. Konzept: Variablen

Das Screendesign gibt beispielsweise einen margin-bottom von 11px vor. Jetzt kann es vorkommen, dass ich im CSS diesen Margin mehrere Male zu schreiben habe:

h1 { margin-bottom: 11px;}
h2 { margin-bottom: 11px;}
p { margin-bottom: 11px;}

Wenn sich jetzt die Vorgabe von 11px auf 13px ändert, darf ich das an drei Stellen korrigieren. SCSS vereinfacht das folgendermassen:

$abstandunten: 11px;
h1 { margin-bottom: $abstandunten;}
h2 { margin-bottom: $abstandunten;}
p { margin-bottom: $abstandunten;}

Mit einem vorangesetzten «$» lassen sich Variablen definieren, die dann anschliessend in den Deklarationen verwendet werden können.

  • 2. Konzept: Verschachtelung

Will ich ein H1-Tag in einem DIV mit der Id «spalte-rechts» anders formatieren als sonst auf der Seite, sieht das in CSS ungefähr folgendermassen aus:

div.spalte-rechts h1 {
 color: green;
}

Mit SCSS sieht das zwar auf den ersten Blick vielleicht komplizierter aus …

div.spalte-rechts {
  h1 {
   color: green;
 }

}

… es erlaubt einem aber, die Anweisungen für den DIV-Tag direkt am selben Ort zu erfassen:

div.spalte-rechts {

background-color: #ccc;

 h1 {
   color: green;
 }
}

Das spart nicht nur Aufwand, sondern verbessert den Überblick enorm, weil man Selektoren nicht redundant erfassen muss.

Fortgeschrittenes

Doch SCSS bietet noch mehr.

  • 3. Konzept: Imports

Hier lohnt sich ein kleiner Exkurs in die Performance-Optimierung von Websites.

Auch herkömmliche CSS-Dateien sind in der Lage, mit dem Befehl «@import» andere CSS-Dateien zu inkludieren. Viele Webdesigner machen sich das zu Nutze, um eine bessere Übersicht über den CSS-Code zu erlangen. Da der Browser aber zuerst die inkludierende CSS-Datei herunterladen muss, bis er weiss, welche anderen CSS-Files er ebenfalls noch herunterzuladen hat, frisst das an der Performance.

SCSS schafft auch hier Abhilfe:

@import "schriftarten"

Diese Zeile sucht automatisch nach der Datei «schriftarten.scss» – man kann hier also die Dateiendung sogar weglassen, wenn man will. Alle so inkludierten Dateien werden in eine einzige CSS-Datei zusammengeführt. Dank Aufteilung in unterschiedliche Dateien behalte ich als Entwickler den Überblick und der Browser braucht in der Live-Website nur eine CSS-Datei zu laden, was performanter ist.

  • 4. Konzept: Mixins

Mixins sind in SCSS das, was in Programmiersprachen die Funktionen sind. Um den Rahmen nicht zu sprengen – über dieses Konzept könnte ich drei eigene Blog-Beiträge schreiben – «nur» ein kleines Beispiel:

@mixin spezialklasse($meinselector)
{
body #{$meinselector}.spezialklasse {
  background-color: yellow;
  }
}

Nach diesem Code ist der Mixin namens «spezialklasse» vorbereitet und braucht nur noch verwendet zu werden. Einzelne Zeilen, die mit @include beginnen, …

 @include spezialklasse("h1");
@include spezialklasse("p span");
@include spezialklasse("div.beispiel");

…werden – gemäss der Mixin-Definition – automatisch wie folgt umgesetzt:

body h1.spezialklasse {
background-color: yellow; }
body p span.spezialklasse {
  background-color: yellow; }
body div.beispiel.spezialklasse {
  background-color: yellow; }

Man nehme sich ruhig zwei bis drei Minuten Zeit, um genau zu verstehen, was das für Möglichkeiten mit sich bringt. Die Begeisterung stieg bei mir von Minute zu Minute.

Was auch sein muss: Vor- und Nachteile von SCSS

Damit ich persönlich eine Technologie für Webprojekte nutze, muss sie folgende Kriterien erfüllen, aus denen sich gleichzeitig die Vor- und Nachteile ergeben:

  • Die Technologie muss relativ unabhängig von Installationen «überall» nutzbar sein. Ein Text-Editor und ein Browser sollten zum Entwickeln ausreichen.

HTML, CSS und JavaScript erfüllen dieses Kriterium. SCSS benötigt Ruby. Das ist ganz klar ein Nachteil. Auf dem Laptop meiner Frau entwickle ich also nicht mit SCSS. Da aber heute kaum wegzudenkende Technologien wie PHP oder MySQL so oder so eine (Server-)Installation benötigen, relativiert sich dieser Nachteil, sobald ich SASS/SCSS auf dem Server installieren kann.

  • Die Technologie muss mit einem Text-Editor und einem Browser debugbar sein.

Schleicht sich ein Bug in ein SCSS-File ein, zeigt mir die «Command Line mit Ruby» schön den Fehler an und auch im Output-File kann ich nachlesen, was ich falsch gemacht habe:

Dazu braucht es aber wieder ein installiertes Ruby.

  • Die Technologie muss mit Typo3 kompatibel sein.

Die meisten Webprojekte setze ich mit Typo3 um. Da bin ich froh, dass es für SASS/SCSS eine eigene Extension namens «Sassify» gibt: http://typo3.org/extensions/repository/view/sassify

Wird diese in Typo3 integriert, braucht auf dem Server nicht einmal mehr Ruby oder SASS zu laufen. Der Nachteil hier: Während der Entwicklungsphase müssen die CSS-Dateien immer wieder neu kompiliert werden, was das Testen verlangsamt. Es empfihelt sich also eine lokale Entwicklung. Dank intelligentem Caching der Typo3-Extension steht einem Live-Betrieb aber nichts im Wege.

  • Die Technologie muss Co-Worker-tauglich sein.

Unter «Co-Worker-tauglich» verstehe ich die Idee, dass bei kleinen einfachen Änderungen auch mal ein interessierter Laie oder Semi-Profi anpacken kann. Doch woher weiss z.B. ein Redaktor, auf welcher Zeile eine Anpassung zu machen ist? Mit herkömmlichem CSS ist das dank den Developer-Tools in modernen Browsern kein Problem: Rechte Maustaste auf das Element klicken, «Element untersuchen» wählen und schon zeigt der Browser (hier im Screenshot Chrome) an, in welcher CSS-Datei und auf welcher Zeile die entsprechenden Anweisungen zu finden sind.

Ein mittels SCSS generiertes Ergebnis kann so aber nicht analysiert werden. Denken wir nur an die Imports und die Mixins. Zum Glück gibt es auch hier Abhilfe. SASS Inspector ist z.B. ein Chrome-Plugin mit dem man die Herkunftszeile aus dem SCSS-File ausfindig machen kann. So kann auch ein Redaktor oder ein interessierter Kunde selbst eine kleine Anpassung vornehmen.

Fazit

Trotz einiger Nachteile nutze ich als Familienvater sehr gerne SCSS für meine Projekte. Das Coden geht schneller und intuitiver. So habe ich mehr Zeit für meine Kinder. Nur ab und zu passiert es mir, dass ich versuche, SCSS-Code in einer herkömmlichen CSS-Datei zu verwenden.


Über den Autor

Alex Kereszturi

Alex Kereszturi ist Web Solution Developer der ersten Stunden, Trike-Fahrer und Hobby-Psychologe. Als einer der ersten «Webpulisher SIZ» und als «Adobe Certified Instructor» entwickelt er seit seinem 15. Lebensjahr Lösungen für das WWW, Mobilgeräte und andere Lebenslagen. Er ist seit bald 25 Jahren Kursleiter bei Digicomp, liebt das Sein in der Natur und setzt bei seinen Schulungen auf einen guten Mix aus Information, Praxisübungen und Unterhaltung. Als Inhaber und CEO führt er die Smilecom GmbH als ein kleines aber feines Software-Entwicklungs-Unternehmen und immer wieder ein turbulentes Familienleben mit drei Töchtern.