Nach dem ich mit Bootstrap von Twitter in Berührung kam, stieß ich auch auf Less. Bootstrap selbst bietet bereits einfache und flexible HTML, CSS und Javascript Kompontenten und setzt bei CSS auf Less, das CSS um Variablen, Operationen, Funktionen, Mixins und einiges mehr, erweitert.
Im Prinzip wird die erweiterte Syntax von einem Compiler in reguläres CSS überführt. Die Vorteile liegen scheinbar auf der Hand:
- Variablen können ausgelagert werden, somit können z. B. unterschiedliche Farbgebungen oder Layout-Breiten realisiert werden.
- Während der Programmierung können codesparende Techniken genutzt werden z. B. ermöglichen die sogenannten Mixins eine Wiederverwendung von bereits genutzten Anweisungen.
- Mehrere Less-Definitionen können durch die import-Anweisung in eine CSS-Datei kompiliert werden.
- Das CSS kann optional durch den Compiler minimiert werden,
- Es können Berechnungen durchgeführt werden, …
Im Gegenzug sehe ich jedoch auch ein paar Probleme. Zum einem muß ein zusätzliches CSS-Framework (?) in den Entwicklungsprozess eingebettet werden. Zum anderen gefällt mir eine entscheidende Funktionalität nicht besonders. Dazu gleich mehr. Jetzt erstmal alle Nachteile die ich sehe:
- Überschreiben von 3rdparty-Less-Definitionen (was für ein Wort…) ist umständlich bzw. erzeugt unnötigen Code.
- Erschwertes Debuggen, da die Zeilennummern des generierten CSS nicht mit denen der Less-Definition übereinstimmen.
- Aufwand für die Einarbeitung.
- Die Kompilier sind teilweise fehleranfällig (z. B. werden keine Schleifen bei den import-Anweisungen erkannt).
Nun zu dem erwähnten Beispiel. Wir haben z. B. fremden Code z. B. Twitter Bootstrap in unser Projekt eingebunden. Wir hüten uns natürlich davor diesen Code zu verändern, damit er leicht zu aktualisieren bleibt (z. B. könnte auch über svn:externals Code eingebunden werden). Nun möchten wir das Layout entsprechend den eigenen Designvorstellungen anpassen. Ich nehme exemplarisch folgende Konstellation an:
Die Datei new/default.less stellt die neu zu schreibende Less-Definition dar, die Datei 3rdparty/lib.css ist eine Definition einer Fremdbibliothek.
Der Inhalt der Dateien nehme ich wie folgt an:
Im Compiler (WinLess) wird nur die Datei new/default.less angegeben und kompiliert:
Nun die spannende Frage: Was wird wohl rauskommen? Unter der Annahme, dass der Kompilierer zuerst die 3rdparty-Datei abarbeitet und anschließend alle weiteren Dateien (override.less und enthaltene Anweisungen) könnte man meinen, er würde im schlechtesten Fall einfach alle Anweisungen nacheinander aufreihen. Im besten Fall würde eine einzige body-Anweisung erzeugt werden, die lautet
body {
background-color:#ff0000; // übersetzter Wert "red"
border:none;
font-family:verdana;
width:500px;
}Das Ergebnis sieht – wie vermutet – folgendermaßen aus:
/* Einbinden fremde Definition */
body {
background-color: #ff0000;
font-family: verdana;
border: 1px solid black;
}
/* Überschreiben */
body {
background-color: #ff0000;
border: none;
}
/* neue Anweisungen */
body {
width: 500px;
}Von schlankem CSS will ich hier nicht sprechen. Außerdem ist nicht mehr ersichtlich, dass der Hintergrund in der ursprünglichen Anweisung den Wert “#5B83AD” hatte.
Fazit
Auf den ersten Blick erscheint eine zusätzliche Abstraktionsschicht interessant, insbesondere die Verwendung der Variablen und der sogenannten Mixins. In der Praxis erhöht sich der Entwicklungsaufwand jedoch nicht unerheblich (Stichwort: Debugging und Integration) und das erzeugte CSS ist in den meisten Fällen nicht kleiner als eigener Code. Der eigentlich Kernnutzen für mich läge im einfachen und optimierten Überschreiben von bestehenden Less-Definitionen. Leider sind dafür die Kompilier noch nicht optimiert.
