molily: Pro vs. Cons Sass (Syntactically Awesome Stylesheets)

Beitrag lesen

Wir setzen nur noch Haml und Sass (sowie verstärkt CoffeeScript) ein. Die meisten unser Projekte sind aber auch in Ruby on Rails. Da ist es sehr einfach, Sass zu integrieren. Wir schreiben hauptsächlich den .sass-Dialekt (nicht .scss). Schreibt man .scss, dann muss man seine gewohnte Syntax nur wenig abändern.

Über die Imports lassen sich Stylesheets sehr gut modularisieren, ohne dass man sich über das Kompilieren Gedanken machen muss. Das nimmt einem Sass ab. Imports unterscheiden zwischen echten Imports und solchen, die von Sass aufgelöst werden, was sehr sinnvoll ist.

Mixins, Variablen und einfache mathematische Operationen sind ebenfalls äußerst brauchbar. Clearfix ist ein häufiger Mixin, sämtliche Farbwerte sollten Variablen sein und Berechnungen braucht man oft, wenn man nicht mit box-sizing das ganze Box-Modell ändern will.

Was mir eher ein Dorn im Auge ist, ist die Verschachtelung von Regeln. Das ist jetzt kein Nachteil an sich, aber es verführt dazu, das CSS genauso in einem »Baum« zu schreiben wie das DOM:

<section>
  <h1>foo</h1>
  <article>
    <p>
      <a href="">

Sass legt einem nahe, sein Stylesheet analog aufzubauen:

section
  h1
    font-size: 150%
  article
    border: 1px solid red
    p
      margin: 1em 0
      a
        color: red

Das hat schon seine Logik, führt allerdings zu unnötig langen Selektorketten (section article p a { color: red }), wo beispielsweise »article a« ausreichen würde. Hier sollte man Sass-Code immer möglichst »links halten«, kleine autonome Pakete schreiben und Verschachtelung nur nutzen, wenn es zum Selektor etwas sinnvolles beiträgt.

Mathias