Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Effiziente CSS-Entwicklung mit Sass und Compass (Teil 1)

Effiziente CSS-Entwicklung mit Sass und Compass (Teil 1)

Das Erstellen und Warten umfangreicher Stylesheets ist aufwändig und zeitraubend. Mathias Schäfer stellt die CSS-Werkzeuge Sass und Compass vor, die die Produktivität entscheidend verbessern.

Sobald eine Webseite umfangreich und ihre Inhalte komplexer werden, wachsen auch die Stylesheets an. Dabei zeigt sich schnell: CSS ist umständlich und der nötige Arbeitsaufwand steigt unverhältnismäßig. Formatierungen wiederholen sich häufig, sodass Änderungen und Erweiterungen viel Zeit erfordern.

Eine erste Maßnahme ist es, die Formatierungen in Module aufzuteilen. Die Grundmodule nehmen Vereinheitlichungen vor, definieren etwa die Basis-Typographie und bieten wiederverwendbare Styles für Spaltenlayout. Darauf bauen Module auf, die das konkrete Layout und die Inhalts-Container umsetzen. So lassen sich gewisse Wiederholungen vermeiden und Aufgaben entkoppeln. Ein solches Baukastensystem findet sich beispielsweise beim YAML-Framework.

Diese Arbeitsweise stößt bei wachsender Projektgröße an ihre Grenzen. Ein Lösungsansatz ist Objektorientiertes CSS (OOCSS), ein radikaleres Konzept zur Modularisierung. Module werden streng mit Klassenselektoren definiert und im HTML durch mehrere Klassen angewendet. Ein Nachteil ist, dass mit den Klassen oftmals wieder Informationen zur Präsentation ins HTML gelangen.

Neue CSS-Fähigkeiten durch Präprozessoren

Ein weiterer Lösungsansatz verlagert die Modularisierung auf die Entwickler- bzw. Serverseite. Zunächst wird eine neue Sprache definiert, die CSS sehr ähnelt. Sie vereinfacht die CSS-Syntax und erweitert sie um neue Fähigkeiten. Diese Metasprache wird anschließend von einem Programm, Präprozessor genannt, wieder in normales CSS übersetzt. Während der Webentwickler den Komfort der Spracherweiterungen nutzen kann, bekommt der Browser gewöhnliches CSS geliefert.

Sass – Syntactically Awesome Stylesheets

Mittlerweile gibt es verschiedene ausgereifte CSS-Präprozessoren. Dieser Artikel widmet sich Sass, einer etablierten, leistungsfähigen Software. Sass ist kostenlos und wird aktiv fortentwickelt.

Sass definiert zunächst ein Dateiformat mit der Endung .scss. Webautoren können solche Dateien schreiben, um die Erweiterungen zu nutzen. Zudem besteht Sass aus einem Kommandozeilen-Programm, das .scss-Dateien in gewöhnliche .css-Dateien übersetzt. Immer wenn ein Webworker die Webseite im Browser testet oder auf den Zielserver hochlädt, wird dieser Übersetzer aufgerufen.

Die SCSS-Syntax ist eine Obermenge der gewöhnlichen CSS3-Syntax des W3Cs. Das heißt, ihr könnt bestehende .css-Dateien einfach in .scss umbenennen. Der Sass-Übersetzer versteht diese bereits und wandelt sie in in korrektes CSS um.

Der Standard-Übersetzer von Sass ist in der Programmiersprache Ruby geschrieben. Um diesen auszuführen, bedarf es einer installierten Ruby-Interpreter. Unter Mac OS, diversen Linux-Distributionen und auf Unix-basierten Servern ist Ruby oft vorinstalliert oder lässt sich über Paketmanager schnell installieren. Für Windows existiert ein einfaches Installationsprogramm. Hinsichtlich der genauen Installation und Verwendung des Übersetzers sei auf das offizielle Tutorial sowie die Referenz verwiesen.

Neben der maßgeblichen Ruby-Umsetzung gibt es eine PHP-Umsetzung, die die nahtlose Einbindung in verbreitete PHP-basierte Systeme wie TYPO3, WordPress und Drupal ermöglicht.

Compass – CSS 3 effizient anwenden

Während Sass Spracherweiterungen und den passenden Übersetzer bietet, baut Compass damit ein Framework. Compass ist quasi die Standardbibliothek für Sass und bietet vieles, was auch gängige CSS-Frameworks enthalten. Sie stellt eine große Anzahl von Mixins zur Verfügung (dazu später mehr), darunter Reset-Styles, Clearfixes sowie bewährte CSS-Hacks. Daneben ermöglicht Compass das automatisierte Erstellen von CSS-Sprites.

