Compass und Sass haben was
In den letzten Monaten gab es eine Reihe Artikel zu diversen Präprozessoren, vor allem Sass und Less. Um mich herum stiegen immer mehr Entwickler auf diese Systeme um. Ich konnte den Systemen lange nichts abgewinnen, waren doch viele Beispiele für mich relativ unnütz, weil ich ein vernünftiges CSS-Framework nutze und deshalb keine Grids selber ausrechne oder überall einen clearfix-Hack einfüge. Allerdings hatte ich in der Vergangenheit ein paar Seiten, die mit Themes versehen wurden. Hinzu kam eine Seite, bei der ich viele unterschiedliche Farben und Verläufe nutzte. Das CSS war allein wegen der vielen vendor-prefixes extrem aufgeblasen. Also gab ich Compass und Sass eine Chance, als ich an einem neuen, etwas kleineren Projekt sass. Und ich muss sagen, ich habe Blut geleckt. Ich möchte hier nicht die x-te Einführung geben. Dafür wurde schon im letzten Webkrauts-Adventskalender (Teil 1 und Teil 2) von Mathias Schäfer und im CSS3-Adventskalender bei Sven Wolfermann ausreichendes geschrieben. Abseits der grundsätzlichen Einführungen gibt es aber Erfahrungen, die selten zu lesen sind.
Dass die Wahl auf Sass fiel hatte seine Gründe. Es ist in meinen Augen das bekannteste System mit einer großen Community. Zudem hat Less einen Konstruktionsfehler: es wurde anfangs im Browser gerendert. Es soll wohl auch eine serverseitige Version geben, doch dieser Konstruktionsfehler hat mich gegen das System eingenommen. Die gleichen Vorbehalte habe ich gegen prefixfree von Lea Verou. Ich möchte nicht, dass Tools, die ich für meine Bequemlichkeit nutze, auf dem Rücken meines Endproduktes, also der Nutzer ausgeführt werden. Jedes CSS-Rendering mittels JavaScript zieht die Performance der Seite unnötig herunter und macht die Seite ohne Javascript unbenutzbar. Die Syntax von Sass und Less unterscheidet sich nicht allzusehr.
Da ich viel mit CSS3 arbeite, lag für mich die Nutzung von Compass nahe. Denn dieses Zusatzframework bringt eine Masse mixins für CSS3 mit. Die Praxis zeigte mir schnell, dass diese mixins für meine Ansprüche zu schlecht waren. Ich arbeite nun also mit Compass, ohne ein einziges mixin davon zu nutzen. Ich fand die Ausgabe von Compass schlecht, weil bspw. bei der Ausgabe von IE-Filtern meist die -ms-filter-Variante fehlt. Zudem bekommen die Elemente kein hasLayout mittels zoom:1 zugewiesen, was die Filter evtl. unsichtbar macht.
Bislang habe ich im Wesentlichen Farbvariablen genutzt, habe Elemente verschachtelt und mixins für border-radius (ich will noch ganz alte Browser mitnehmen), gradients und box-shadow genutzt. Ausserdem habe ich mir selber ein mixin geschrieben, mit dem ich über :before oder :after Pfeile erzeugen kann.
Für meine Bedürfnisse reichen ein paar CSS3-mixins, die ich in den unendlichen Weiten von github gefunden habe. Ich habe sie mir mittlerweile bearbeitet und in zwei mixins gesplittet. Die eine Version ist für die alten IE, die andere für moderne Browser. Ich muss so nur irgendwann im Zuge der Bearbeitung die CSS3-Regeln für eine IE-Version herausziehen. Da die Namen der mixins identisch bleiben, erzeugen sie dann im IE-spezifischen CSS genau den passenden Code - und nur den.
Leider gibt es bislang noch keine Möglichkeit, diesen Vorgang aus dem SCSS-File zu automatisieren. Aber wenn ich den dazugehörigen Thread in github richtig verstanden habe, wird zumindest darüber nachgedacht, das Aufsplitten von Regeln aus einer Datei in zwei Zieldateien entweder in Compass oder in Sass zu integrieren. Ich bin gespannt. Aber auch ohne diese weitere Erleichterung ist mein Workflow mittlerweile schon besser geworden. Meine Arbeitdatei ist übersichtlicher und ich kann viel einfacher mit Farben hantieren. Ich werde mit der Zeit sicher noch ein paar weitere Highlights entdecken. Aber der erste Schritt ist getan und ich möchte das Tool nicht mehr missen. Irgendwann teste ich auch die Erzeugung von Sprites aus. Das kann Compass nämlich auch. Ich werde mir auch mal die Compass-recipes anschauen. Das scheint mir eine interessante Sammlung zu sein.
Wer wie ich im Laufe eines Projektes entscheidet, Compass zu verwenden, der hat ein Problem. Sowohl die Doku als auch alle Einführungen, als auch das im Entstehen befindliche Buch bei Manning erklären immer nur, wie man in einem leeren Verzeichnis mittels Compass eine Grundstruktur erzeugt. Das war aber gar nicht mein Wunsch. Nach längerem Suchen bin ich auf folgende Zeile gestossen, die man im Terminal im betreffenden Verzeichnis ausführen muss:
Ich bin mal gespannt, welche Details mir mit der Zeit noch so auffallen. Aktuell splitte ich mein CSS und meine mixins in viele unterschiedliche Dateien, am Ende kommt eine Datei bzw. noch eine weitere IE-Datei heraus. Während der Entwicklung kann ich hingegen in kleinen, übersichtlichen Dateien arbeiten. Auch meine Variablen habe ich ausgelagert. So werden sie von der normalen und der IE-spezifischen Datei erfasst und verarbeitet.