Weniger ist mehr: So optimierst du mit LESS deinen CSS-Workflow
![Weniger ist mehr: So optimierst du mit LESS deinen CSS-Workflow Weniger ist mehr: So optimierst du mit LESS deinen CSS-Workflow](https://images.t3n.de/news/wp-content/uploads/2013/08/less_css_teaser.jpg?class=hero)
Man kennt das – als ambitionierter Internet-User stößt man fast täglich auf Begriffe, die man schon tausendmal gelesen, bei denen man aber noch nie wirklich verstanden hat, was genau sich dahinter verbirgt. Oder man hat nur eine ungefähre Ahnung, worum es geht und möchte durch das eigene Halbwissen nicht unangenehm auffallen. Wir bringen Licht ins Dunkel und erklären die Begriffe und Plattformen auf leicht verständliche Weise. In der Vergangenheit haben wir uns schon Markdown, reddit, Tumblr, GitHub und Medium.com gewidmet. Heute erklären wir euch, was es mit LESS auf sich hat.
Mit CSS kannst du fantastische Webseiten kreieren und dank Responsive Design für jedes denkbare Endgerät perfekt angepasst ausliefern. So vielseitig die Möglichkeiten bei der Erstellung von Webseiten sind, so komplex und unübersichtlich werden Stylesheets mit der kontinuierlichen Entwicklung von Web-Projekten. Ein guter Editor und ein schlüssiger Aufbau sind schon die halbe Miete, um den Überblick im Stylesheet-Chaos zu behalten. Irgendwann stößt man auch hier an gewisse Grenzen, die teilweise der Syntax von CSS zugrunde liegen.
Hast du dir nicht auch schon immer gewünscht, in CSS mit Variablen arbeiten zu können, oder Stylings von Child-Elementen nicht mit umständlichen „Pfadangaben“ machen zu müssen? Mit LESS eröffnen sich dir zahlreiche Möglichkeiten, wie du deine Arbeit mit Stylesheets vereinfachen und optimieren kannst.
Was ist LESS?
![LESS im Einsatz](https://images.t3n.de/news/wp-content/uploads/2013/08/less_im_einsatz1.jpg?class=content)
LESS im Einsatz.
LESS bezeichnet sich selbst als „Die dynamische Stylesheet-Sprache“. Aber keine Angst, hier geht es nicht darum, eine komplett neue und komplizierte Syntax zu lernen. LESS erweitert die Fähigkeiten von CSS mit dynamischen Funktionen wie Variablen, Mixins, Operationen und Funktionen. Mit Hilfe von JavaScript kann LESS Clientseitig (nur bei modernen Browsern) und mit Node.js oder Rhino serverseitig betrieben werden. Außerdem kann LESS nach Abschluss der Entwicklungsarbeit für eine bessere Kompatibilität zu einem CSS-Stylesheet kompiliert werden.
Was kann LESS?
LESS vereinfacht die Erstellung von CSS-Stylesheets und sorgt dafür, dass du weniger (less) schreiben musst und den Überblick in deinem Projekt behältst. Dafür bietet LESS die folgenden Features.
Variablen
Mit Variablen kannst du wichtige Werte für das gesamte Stylesheet definieren und abrufen. So sind Änderungen von Farbwerten ohne lästiges Suchen der jeweiligen Stellen im Code oder Felder durch die unzuverlässigen „Suchen-und-Ersetzen“-Routinen des Editors möglich. Auch die Entwicklung von komplexen Grid-Systemen geht deutlich einfacher von der Hand, wenn die Werte übersichtlich außerhalb der eigentlichen Klasse zusammengefasst werden können.
// LESS
@color: #4D926F
#header {
color: @color;
}
h2 {
color: @color;
}
/* Kompiliertes CSS */
#header {
color:#4D926F;
}
h2 {
color: #4D926F
}
Mixins
Wenn die normale Vererbung von Klasseneigenschaften nicht mehr reicht, kommen Mixins ins Spiel. Mixins erlauben es dir, Eigenschaften einer Klasse an eine andere Klasse zu vererben, sodass lästige Mehrfachdefinitionen während der Entwicklung der Vergangenheit angehören. Besonders nützlich bei Elementen, die zahlreiche Eigenschaften mit Vendor-Prefixen enthalten. Du hast sogar die Möglichkeit, Variablen der Klassen parametrisiert zu setzen um bei Bedarf andere Ergebnisse zu erzielen.
// LESS
.rounded-corners (@radius: 5px){
-webkit-border-radius: @radius;
–moz-mobrder-radius: @radius;
-ms-border-radius: @radius;
-o-border-radius: @radius;
border-radius: @radius;
}
#header {
.rounded-corners;
}
#footer {
.rounded-corners(10px);
}
/* Kompiliertes CSS */
#header {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
(…)
}
#footer {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
(...)
}
Nested Rules
Je genauer der Selektor im Stylesheet definiert ist, desto unwahrscheinlicher wird es, dass er von anderen Stylesheets – beispielsweise von Drittanbietersoftware – überschrieben und zerstört wird. Bei komplexeren Pfaden kann das aber zu sehr schlecht les- und wartbarem Code führen. Mit LESS kannst du Selektoren ineinander verschachteln und so die Übersicht deines Stylesheets wahren.
// LESS
#header {
h1 {
font-size: 26px;
font-weight:bold;
}
p {
font-size:12px;
a { text-decoration:none;
&:hover {border-width:1px;}
}
}
}
/* Kompiliertes CSS */
#header h1 {
font-size: 26px;
font-weight: bold;
}
#header p {
font-size: 12px;
}
header p a {
text-decoration: none;
}
#header p a:hover {
border-width: 1px;
}
Funktionen und Operationen
Sind einige Elemente in deinem Stylesheet proportional zu den anderen? Mit Operationen kannst du Werte addieren, subtrahieren, multiplizieren und dividieren. Das funktioniert nicht nur mit Pixel-, Prozent- oder VW- und VW-Werten, sondern geht auch mit Farben, sodass du eine komplexe Beziehung zwischen den Werten verschiedener Elemente aufbauen kannst.
// LESS
@the-border: 1px;
@base-color: #111;
@red: #842210;
#header {
color: (@base-color * 3);
border-left: @the-border;
border-right: (@the-border * 2);
}
#footer {
color: (@base-color + #003300);
border-color: desaturate(@red, 10%);
}
/* Kompiliertes CSS */
#header {
color: #333;
border-left: 1px;
border-right: 2px;
}
#footer {
color: #114411;
border-color: #7d2717;
}
Wie benutze ich LESS?
An dieser Stelle behandeln wir LESS ohne serverseitige Einbindung von Node.js im Einsatz in Entwicklungsumgebungen. Dafür liefert das Team von LESS eine JavaScript-Bibliothek, die im Dokument eingebundene Stylesheets parst und als Inline-CSS-Tag in das DOM einfügt. Dafür müssen nur die JavaScript-Datei in das Dokument und die Stylesheets mit entsprechendem Rel-Attribut in das HTML-Dokument eingebunden werden.
<link rel="stylesheet/less" type="text/css" href="styles.less" />
<script src="less.js" type="text/javascript"></script>
Wichtig hierbei ist, dass das Stylesheet vor dem Skript eingefügt wird, da es sonst zu Verarbeitungsproblemen kommen kann. Auch ist diese Herangehensweise nichts für den Produktivbetrieb, da so bei deaktiviertem JavaScript und einigen älteren Browsern kein CSS generiert und angewandt werden kann. Außerdem leidet die Performance darunter, wenn das LESS-Stylesheet vom Browser verarbeitet werden muss, bevor das eigentlich darzustellende CSS daraus entsteht.
Für den Produktivbetrieb kannst du neben dem serverseitigem Betrieb von LESS mit Node.js die .less-Dateien mit einem Automationsprogramm wie beispielsweise Grunt kompilieren. Durch diese Herangehensweise behältst du den Überblick in deinem Stylesheet und lieferst voll funktionsfähiges CSS an deine Clients aus.
Brauche ich LESS?
Die Frage, ob man LESS braucht, kann jeder für sich selbst am besten beantworten. LESS kann nichts, was man mit normalem CSS nicht auch erreichen könnte. Das Potential für Zeitersparnis kann man LESS aber nicht aberkennen. Die dynamischen Funktionen von LESS ermöglichen eine deutlich kompaktere und besser lesbare Schreibweise, die insbesondere bei großen Projekten ihre Vorzüge zur Geltung bringen kann. Durch den Einsatz von Variablen und Funktionen können Verhältnisse zwischen Elementen hergestellt werden ohne komplizierte Berechnungen immer wieder selbst wiederholen und umständlich im Stylesheet einpflegen zu müssen.
Wenn du der Meinung bist, dass LESS genau das Richtige für dich ist, findest du auf der offiziellen Webseite von LESS alles, was du für den Start mit dem Programm benötigst.
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
Ich finde LESS und SASS viel zu umständlich. Die Ideen der Syntax ist schon gut, aber wie dort Mixins gelöst worden, einfach nur schrecklich. Ich finde Stylus 1000mal sympatischer.
Dann muss man wieder was lernen, was irgendwann nicht weiterentwickelt wird. Extra Javascript und und und. Sehe da keine Vorteile!
@El Gringo: Für Javascript ist es nie zu spät!
Ich persönlich finde Less interessant, weiß aber auch noch nicht so genau, ob ich mich vom „normalen“ CSS verabschieden soll…
Aber danke für den Artikel. :)
Also ich habe SASS zuletzt in einem Großprojekt genutzt und bin durchaus sehr begeistert davon. Gerade die Mixins und das Nesting erleichtern die Arbeit enorm und sind auch definitiv ein Zeitvorteil.
@Gringo Mit lernen ist da nicht viel. Im Prinzip verschachtelst du die CSS Regeln einfach nur ein wenig und kannst zusätzlich Funktionen und Variablen nutzen. Wenn du CSS kannst ist das eine Einarbeitungszeit von maximal 2 Stunden.
Und für SASS gibts zusätzlich ein nettes Tool welches die Dateien direkt kompiliert und auch minified, sofern man das möchte. http://mhs.github.io/scout-app/
Ich habe mit LESS angefangen und nach langen Überlegungen zu SASS gewechselt. Es gibt für SASS u. a. interessante Frameworks und Tools, wie z. B. Compass (http://compass-style.org/) und Susy (http://susy.oddbird.net/). Außerdem nutze ich gerne CodeKit, das kann sowohl SASS- als auch LESS-Dateien kompilieren.
Also ich kann mir Projekte ohne LESS oder SASS (wobei LESS IMO die „einfachere“ Variante ist) nicht mehr vorstellen. Dabei geht es weniger um die reine Zeiterstparnis als viel mehr um die Möglichkeit der klaren und vor allem flexiblen Strukturierung. Allein die Nutzung von Mixins in Kombination mit Parametern sind Gold wert.
Und mit JS hat das ganze ursächlich nichts zu tun. JS wird nur manchmal als „Laufzeit-Interpreter“ genutzt, wobei ich davon schon alleine aus Performancegründen abrate. JS Interpreter sind für die Entwicklung oder das Ausprobieren von LESS ausreichend.
Für Produktivsysteme setze ich auf „klassische“ Compiler, die aus den .less Files das fertige CSS generieren (zB. WinLess).
man muss es mit sass/less ja nicht übertreiben und alles bis ins letzte ausreizen.
mixins machen sich für mediaqueries sehr gut und auch die rumfrickelei mit schatten, runden ecken und den anderen css3 sachen, gehen damit sehr gut.
zudem kann man eben ohne extra php-script alles komprimieren oder ausgelagerte dateien zusammenfassen.
… ein Kommentar zu dem Beispiel für den border-radius: Da sind per se die meisten Präfixe unnötig, denn es gab nie einen Browser, der -ms-border-radius oder -o-border-radius benötigt hätte, da der IE9 direkt border-radius ohne Präfix implementiert hat und Opera 10.5 dito auch direkt border-radius und nie -o-border-radius.
-moz-border-radius wäre für den Firefox vor Version 4 notwendig, den man heute ignorieren kann, -webkit-border-radius würde Safari 4 brauchen, der eigentlich heute auch keine große Rolle spielt.
LESS verlockt einen manchmal dazu, unnötigen Code zu produzieren – wie beispielsweise die ganzen Präfixe bei border-radius, weil es ja so einfach geht. Dass man mit LESS redundaten Code produzieren kann, spricht aber nicht an sich gegen den Einsatz von LESS.
Ich finde die folgende Fausregel gut: LESS ist dann gut eingesetzt, wenn man dem Ergebnisstylesheet nicht sofort ansieht, dass es mit LESS erzeugt wurde.
Mich hat es bisher noch nicht überzeugt aus drei Gründen:
1) Es führt eine Zwischentechnik mehr ein, die eine potentiell zusätzliche Fehlerquelle sein kann. Außerdem entfernt man sich etwas von der eigentlich vorgesehenen Technik.
2) Das normale Kundenprojekt verläuft so „agil“. das der Vorteil von Variablen etc meist wieder hinfällig ist.
3) Wenn ich sowas wie Sass/Compass einsetze, habe ich spezielle Dateien, die dann zu CSS compiliert werden. Damit fehlt mir dann bei der Analyse im Browser die Zuordnung zum Definitionsort, was dann die marginalen Zeitersparnisse wieder mehr als wegmacht.
Wie löst ihr das Dilemma bei 3)?
Mit Punkt 3 hatte ich ehrlich gesagt noch nie ein Problem. Mit entsprechend konsistener Benennung der Klassen, IDs etc., der übersichtlichen Verschachtlung von LESS und dem Aufsplitten der LESS-Dateien kann ich pers. mich deutlich schneller und besser orientieren, als wenn ich mit Browsertools den Zuordnungsort eines „normalen“ Stylesheets auslese.
Zu 2.: Variablen sind jetzt vielleicht nicht DAS Highlight. Wobei ich das bei Entwicklung von Grits, besonders wenn sie responsive sind, sehr zu schätzen gelernt habe.
Zu 1: Da würde ich wiedersprechen. LESS gibt eine Fehlermeldung beim Kompilieren aus, wenn du etwas falsch macht – ein normales Stylesheet wird weiter interpretiert. Und durch die Verschachtelung hat man einfach die bessere Übersicht als wenn man ellenlange Definitionen untersuchen muss.
Aber es ist und bleibt natürlich zum Teil auch Geschmackssache, ob man nicht lieber doch alles komplett selbst macht und auch so besser hinkriegt. Für mich hat sich das auf jeden Fall gelohnt und ich würde nie wieder darauf verzichten wollen.
Ich nutze LESS seit etwa 2 Monaten und bin voll auf zufrieden damit!
Für alle, die sich über meine Erfahrung und Tipps zu LESS interessieren, hab ich hier (www.tobias.feldmeth.de/Information/less/) auch einen kleinen Beitrag dazu geschrieben. Freue mich über jede Konversation auf meinem Blog ;) … auch gerne zu anderen Themen.
Mit Twitter’s Bootstrap habe ich auch mit LESS angefangen, ich kompiliere immer Software gestüzt mit http://incident57.com/less/ , alternative dazu ist auch CodeKit mit zusätzlichen Funktionen. Für Windows gibt es das Pendant namens WinLESS.
@Martin zu Punkt 3. Ilja Zaglov hat es schon richtig erwähnt und ich kann dazu auch nur sagen, sich eine konsistente Struktur zu überlegen. Am Anfang habe ich mich in den vielen LESS Dateien auch nicht zurecht gefunden, mittlerweile habe ich mit meinem Team in allen Projekten die gleiche Struktur und das klappt super.
Einziger Wermutstropfen, ich habe es noch nicht geschafft, die Kompilierung von LESS Dateien an die Kompilierung von Visual Studio zu verknüpfen. Gibt es da ein gutes Tutorial im Netz zu?
OK, danke für die Rückmeldungen.
Eine ordentliche Struktur haben wir natürlich auch so, dass ist unabhängig von anderen Techniken viel Wert. Und ja überzeugt, mit so einer guten Struktur braucht man nicht unbedingt den Zusammenhang zwischen Angabe z.B. im Firebug und Definitionsort. Wenn man sich in der Struktur auskennt.
Problematisch wird es sicherlich trotzdem, wenn man wie ich oft mit übernommenen Fremdsystemen zu tun hat oder neue Leute dazukommen.
Aber danke trotzdem für den Artikel, dass ich mal wieder Anregung hatte über das Thema nachzudenken. Aktuell bin ich noch auf der Stufe „ist wohl Geschmackssache“ in der Einschätzung, aber wenn hier einige meinen, dass ihre Erfahrung Positives zeigt, wird das ja sicher nicht von Ungefähr kommen.
Wie hier bereits erwähnt wurde gibt es z.B. Compiler wie Codekit, die sowohl LESS als auch SASS in reines CSS umwandeln können und es somit auch ohne JS oder Node.js einsetzbar machen.
Warum wird so etwas in einem Artikel zu dem Thema verschwiegen? Denn gerade DAS macht es so effektiv: Keine 4000 Zeilen CSS-Datei, sondern nach Bereichen aufgeteilte, überschaubare Teile, die dann sauber in eine Datei (ggf. 2 bei responsive) zusammengeführt werden, ohne irgendwas im Code anpassen zu müssen.
Und wer schon mal in den ‚Genuss‘ gekommen ist, bei einem Projekt mit dem Color-Picker 15 verschiedene Grüns aus einer JPG-Datei holen zu müssen, wir sich über die Variablen SEHR freuen.