SASS und LESS sind Erweiterungen der klassischen CSS-Syntax, die CSS-Vielschreibern lästige Tipparbeit ersparen sollen. Mit SASS und LESS wird CSS smarter und leistungsfähiger.

Ich möchte in diesem Artikel herausfinden, welche Konsequenzen das Arbeiten mit CSS-Dateien, die einen Compiler brauchen, auf meinen Arbeitsablauf bei der Entwicklung von WordPress-Themes haben würde.
Eine Warnung vorweg: In diesem Artikel werde ich LESS und SASS fröhlich in einen Topf werfen. Das Prinzip dahinter ist dasselbe, aber mir ist klar, dass sich beide Ansätze voneinander unterscheiden. Eine Gegenüberstellung beider Methoden gibt es bei smashingmagazine.

Eine kurze Einführung in LESS

Die Syntax von LESS (und SASS) unterscheidet sich von der im klassischen CSS. Das muss auch so sein, schließlich bieten die Frameworks Funktionen, die es in CSS nicht gibt und die müssen irgendwie dargestellt werden.

Ein Beispiel: Ich möchte ein bestimmtes Rot definieren, die Hausfarbe der Firma, der die Website gehört. Der Hexcode der Farbe ist: #990000.

Dieses Rot soll auf der Website in verschiedenen Elementen vorkommen. Es gibt rote Überschriften, rote Linien und rote Flächen. Im klassischen CSS bleibt mir nichts anderes übrig, als überall dort, wo das Rot auftauchen soll, den Hexcode der Farbe einzutippen.
Ein Schriftelement bekommt eine color: #990000, eine Fläche eine background-color: #990000 und ein Rahmen die border-color:#990000 und so weiter.

Mit Variablen arbeiten

Mit LESS wird das einfacher.
Die Farbe wird nur einmal definiert und in eine Variable (im  Beispiel unten ist es die Variable @hausfarbe) gepackt. Danach kann ich das Rot an allen möglichen Stellen einsetzen, es genügt, wenn ich mir den Namen der Variable gemerkt habe.

Der Haken dabei: Damit am Ende eine CSS-Datei herauskommt, die alle Browser lesen können, muss die Syntax von SASS und LESS durch einen Compiler laufen. Die Kurz-Schreibweisen werden dann aufgelöst in den üblichen CSS-Code.

/* LESS */
@hausfarbe: #990000;
#header {background-color: @hausfarbe;}
h2 {color: @hausfarbe;}

 

