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.

15 Kommentare zu “Compass und Sass haben was”

  1. Es soll nicht eine serverseitige Version von LESS geben, es gibt eine – basierend auf node.js, was es für mich aus dem Rennen genommen hat, weil SASS auf Ruby für mich lokal einfacher in Betrieb zu nehmen war und leichter zu warten ist. Die clientseitige Version von LESS eignet sich maximal zu Testzwecken.

    Deinen Einwand gegen Compass kann ich nicht nachvollziehen – abgesehen davon, dass man auch nur Teile von Compass nutzen kann, schleppst Du ja keinen Ballast mit; was von Compass nicht genutzt wird, wird auch nicht ins generierte Stylesheet eingebunden. Der Vorteil von Compass gegenüber eigenen oder zusammengeklaubten Mixins ist der geringere Wartungsaufwand, wenn man alles „in einem Paket“ hat, das noch dazu als Ruby-Gem bequem zu aktualisieren ist. Zudem wird Compass ziemlich regelmäßig gepflegt, bei einzelnen Schnippseln von GitHub wäre ich da skeptisch.

    Ich habe auch ein paar eigene Partials, mit denen ich bequemer arbeiten kann als mit Compass – aber gerade das CSS3-Zeugs, welches sich noch ändern kann und wird, ist mit Compass eigentlich ideal abgedeckt.

    • Jens Grochtdreis sagt:

      @Matthias: Stimmt, node.js war es. Genau deshalb fiel es aus dem Raster. Ich möchte eine einfach nutzbare Umgebung haben, die mir auch die Erstellung statischer Seiten ermöglicht. Denn mehr benötige ich für meine Templatevorlagen nie. Da war die Nutzung von Ruby, das bei MacOSX mitkommt, einfach perfekt.

      Ich finde die Ausgabe von Compass für meine bisherigen Zwecke einfach schlecht. Und ich möchte ja das Endergebnis nicht schlechter machen, als ich bisher geschrieben habe. Nur weil ich meinen Workflow verbessern möchte.

  2. molily sagt:

    Compass scheint tatsächlich etwas hinterher zu hinken. Wir verwenden seit langem die 0.12er-Alpha-Versionen (aktuell ist RC1 vom 2. Februar). Diese Bleeding-Edge-Versionen sind schon weiter. Allgemein scheint das Projekt Unterstützung zu brauchen, also ran an die Github Issues und Pull Request. ;)

  3. Habe grad auch an meiner ersten Compass-Extension gebastelt für den Einsatz von normalize.css. Witzigerweise sind Kristian Andersen und ich genau zeitgleich auf die selbe Idee gekommen, daher habe ich meine Ideen einfach in seinen Code eingebaut: https://github.com/ksmandersen/compass-normalize

    Man kann dieses Repository auch gut in Verbindung mit der Compass-Moduldokumentation als Vorlage für eigene Erweiterungen verwenden.

  4. datenkind sagt:

    Für LESS SASS und compass gibt’s doch schon feine Apps, die das Terminal oder serverseitige Kompilierung überflüssig machen. LESSapp, LiveReload und compass selber

  5. Mario sagt:

    @datenkind CodeKit nicht zu vergessen … ;-)

  6. Felix sagt:

    Such mal bei github nach Bourbon und sass dieses gem macht in meinen Augen einen gutenj Job wenn es um css3 Features geht, und somit compass überflüssig.

  7. Frank sagt:

    bzgl. PHP und Less (lessphp) ist die Bridge hilfreich.

  8. Paul sagt:

    Ich kann die Argumente gegen LESS nicht nachvollziehen:

    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. […] 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 Client-seitige Ausführung von LESS ist ein Feature, kein Nachteil. Niemand muss es nutzen. Man kann es aber für die schnelle Entwicklung gebrauchen. Wenn die Website dann ins Netz geht, sollte man das Stylesheet aber als CSS ausliefern. Das funktioniert mit LESS genauso wie mit SASS, entweder dynamisch vom Server oder als statisch gerendertes CSS.

    lessc styles.less > styles.css verwandelt eine LESS-Datei in eine CSS-Datei. Wo ist da das Problem?

    Und es ist auch nicht schwerer, LESS zum Laufen zu bekommen als SASS:

    1. Node installieren
    2. In einem Terminal npm install -g less ausführen.

    Fertig.

    • Jens Grochtdreis sagt:

      @Paul: Ich finde nunmal, dass es Sachen gibt, die nicht per JS in den Browser gehören. Und eine komplette CSS-Datei gehört definitiv dazu. Für mich bleibt es ein Denkfehler, ein Projekt überhaupt so aufzuziehen. Egal, wie es sich weiterentwickelt hat. Es kann mir niemand garantieren, dass sich nicht noch irgendwo Details verstecken, die ähnlich seltsam konstruiert sind. Das geht mir auch bei prefix-free so, das ich nur für Präsentationen akzeptieren kann, aber nicht für den Produktivbetrieb.

      Wenn Du das anders für Dich entschieden hast, dann gönne ich es Dir, vertsehen tue ich es nicht. Ich sehe auch keinen Sinn darin, eine extra Version für die Produktion anstossen zu müssen. Aber da sind ja offenbar die Geschmäcker verschieden. Und da Du offenbar viel mit node.js arbeitest, wäre sicherlich auch stylus etwas, das ja auf node aufsetzt. Für mich ist es nichts.

  9. Paul sagt:

    Ich finde nunmal, dass es Sachen gibt, die nicht per JS in den Browser gehören.

    Da stimme ich dir zu! Ich bin ebenfalls kein Fan von solchen Methoden.

    […] dann gönne ich es Dir, vertsehen tue ich es nicht. Ich sehe auch keinen Sinn darin, eine extra Version für die Produktion anstossen zu müssen.

    Was genau meinst du damit? Etwa, dass ich händisch vor dem Ausliefern der Website das Stylesheet kompilieren muss? Das ist jedenfalls besser, als es dynamisch auf dem Server erzeugen zu lassen. Denn in dem Fall lastet es „auf dem Rücken meines Endproduktes, also [dem] Nutzer“, was du ja zu vermeiden versuchst.

    Kurz zu meiner Präferenz: Ich nutze sowohl zum Entwickeln als auch zum Produktiveinsatz den statischen lessc-Compiler. Dann muss ich bei jeder Änderung neu kompilieren, aber ich kann die Website 1:1 so ausliefern. Generell halte ich wenig von dynamischen Inhalten, wo es auch anders geht.

    Ich wollte nur aufzeigen, dass sich für den ein oder anderen durchaus ein sinnvolles Szenario bietet, in dem man LESS auch im Browser ausführen kann. Und wenn LESS diese Möglichkeit bietet, ist sie alles andere als verkehrt. Du darfst aber gerne und ohne Einwand SASS verwenden, wenn es dir eher zusagt. Nur deine Argumente gegen LESS sind nicht sehr schlüssig. Niemand kann dir garantieren, dass es keine konzeptionellen Fehler in [hier Tool einsetzen] gibt.

  10. Michael sagt:

    Ich arbeite schon länger mit SASS und seit dem letzten Multimediatreff auch mit Compass, nachdem mich Sven Wolfermann doch schnell überzeugt hatte.
    Momentan nutze ich noch die Compass CSS3-Funktionen, bin damit aber auch noch nicht wirklich glücklich. Wenn mich nicht alles täuscht, dann bist du doch auch ein leidenschaftlicher YAML-Nutzer (Stichwort Technikwürze YAML total).
    Wie gehst du denn hier mit den IE-Stylesheets in Kombination mit deinen eigenen mixins vor? Hier habe ich noch keinen angenehmen Workaround gefunden, da ich die IE-Hacks nicht in der am Schluss zusammengefassten style.css haben möchte, sondern wie Dirk es vorsieht per Conditional Comments lade.
    Wie hast die mixins für dich umgeschrieben?

    Richtig interessant wird das ganze dann noch, wenn du die Sprite-Funktion von Compass nutzt.

  11. Andy sagt:

    Für LESS gibt es bereits eine sogenannte Demand Bridge, die LESS während der Laufzeit kopiliert und cacht. Gibt es eine gecachte Version und es wurden KEINE Änderungen am LESS Code gemacht, so wird auch weiterhin die gecachte Version ausgeliefert.

    Die Nutzung der Demand Bridge erfolgt hierbei recht simpel durch ein einbettendes link-Tag im Header:

    Hier die Lib dafür: https://github.com/andyhausmann/PhpLessDemandBridge

  12. Jens Grochtdreis sagt:

    Alle Less-Fans möchte ich noch einmal daran erinnnern, dass ich ihnen ihr Less durchaus gönne. Es ist bestimmt auch mittlerweile nicht schlecht. Ich habe nur für mich entschieden, dass ich das Tool deshalb nicht nutze, weil ich den ursprünglichen Ansatz für falsch halte. Ich bin mir deshalb nicht sicher, dass nicht irgendwo ein Pferdefuss ist.

    Da ich mich mittlerweile mit Sass halbwegs auskenne, Compass im Grossen und Ganzen zu überladen, schlecht dokumentiert und ansonsten auch nicht besonders toll finde, kann ich mir super vorstellen, auch mal Less in einem Projekt zu nutzen, wenn es die Umstände erfordern.

    Am Ende ist die Syntax kaum unterschiedlich. Das ist doch schonmal gut.

    Aber so findet jeder seinen Workflow. Ich habe hier nur meinen mit Euch geteilt.