Teil 5:
Mein CSS Workflow für Contao

Für den fünften Teil unserer Artikelserie CSS-Kurs für Contao will ich euch heute beschreiben, wie sich mein CSS Workflow in den letzten Jahren vom internen Contao-Editor bis hin zu SASS und gulp.js entwickelt hat.

Seit Beginn unserer Artikelserie und besonders nach dem vierten Teil wurde ich immer wieder gefragt, wie denn eigentlich mein CSS Workflow aussieht. Die Kurzform passt dabei locker in 140 Zeichen: „Ich nutze SASS, den CSS-Editor Coda und gulp.js“. Viel spannender finde ich aber eigentlich die Frage nach dem „Warum?!“.

Denn mein heutiger CSS Workflow für Contao ist das Ergebnis der letzten Jahre, in denen ich immer versucht habe, ihn weiter zu optimieren. Habt ihr den richtigen CSS Workflow für euch gefunden? Wann habt ihr das letzte darüber nachgedacht, etwas zu ändern? Vielleicht kann ich euch mit meinen Erfahrungen der letzten 6 Jahre ein paar neue Impulse geben.

Die letzten Jahre lassen sich grob in 4 Phasen unterteilen:

2008 bekam ich von meinem damaligen Bürokollegen Heiko die Empfehlung, mir mal TYPOlight (also noch weit vor der Umbenennung zu Contao) anzusehen. Es war mein erstes auf PHP basierendes und ernstzunehmendes CMS und eine ganz neue Welt für mich, nachdem ich vorher nur statische Websites gebaut hatte.

Der contaoeigene Editor

In den Monaten zuvor hatte ich mir zwar ein solides Wissen über CSS angeeignet, dennoch war ich sehr froh über den in Contao mitgelieferten CSS-Editor. Einer der größten Vorteile war, sich nicht alle Eigenschaften merken zu müssen. Und auch im Team ließ es sich noch ganz gut am CSS arbeiten. Ich musste mir zumindest keine Gedanken machen, dass wir uns im Team die CSS-Dateien gegenseitig überschrieben.

Der interne CSS-Editor von Contao hatte aber auch ein paar Nachteile:

• CSS-Anweisungen oder nur Teile davon ließen sich nicht oder nur relativ umständlich kopieren
• Die Geschwindigkeit des internen Editors war stark von der Server-Leistung abhängig. CSS-Anweisungen zu öffnen, zu bearbeiten und zu schließen konnte mitunter sehr lange dauern
• Nachdem ich sicherer beim Schreiben von CSS wurde, empfand ich es als umständlich, die entsprechende Stelle im contaoeigenen Editor zu suchen und auszufüllen

Ein paar der Probleme hätte ich relativ einfach in den Griff bekommen können, aber mit der Zeit fühlte es sich einfach nicht mehr richtig an, als „Programmierer“ sein CSS im internen Editor zu erstellen.

Rückkehr zum externen Editor

Bevor ich TYPOlight kennenlernte hatte ich bereits mit Dreamweaver (damals Teil meiner Creative Suite) mein CSS geschrieben. Als ich mich nun dazu entschied, wieder auf einen externen CSS-Editor zu setzen, war Dreamweaver meine erste Wahl. Später testete ich weitere Programme wie Espresso, CSSEdit und ein paar mehr bevor ich bei Coda landete.

Der Umstieg machte sich sofort bemerkbar. Ich hatte einen spürbaren Produktivitätsschub, den ich aber anfangs beim Debugging für den Internet Explorer wieder verlor. Denn auch da hatte mir TYPOlight vorher unmerklich ein paar Probleme abgenommen. Nach etwa einem halben Jahr habe ich auch am Ende eines Projektes wirklich noch Zeit gespart, dank des externen Editors.

Aber auch die Arbeit mit einem externen Editor hatte Nachteile:

• Wenn ich nicht gerade Copy & Paste verwenden konnte, musste ich ganz schön viel wiederholendes CSS schreiben
• Wenn ich im Team an Projekten arbeitete, was mittlerweile häufig der Fall war, mussten wir uns absprechen, damit wir uns nicht gegenseitig den letzten Stand überschrieben

Das Problem mit dem gegenseitigen Überschreiben haben wir dann über die Contao-Extension Stylesheets External gelöst, die es ermöglichte, mehrere Dateien zu einer zusammenzufügen. Sie hat außerdem dazu geführt, dass ich mir erstmals Gedanken über den modularen Aufbau und die Struktur der CSS-Datei(en) einer Website gemacht habe.

Lediglich die Tatsache, dass ich immer noch sehr viel CSS schreiben musste, bekam ich damit nicht in den Griff.

Eines Tages kam Phil mit LESS, einer „neuen Art CSS zu schreiben“, wie er es nannte, um die Ecke. Für mich war es das erste Mal, dass ich von Präprozessoren hörte. Schnell war klar, dass selbst wenn ich nur das Nesting nutzen würde, ich dennoch jede Menge Tipparbeit sparen würde. Auch die Tatsache, dass LESS die ganz normale CSS-Syntax verstand, kam mir sehr entgegen.

Contao LESS beibringen

Nur konnte Contao damals noch nichts mit LESS-Dateien anfangen. Deshalb entwickelte Phil für meine damalige Agentur SOLADES die Erweiterung [stylesheets_external_lessphp], mit der wir dann auch LESS-Dateien in Stylesheets External und damit in Contao hinterlegen konnten.