Der Schwerpunkt von Compass liegt darauf, die Anwendung der neuen CSS3-Techniken zu vereinfachen. Compass erlaubt eine einheitliche Schreibweise, die in verschiedene Eigenschaften mit Hersteller-Präfixen übersetzt wird. Damit müssen Entwickler sich keine Gedanken mehr machen, ob sie alle Browser abdecken und die aktuelle, vom W3C empfohlene Schreibweise verwenden. Es reicht, mit einer Codezeile einen Compass-Helfer einzubinden und die Compass-Version aktuell zu halten.

Obwohl Compass eine sehr umfangreiche Bibliothek ist, landen im generierten CSS-Code nur die Teile, die auch tatsächlich genutzt werden. Die eigenen Stylesheets müssen also keine riesigen Dateien einbinden, sondern können punktgenau Compass-Helfer aufrufen. Richtig angewandt kommt der entstehende Code weitgehend ohne Wiederholungen aus.

Im Folgenden lernt ihr die wichtigsten Features von Sass und Compass kennen.

Verschachtelung

Sass erlaubt das Verschachteln von CSS-Regeln. Damit kann die Verschachtelung der Regeln die Verschachtelung der Elemente im HTML-DOM widerspiegeln. Beispiel:

  1. .tabs {
  2.   height: 27px;
  3.   padding: 0 10px;
  4.  
  5.   li {
  6.     float: left;
  7.     height: 23px;
  8.     overflow: hidden;
  9.     padding: 5px 2px 0;
  10.  
  11.     &.active {
  12.       height: 24px;
  13.       padding: 4px 1px 0;
  14.       a {
  15.         background: white;
  16.         padding: 4px 12px 5px;
  17.       }
  18.     }
  19.   }
  20. }

Der Selektor einer verschachtelten Regel wird mit dem Selektor der darüberliegenden Regeln kombiniert, sodass in der Regel ein Nachfahrensselektor entsteht. Der obige SCSS-Code wird in folgende vier CSS-Regeln übersetzt:

  1. .tabs {}
  2. .tabs li {}
  3. .tabs li.active {}
  4. .tabs li.active a {}

Das Zeichen & wird durch den Eltern-Selektor ersetzt, sodass dieser z.B. durch eine Klasse oder Pseudo-Klasse eingegrenzt werden kann.

Diese Schreibweise verbessert die Übersicht im Stylesheet, da zusammengehörige Styles in einem Block stehen. Sie verführt Sass-Einsteiger leider dazu, den HTML-Baum im Stylesheet komplett abzubilden. Dies führt lediglich zu komplexen, ineffizienten Selektoren und verhindert Modularisierung. Selektoren sollten so spezifisch wie nötig und so einfach wie möglich sein. Daher lautet eine Grundregel, den Code möglichst wenig verschachtelt zu halten. Dadurch bleibt der Code wiederverwendbar und das Modul ist nicht an einen bestimmten Kontext gebunden.

Variablen

Für ein stimmiges Layout ist es erforderlich, dass Größen, Abstände, Farben und Schriftgrößen über Module hinweg identisch sind. Leider wiederholen sich diese Werte oftmals und werden mit anderen verrechnet, was spätere Änderungen unter Wahrung der Konsistenz sehr schwierig macht. Sass führt Variablen ein, um diesem Problem zu begegnen. Variablen werden global (z.B. in einer zentralen Datei) oder nur für eine Regel und deren verschachtelte Regeln definiert.

  1. // Globale Variablen:
  2.  
  3. $flashy-green: #80AA00;
  4.  
  5. $box-background-color: #fff;
  6. $box-border-color: #c7c7c7;
  7.  
  8. $std-padding: 10px;
  9.  
  10. // Anwendung:
  11.  
  12. h1, h2, h3 {
  13.   color: $flashy-green;
  14. }
  15.  
  16. .box {
  17.   margin: 0 auto ($std-padding * 2);
  18.   border: 1px solid $box-border-color;
  19.   padding: $std-padding;
  20.   background-color: $box-background-color;
  21. }
  22.  
  23. .modal {
  24.   // Variable für diese Regel
  25.   $width: 600px + (2 * $std-padding);
  26.  
  27.   position: absolute;
  28.   position: fixed;
  29.   top: 20px;
  30.   left: 50%;
  31.  
  32.   margin-left: -($width / 2);
  33.   border: 5px solid $flashy-green;
  34.   width: $width;
  35.   padding: $std-padding;
  36. }

Das obige Beispiel zeigt auch, dass ihr mit Variablen rechnen könnt. Im generierten CSS-Code stehen die Ergebnisse dieser Berechnungen.

Morgen folgt der zweite Teil des Artikels.

Kommentare

datenkind
am 04.12.2011 - 10:09

