John W. Long beschreibt im Blog „The Sass Way“ seinen modularen Ansatz mit Sass. In meinen aktuellen Schulungen gehe ich auch immer darauf ein, dass man eine Webseite als Ansammlung von Modulen betrachten sollten. Präprozessoren wie Sass helfen uns dann dabei, die für die Module passenden Regeln auch wieder in einzelne Dateien zu splitten.
Ohne Präprozessoren muss man entweder mit Projekten wie dem CSS-JS-Booster alle CSS-Dateien zusammenfassen oder in einem einzigen, immer größer und unübersichtlicher werdenden Stylesheet arbeiten. Da ich Letzteres über die letzten Jahre gemacht habe, weiss ich es mittlerweile zu schätzen, mit Sass-Partials meine Arbeit wieder übersichtlicher und strukkturierter zu gestalten.
Meine Vorgehensweise ist gar nicht so weit von der in dem Text beschriebenen entfernt. Nur die Benamung realisiert er konsequenter. Mal schauen, ob ich das demnächst in meinen Workflow integriere. Für den Workflow im Team sind kleine Modul-CSS-Dateien auch hilfreich. Dadurch können sich die Teammitglieder auf einzelne Aufgaben konzentrieren. Man sollte dann zu einem festgelegten Zeitpunkt – bspw. immer zur vollen Stunde – alle Dateien in das hoffentlich genutzte Versionierungssystem spielen. Danach haben alle Teammitglieder wieder einen einheitlichen Stand.
27. März 2012 um 11:37 Uhr
Kleine Anmerkung zu „Man sollte dann zu einem festgelegten Zeitpunkt – bspw. immer zur vollen Stunde – alle Dateien in das hoffentlich genutzte Versionierungssystem spielen.“:
Wenn man ein Versionskontrollsystem einsetzt, sollte man grundsätzlich nur fertige Arbeitsschritte einchecken, damit immer ein funktionierender Stand verfügbar ist. Einchecken nach bestimmten Zeiten oder dem Kollegen zuliebe ist wenig sinnvoll.
27. März 2012 um 13:48 Uhr
Deswegen liebe ich so mein Contao und die Extension Theme+. Mithilfe der Extension werden alle CSS- und JS-Dateien zusammengefasst und minimiert. Nie wieder nur noch eine große Datei oder 20 Requests im Head.
Auf der MMT29 hieß es zwar das man zur Laufzeit niemals Dateien komprimieren dürfte weil es die Performance beeinrächtigt, wir konnten das auf unseren Kundenservern noch nicht feststellen oder messen.
27. März 2012 um 16:02 Uhr
Das machen sicher auch andere CMS so, ausserdem gibt es Skripte. Das bringt mir aber nix, weil ich gar nicht im CMS oder direkt für eines arbeite 🙂 Zudem: warum soll ich denn zur Laufzeit Arbeiten ausführen, die ich auch prima lokal machen lassen kann?
Aber jeder so wie er es mag. Ich finde diese Option charmant, nimm Du ruhig Deine.
27. März 2012 um 17:00 Uhr
Zum Thema Modularisierung kann man auch einmal einen intensiveren Blick in den Code von bootstrap werfen. Die Jungs verwenden zwar less, haben sich aber viele Gedanken zum Thema Modularisierung gemacht. Lesenswert finde ich auch SMACSS.
Weshalb hast Du dich eigentlich für Sass entschieden?
27. März 2012 um 17:16 Uhr
Dazu habe ich vor ein paar Wochen geschrieben: http://grochtdreis.de/weblog/2012/02/14/compass-und-sass-haben-was/
Kurzfassung: ich nutze einen Mac, da kommt Ruby mit. Mit node.js möchte ich mich nicht nur wegen CSS beschäftigen und Less hat für mich einen Konstruktionsfehler. Der ist zwar behoben, aber wer sagt mir, dass da nicht noch mehr Konstruktionsfehler sind? Am Ende ist es egal, denn Less und Sass ähneln sich.
28. März 2012 um 18:10 Uhr
Danke. hatte ich nicht gesehen.
2. April 2012 um 7:50 Uhr
Welcher Konstruktionsfehler wäre das denn bei Less? Ich dachte bisher, dass es lediglich Geschmacksache ist, ob mann sass oder less nutzt. (Abgesehen von der Art der „Kompilierung“.)
2. April 2012 um 7:59 Uhr
@John: Folge einfach dem Link in Kommentar Nr. 5. Da begründe ich dieses Statement. Kurzfassung: die Ursprungsidee war, dass Less im Browser des Endnutzers kompiliert wurde. Das finde ich vollkommen daneben. Den gleichen Fehler hat „prefix“ von Lea Verou. Deshalb kann ich dieses Projekt nicht ernst nehmen.
Es ist ja okay, wenn ich als Entwickler eine effektivere Arbeitsweise einschlagen möchte. Das darf aber keineswegs auf Kosten des Endproduktes und des Endnutzers gehen. Und das tut der Ursprungsansatz von Less.
Mir ist vollkommen egal, wie das Projekt jetzt funktioniert. Allein die Tatsache, dass jemand so einmal gedacht und ein Tool konstruiert hat, ist für mich disqualifizierend.
3. April 2012 um 14:39 Uhr
Danke Jens. Das meinte ich mit „Kompilierung“. Deshalb mochte ich Less auch nicht. Die serverseitige Lösung braucht auch wohl heute noch den manuellen Stupps zum rendern, was bei der Arbeit ungemein störend ist. Da bin ich aber nicht auf dem laufenden, ob es immer noch so ist.