Der Einsatz von Variablen und Mixins bot uns ganz neue Möglichkeiten und wir begannen damit ein eigenes CSS-Framework für Contao zu entwickeln. Das war noch bevor Twitter sein Framework Twitter Bootstrap der Öffentlichkeit vorstellte. Aber als wir sahen, was Twitter da auf die Beine gestellt hatte, warfen wir unsere Ansätze recht schnell über Bord und versuchten stattdessen Contao und Twitter Bootstrap so gut es geht zu kombinieren. Es war die Geburtsstunde des Contao-Themes CTO-Bootstrap.

In CTO-Boostrap haben wir all unsere Best Practices zusammengefasst. Viele Ideen und Anpassungen sind in das Theme damals eingeflossen. Es war Grundlage für viele Contao-Projekte und sogar für ein paar Magento-Projekte bei SOLADES.

Gleichzeitig wurden meine Projekte immer komplexer. Mit ein paar Hundert Zeilen CSS war es plötzlich nicht mehr getan. Die LESS-Erweiterung von Phil hatte keine vernünftige Fehlerdarstellung, die ich aber gerade bei größeren Projekten brauchte – besonders wenn mehrere Personen daran arbeiteten. Außerdem wurde Stylesheets External nicht mehr weiterentwickelt.

Mit meinem Weggang von SOLADES letztes Jahr habe ich meinen CSS Workflow dann noch mal komplett überholt. Ich konnte einiges ausprobieren und musste ihn nicht mehr vor einem 4–6-köpfigen Team rechtfertigen oder erklären.

Ich entschied mich für gulp.js, was zu diesem Zeitpunkt gerade die nächste Sau war, die durch das Webentwickler-Dorf getrieben wurde und als Nachfolger von Grunt.js gehandelt wurde. Das hatte den Vorteil, dass es jede Menge aktuelle Tutorials gab, in denen dann auch meistens SASS verwendet wurde. Da es zu SASS generell mehr Infos gab als zu LESS, gab ich auch SASS eine Chance. Letztendlich machte auch der SASS-Port von Bootstrap mir den Wechsel von LESS zu SASS noch ein wenig leichter.

Nur beim Editor bin ich bei Coda von Panic geblieben und nach wie vor zufrieden, auch wenn viele auf PhpStorm schwören. Mittlerweile habe ich mich auch von dem Bootstrap-Framework immer mehr entfernt. Geblieben sind ein paar Mixins, das Grid von Bootstrap sowie ein paar der Variablen(bezeichnungen).

Auch heute arbeite ich noch mit SASS und gulp.js. Ich bin froh, dass ich den Schritt gewagt und mich mit der Konsole angefreundet habe. Würdet ihr mich allerdings fragen, ob ich euch meinen CSS Workflow empfehlen kann, würde ich wohl sagen „das kommt ganz drauf an“.

Präprozessoren haben meine Arbeit um ein vielfaches beschleunigt. Ich nutze vor allem Variablen, einfach Mixins und das Nesting. Die vereinfachte Schreibweise und Nutzung hat man schnell verinnerlicht, nur muss man gerade zu Anfang darauf achten, was für CSS man am Ende rausbekommt. Da spielt es auch keine Rolle, ob man Programme wie Codekit benutzt oder auf Task-Runner wie gulp für die Kompilierung setzt.

Was gulp betrifft, bin ich ein wenig hin- und hergerissen. Einerseits gibt es eine Vielzahl von Plugins für gulp (die meisten Grunt-Plugins kommen früher oder später auch für gulp raus), mit denen ihr eure CSS-Dateien (aber auch JS und Bilder) überwachen und optimieren könnt. Gerade, wenn ihr euch mit dem Thema Website-Performance auseinandersetzt, findet ihr dort eine Menge nützlicher Plugins.

Andererseits kann es gerade bei gulp (bei Grunt kann ich es nicht beurteilen) passieren, dass eine neue Erweiterung oder ein Update quer schießt und plötzlich nichts mehr geht. Dann verbringt man Stunden damit den Fehler zu finden, anstatt sich um seine eigentliche Aufgabe, die Umsetzung eines Webprojekts, zu kümmern.

Rückbesinnung auf CSS?

Interessant finde ich, dass einige Webentwickler gerade wieder dabei sind, sich von Präprozessoren zu verabschieden und zurück zu einfachem CSS zurückkehren. Autoprefixer, statt dem ein oder anderen Mixin? Okay. Sogenannte Postprozessoren sind ja gerade stark im Kommen. Aber gleich auf alle Vorteile von SASS und Co zu verzichten? Das kann ich ehrlich gesagt nicht nachvollziehen.

Mit Sicherheit wird die CSS-Qualität noch ein bisschen besser sein, wenn man jede Zeile selbst schreibt und sich nicht ein paar Mixins bedient, die man mal für ein Projekt X geschrieben hat. Aber rechnet sich der zusätzliche Aufwand? Selbst die beste Autovervollständigung im CSS-Editor sorgt immer noch dafür, dass die Anweisungen deutlich länger und dadurch unübersichtlicher werden. Das tue ich mir freiwillig nicht mehr an und fluche jedes Mal ein bisschen, wenn ich mal wieder ein altes Projekt ohne Präprozessor anfassen muss.

Ich würde meinen Worflow keineswegs als perfekt bezeichnen. Aber nach Stunden der Einrichtung und dem Zusammenstellen der richtigen Tools und Plugins bin ich im Großen und Ganzen zufrieden. Gleichzeitig bin ich weiterhin gespannt, wie sich unser Workflow in Zukunft verändern wird. Vielleicht ist in einem Jahr schon nichts mehr von meinem jetzigen Workflow übrig geblieben. Ein Update dieses Artikels ist also nicht ausgeschlossen.