Hast du PHamlP schon mal getestet? Weißt du, ob das Teil zuverlässig arbeitet? Ich hatte bei Stack Overflow ein paar negative Kommentare gelesen.

Permanenter Link

Bertram Simon
am 04.12.2011 - 15:21

Nur um die Liste zu vervollständigen, es gibt auch noch Less [ http://lesscss.org/ ], Google Closure Stylesheets [ http://code.google.com/p/closure-stylesheets/ ], Turbine [ http://turbine.peterkroener.de/ ] und einige mehr.

Insgesamt bin ich bei der Nutzung von Präprozessoren zwiegespalten. Auf der einen Seite wird die Arbeit deutlich einfacher und schneller. Auf der anderen Seite bedient man eine weitere Zwischenschicht und nutzt Ressourcen, die man nicht selbst erstellt hat. Außerdem darf man den Aufwand, eine funktionierende Umgebung aufzubauen (die u.a. eine IDE mit passenden Syntax beinhaltet), nicht unterschätzen.

Jedenfalls unter Windows ;)

Ich persönlich nutze ebenfalls Compass. Allerdings mag ich den .sass-Syntax lieber, weil er weniger Platz verbraucht und übersichtlicher ist.

Permanenter Link
Mathias Schäfer

Mathias Schäfer (Autor)
am 04.12.2011 - 17:47

@datenkind, zu PHamlP: Ich habe es selbst nicht ausprobiert. Es scheint unter der angegebenen Adresse auch nicht mehr aktiv weiterentwickelt zu werden. Auf Github gibt es jedoch einige aktuelle Forks, die den Code weiter pflegen und Fehler korrigieren, z.B. johandouma/phamlp und codeincarnate/phamlp.

Permanenter Link

datenkind
am 05.12.2011 - 09:50

Danke, Mathias!

Permanenter Link

Robert
am 05.12.2011 - 10:42

Interessanter Artikel, Danke!

@Bertram Simon: Mich hat auch bisher bei der Nutzung von SASS abgeschreckt, dass es relativ aufwändig ist, lokal den Code zu schreiben, zu kompilieren und dann hochzuladen. Wenn man selbst oder jemand anderes "mal schnell" etwas online ändert, geht dann diese Änderung verloren, wenn man sie nicht lokal nachzieht. Aber zumindest für TYPO3 gibt es bspw. die Erweiterung "sassify", die es ermöglicht, direkt auf dem Server die SCSS-Datei abzulegen und sich nicht mehr um die Kompilierung kümmern zu müssen. Das macht es dann aus meiner Sicht sehr attraktiv, mit dieser Technologie zu arbeiten, dan man nichts von der bisherigen Flexibilität einbüßt.

Permanenter Link

Sascha Fuchs
am 07.12.2011 - 15:58

Zuerst schöner Artikel, mich freuts wenn immer mehr auf den Geschmack kommen :)

Aber man erkennt SASS Files auch an der Endung .sass - sind zwei leicht von einander abweichende Schreibweisen. SCSS wird sich wohl durch setzen, wer aber noch weniger tippen will weicht auf die SASS Syntax aus.

Wenn man SASS nutzen will, dann sollte man auch auf die echte Variante umschwenken, so Krückenlösungen wie pHAMLp sind immer bleiben immer zurück im Entwicklungsprozess, gerne wird auch gar nicht mehr weiter gepflegt. Die Entwicklung bei SASS wie auch Compass läuft ja stetig weiter.

Eine Ruby Umgebung aufzustellen ist nicht die Welt, http://railsinstaller.org/ da bekommt man sogar gleich Rails mit und die Geschichte ist mit einem Klick erledigt.

Alternativ bietet sich noch http://jruby.org/ an, da läuft Ruby über Java.

SASS mag am Anfang aufwendiger erscheinen, spielt aber mit fortschreitender Entwicklung immer mehr die Vorteile aus. Während der Default Dev kurz vor Ende der Deadline graue Haare bekommt weil der Kunde ein paar klitzekleine Änderungen noch eingepflegt bekommen will, grins ich mir eines Ändere zwei Variablen speicher und das war es. Sei es nun Farben oder das ganze Layout.

Klappt aber nur wenn man vorausschauend Entwickelt "was wäre wenn?" und sich die Optionen schon vorab implementiert.

Dazu der Compass Framework mit Sprite Engines, Dynamischen Pfaden, Base64 Codierung, CSS3 Prefixes etc. Der Rest sind eigene Mixins aus denen man sich am Ende ein Compass Gem schreibt und bei Bedarf dynamisch ins Projekt lädt.

Die Liste was geht, ist lang. Ich programmiere jetzt seit zwei Jahren damit und ich würde nicht mehr ohne wollen.

Permanenter Link

Die Kommentare sind geschlossen.