/* Kompiliertes CSS */
#header {background-color:#990000}
h2 {color: #990000;}

Mit den Variablen kann man eine Menge Dinge machen, man kann zum Beispiel mit ihnen rechnen:

/* LESS */
@the-border: 1px;
#header { border-top: @the-border * 2; }

 

/*Kompiliertes CSS*/
#header { border-top: 2px; }

CSS-Klassen verschachteln

Über so genannte Mixins kann ich classes und ids verschachteln. Auch hier geht es darum, etwas, das schon einmal definiert wurde, wiederverwendbar zu machen.
Ich lege beispielsweise eine Klasse für Unterstreichungen fest:

.unterstrichen { border-bottom: 1px solid #ccc; }

Diese Klasse kann ich in jedem beliebigen Element wieder verwenden. Wenn beispielsweise alle Links im Artikeltext grau unterstrichen sein sollen, schreibe ich es so:

.post a { color: #666; .unterstrichen; }

Wer hat’s erfunden?

Auf den Weg gebracht wurde LESS von Alexis Sellier. Meine Beispiele stammen teilweise von seiner Seite lesscss.org. SASS wurde von Hampton Catlin und Nathan Weizenbaum entwickelt.

LESS kann natürlich noch eine Menge mehr, ich möchte es aber bei einem kurzen Einblick bewenden lassen.

Mein WordPress-Workflow in einem Wort: FTP

Ein neues WordPress-Theme entwickle ich zunächst auf MAMP, das meinen Mac zum virtuellen Server macht. Das Programm ist kostenlos, schnell installiert und funktioniert einwandfrei.
Ich wechsle allerdings relativ früh auf eine Testdomain bei dem Provider, bei dem die Seite am Ende laufen soll. MAMP und ein externer Server verhalten sich nicht in allen Details gleich, manche PlugIns mögen die lokale Umgebung nicht und es gibt immer mal wieder kleinere Abweichungen in der Interpretation des Codes – je nach Server-Konfiguration.

Wenn ich an einer WordPress-Seite arbeite, dann passiert das also im wesentlichen über FTP. Ich nutze dafür das FTP-Programm Transmit von Panic.
Von den Daten auf dem Server erstelle ich regelmäßig Backups auf meinem lokalen Rechner und in der Cloud.

Die Vorteile des FTP-Workflows

  • Ich bin nicht an einen lokalen Rechner gebunden und kann von jedem Gerät aus auf die Daten zugreifen
  • Die Daten liegen auf einem Testserver, der nicht öffentlich sichtbar ist, aber die technische Umgebung ist identisch mit derjenigen des Live-Servers
  • Es gibt immer eine eindeutige „letzte Version“ – nämlich die auf dem Server
  • Ich kann die CSS-Datei mit meinem Lieblingseditor Espresso oder mit den Dev-Tools von Chrome (alternativ: Firebug) bearbeiten

Die Sache mit dem Compiler

In dem Moment, indem ich mein Stylesheet in einer Datei mit der Endung .less, .sass oder .scss entwickle, funktioniert der Weg über FTP nicht mehr so ohne Weiteres. Zwar gibt es nach wie vor eine Datei namens style.css in meinem wp-content-Verzeichnis. Aber die darf ich nicht mehr wie gewohnt bearbeiten.
Meine Arbeitsdatei ist ja die nicht-kompilierte Version, also zum Beispiel eine Datei namens style.less.
An dieser Datei mache ich alle Änderungen und Anpassungen. Bin ich damit fertig, tut der Compiler seine Arbeit und wandelt die Datei um in style.css.

Eine Entwicklungs-Umgebung für LESS und SASS

Es wäre natürlich unpraktisch, wenn man jedes Mal, wenn man aus einem LESS- oder SASS-File eine CSS-Datei erzeugen wollte, per Hand den Compiler aktivieren müsste. Früher oder später würde man diesen Arbeitsschritt vergessen – mit der Folge, dass das Stylesheet nicht auf dem aktuellen Stand wäre.

Dateien automatisch kompilieren

Praktischer ist es, wenn das automatisch passiert. Die Tools, die diese Aufgabe übernehmen, arbeiten alle nach dem gleichen Prinzip: Der Compiler überwacht einen bestimmten Ordner, der die Stylesheet-Dateien enthält. Jedes Mal, wenn sich an der LESS-Datei etwas ändert, wird der Compiler aktiv und erzeugt eine .css-Datei. Damit ist das CSS-File immer auf dem neuesten Stand.

Diese Überwachungmethode funktioniert am besten in einer lokalen Entwicklungsumgebung. Programme wie simpless, codekit oder crunchapp sind da sehr hilfreiche Tools. Sie kümmern sich um das Kompilieren der less-Dateien und helfen außerdem, den Workflow in der lokalen Entwicklungsumgebung besser zu organisieren. Ein interessantes Tool ist auch LiveReload, das es als kostenpflichtige App (9,99$ im AppStore) und als kostenlose Browserextension gibt. Die Extension wollte bei mir nicht funktionieren, aber die App macht ihren Job sehr gut.

Dateien auf dem Server kompilieren

Schwieriger wird es, wenn die Daten auf einem externen Server liegen. Aber auch dafür gibt es Lösungen.

Mit lessphp kann man die Kompilation auf dem Server durchführen lassen. Allerdings muss man dazu die Datei, in der das Stylesheet eingebunden ist, mit ein paar Zeilen php anreichern.

Eine sehr elegante Möglichkeit bietet Transmit: Ich kann ein externes Verzeichnis wie ein internes Laufwerk auf den Desktop meines lokalen Rechners laden. Dann kann ich Ordne auf einem externen Server über einen lokalen Kompilierer, der auf meiner lokalen Festplatte liegt, überwachen lassen.

Github und Co.

Ein anderer Weg, den viele Entwickler nutzen, ist der Weg über ein Versionskontrollsystem. Das bekannteste ist Github, aber auch Beanstalk zielt in dieselbe Ecke. Sowohl Github als auch Beanstalk bieten Serverplatz (Repositories) an, auf dem Entwickler ihren Code speichern und gemeinsam im Team bearbeiten können. Aber man kann den Code hier nicht nur lagern, man kann – neben vielen anderen Funktionen – den Code auch an andere Server weiterschicken, das heißt, die Dateien, die verändert wurden, mit denen auf einem anderen Server synchronisieren.
Wie das mit beanstalk geht, zeigt Chris Coyierin einem Video-Screencast Getting off FTP and onto Git Deployment with Beanstalk.

Einen anderen Weg der Kombination von lokaler Entwicklung + GitHub beschreibt Mark Jaquith: WordPress local dev tips: DB & plugins. Für meinen Geschmack ein bisschen zu abenteuerlich.

Im Spiel mit LESS und SASS spielt der Github- oder Beanstalk-Server eine Art Mittlerrolle. Entwickelt wird auf dem lokalen Rechner, der an ein Repository angebunden ist. Auf dem Repository wird der Code dann kompiliert – so habe ich es zumindest verstanden. Ist das geschehen, wird das CSS-File an den eigentlichen Server weitergeschickt. Alternativ kann man gleich die gesamte (Test-)Website bei Github hosten.

Das Ganze ist ziemlich komplex. Kommt dazu, dass nicht jeder Server mit Git reden mag. Man muss eine solche Umgebung gründlich testen.

Lohnt sich die Mühe?

Es ist also mit Aufwand verbunden, wenn man mit kompilierten CSS-Dateien arbeiten möchte. Man muss den Arbeitsablauf entsprechend umstrukturieren. Diese Umstellung kostet Zeit und Energie. Das heißt, zunächst dürfte die Produktivität eher sinken als steigen.

Es lohnt sich also, darüber nachzudenken, welche konkreten Vorteile der Umstieg auf eine LESS/SASS Entwicklungsumgebung im Zusammenhang mit WordPress haben würde.

Vorteile einer Entwicklung mit LESS oder SASS

  • Die Syntax einer .less oder .sass-Datei ist übersichtlicher als die in einem üblichen CSS-File
  • Dadurch ist die Datei leichter zu pflegen (weniger Zeilen Code)
  • Das Schreiben von CSS geht schneller von der Hand, man spart also Zeit

Nachteile einer Entwicklung mit LESS oder SASS

  • Alle, die an der Entwicklung und Pflege der Website beteiligt sind, müssen auf den Workflow  mit LESS/SASS eingeschworen werden.
  • Sobald jemand Änderungen direkt an der CSS-Datei vornimmt – weil es mal wieder eilig war – ist der Wurm drin
  • Wer mit LESS/SASS-arbeitet, braucht sehr gute Kenntnisse in CSS. Ist das nicht der Fall, dann kann der kompilierte CSS-Code zum Alptraum werden
  • Die Dev-Tools von Chrome arbeiten nicht mit LESS und SASS zusammen:
    Dateien mit anderen Endungen als .css werden nicht angezeigt.

Mein Fazit

Für CSS-Profis sind die kompilierbaren Erweiterungen ein faszinierendes Werkzeug, denn sie bieten Vieles, das das klassische CSS nicht bietet. Es ist schon ziemlich öde, wieder und wieder dieselben, langen Codezeilen einzutippen.

Idealerweise sieht man es dem kompilierten CSS-File nicht an, dass es über den Compiler-(Um)weg entstanden ist. Dazu muss aber der Mensch, der LESS und SASS schreibt, genau wissen, was er tut. Das heisst, er braucht eine sehr genaue Vorstellung davon, wie das kompilierte CSS-File aussehen wird.
Wer das nicht leisten kann oder Opfer seines Spieltriebs wird – man kann zum Beispiel so ziemlich alles verschachteln –, erzeugt unsinnigen Wurstelcode.

Der entscheidende Faktor: Die Komplexität

Wenn ich es auf einen Nenner bringen müsste, würde ich es so formulieren: Die Vorteile von LESS & Co. kommen erst dann zum Tragen, wenn man mit komplexen Stylesheets arbeitet. Bei sehr großen Seiten mit vielen Stylesheets oder Multisite-Projekten bringt die vereinfachte und mächtigere CSS-Syntax sicherlich einen Produktivitäts-Vorteil.

Auch an anderer Stelle schließt sich hier der Kreis: Große Projekte können nicht über einen FTP-Workflow organisiert werden. Sobald nicht einer allein, sondern ein Team an einem Projekt arbeitet, geht nichts ohne Versionskontrolle. Damit wäre der Workflow grundsätzlich bereit für die Arbeit mit LESS und SASS. Man müsste gar nicht groß umstrukturieren.

Die Entwicklung von WordPress-Themes ist aber in viel Fällen eine One-Man/Woman-Show. Das Stylesheet eines WordPress-Themes ist außerdem vergleichsweise übersichtlich. Der FTP-Workflow ist in diesem Kontext ein effizienter Weg mit einem sehr guten Aufwand/Nutzen-Verhältnis.

Und? Wie geht es weiter?

Noch scheue ich mich, meine Arbeitsabläufe umzustellen. Ich arbeite ungeheuer gern mit den Chrome-Dev-Tools und mit Transmit fühlt sich der FTP-Server so leichtgängig an wie MAMP.

Das einzige Manko, das ich an diesem Setting ausmachen kann, ist die fehlende Versionskontrolle. So gesehen werde ich mich im nächsten Schritt in dieses Thema einarbeiten. Ich fange mal mit Github for Mac an.
Meine CSS-Files werden bis auf Weiteres die Endung .css tragen. Aber wer weiß, wie lange noch.