Wieso sich Sass lohnt

Oder: Warum die eigene Toolbox besser als jedes Framework ist

5. Juni 2015  •  sass framework toolbox

Wie alles begann: Von einer heissen Affäre zur grossen Liebe

Die Entdeckung von CSS eröffnete mir eine ganz neue Welt. Ich liebte das Schreiben, ich mochte Photoshop, doch Stylesheets konnten etwas, was ich mir schon Jahre zuvor zum Ziel gesetzt hatte: Sie erlaubten mir, mit Worten Bilder zu malen. Nicht nur metaphorisch, sondern ganz fass- und sichtbar, was meine Gefühlslage auf ihren vorläufigen Höhepunkt katapultierte. Doch die anfängliche Freude verflog schnell. Ich wurde der ständigen Wiederholungen, die CSS mit sich brauchte, überdrüssig. Wieso sollte ich gewisse Angaben immer wieder schreiben und wieso konnte ich meine Styleangaben nicht einfach ineinander schreiben? Und diese ganzen Basic-CSS-Styles immer neu zusammenzuschustern, war auch nicht wirklich das, was ich mir unter „CSS-Schreiben“ vorstellte. Ich wollte etwas Neues schaffen und nicht ständig mit minimalen Kleinigkeiten beschäftigt sein. Nach dem anfänglichen High hatte mich CSS auf den harten Boden der Realität zurückgeholt.


Ergo: Es war in einer dunklen Zeit, als ich Bootstrap1 in mein Leben lies. Und – ich gestehe – wir gingen eine heisse Affäre ein… Bootstrap (kein custom build damals, weil custom builds dort nur minimal anpassbar waren) landete in jedem meiner Projekte. Ein bisschen hier, ein bisschen da – und wenn mir was nicht gefiel – na dann wurde es einfach überschrieben! Wie das herauskam ist vorhersehbar. Meine Stylesheets waren nicht schön anzusehen. „Chaos“, beschreibt es nicht einmal annähernd. Noch dazu war ich damals stur und ein Gedächtnistalent… Ich schrieb nicht einmal Kommentare, um zumindest einen Teil der Übersicht zu bewahren. Das war als ich felsenfest überzeugt war, jede margin: 31px hier und jeden float: right da auch einige Monate später noch exakt zu verstehen… (Spoiler: dem war nicht so) Nachdem ich allerdings im Chaos zu versinken drohte, zog ich einen folgenschweren Schluss: Die Affäre Bootstrap eignete sich ganz gut für One-Night-Stands, doch eine längerfristige Beziehung schien uns beide bloss in mentale Krisen zu führen. (So genau kenne ich Bootstrap’s Perspektive dazu nicht, aber ich stelle mir vor, dass er sich direkt ins nächste Abenteuer gestürzt hat und sich nun irgendwo in den Weiten des WWWs mit einem CSS-Frischling vergnügt) Ich für meinen Teil hatte die Nase erstmal voll von CSS Frameworks und schrieb wieder nur „vanilla“2 CSS. Alles schien besser als das was ich die vergangenen Monate getan hatte. Und trotzdem wusste ich, dass es so nicht weitergehen konnte. Und das musste es auch nicht. Denn in diesem Augenblick, eroberte Sass mein Herz. Und – es war Liebe auf die erste Zeile.

Schmetterlinge im Bauch, Spielereien und der erste Schritt in die gemeinsame Zukunft

Sass, es klang schon so vielversprechend. Syntactically Awesome Style Sheets3. Das klang nach mir und das musste ich mir ansehen. CSS mit Superheldenkraft war genau das, was ich mir von Bootstrap versprochen hatte. Was mir daran gefiel war, dass ich es in weniger als einem Tag lernen konnte. Alles was ich nicht auf Anhieb verstand, schien entweder unwichtig zu sein, oder spätestens dann lernbar, wenn ich es wirklich brauchen konnte. Das Beste an Sass war, wie viel kürzer meine Stylesheets wurden. Wie viel einfacher zu managen – wie viel grandioser als jedes Framework es sein konnte. Ausserdem liess es sich wunderbar mit Autoprefixer4 kombinieren, was ein gaaanz grosses Plus war. Variablen eröffneten mir einen Weg Farben zu speichern, Mixins ersparten mir unnötige Wege und allgemein war das Nesting das Non-Plus-Ultra, das ich mir von Anfang an gewünscht hatte. Sass füllte alle CSS-Lücken und erfüllte Wünsche, von deren Existenz ich noch nicht einmal gewusst hatte. Kurzum: alles war perfekt. Ich war bereit Sass in jedem meiner Projekte zu benutzen!

Und? Noch immer so glücklich wie am ersten Tag?

Wie sieht die Gegenwart aus? Die kurze Antwort: Keine Frameworks. Und die etwas Längere: Seit ich und Sass nur als Package Deal zu haben sind, habe ich kaum ein Framework mehr in meine Projekte gelassen (ab und an kann ein bisschen Bootstrap nicht schaden). Stattdessen reise ich mit einer kleinen Toolbox, die die Organisation und Instandsetzung von neuen Projekten so einfach machen, wie nie zuvor. Man stelle es sich wie einen Bootstrap Custom Built vor - bloss in viel cooler (much more sassy).


Wenn es um Sass geht, bin ich mittlerweile enorm begeistert von folgender Struktur in meinem Sass-Ordner:

│sass/
├── base/
│   ├── _reset.scss 
│   ├── _typography.scss
│   ├── _settings.scss
│   └── _base-style.scss
├── partials/
│   └── alle projekt partials
├── toolbox/
│   ├── _all.scss
│   ├── _colors.scss
│   ├── _functions.scss
│   └── _mixins.scss
└── main.scss

Die Toolbox scheint klar zu sein. Hier sammle ich alle Mixins, die man so brauchen kann, sowie Funktionen und Farben. Im _all-File importiere ich sie alle, sodass ich sie später mit nur einem einzelnen Import einfügen kann. Mixins können spannend sein, doch viel spannender ist der Base Ordner, den man auch als mein persönliches Framework bezeichnen könnte. (Wer sich übrigens den ganzen Start-Ordner ansehen möchte, mit dem ich jedes Projekt starte, darf das gerne hier tun.) Das reset-File setzt die Standard Styles der Browser mit dem grandiosen Reset von Eric Meyer zurück, im typography-File werden die Webfonts deklariert (per default verwende ich hier Roboto und Source Code Pro). Doch die ganze Magie passiert im settings-File zusammen mit _base-style.scss. Base style strotzt nur so von konditionalen Tags. Denn im Settings File, kann ich innerhalb weniger Augenblicke den ganzen Grundstyle ändern. In dieser Datei befinden sich alle Variabeln wie Breitenangaben für Media Queries, Standardschriften, Grössen etc. Doch es gibt noch andere Variabeln. Die yes-no-variabeln. z.Bsp. Wenn ein WordPress Projekt ansteht, müssen gewisse WordPress-spezifische Helper-Klassen integriert werden. Für andere Projekte machen diese Klassen nicht viel Sinn. Also habe ich es foldendermassen gelöst. Im Settings-File gibt es folgende Zeile:

$inlcude-WordPress-kit: yes;

Und im base-style file folgendes:

@if $inlcude-WordPress-kit == yes {
    .alignnone {
        float: none;
        margin: 0;
    }

    .aligncenter,
    div.aligncenter {
        display: block;
        margin: 0 auto;
    }

    .alignright {
        float: right;
        margin: 10px 15px !important;
    }

    .alignleft {
        float: left;
        margin: 10px 15px !important;
    }

    .gallery-caption {
        font-size: 0.9em;
    }

    .bypostauthor {
        > div {
            p {
                font-weight: bold;
            }
        }
    }

    .wp-caption {
        border: 1px solid rgba($black, 0.05);
        text-align: center;
        margin-top: 10px !important;
        margin-bottom: 10px !important;
        max-width: 100%;
        height: auto;
    }

    .wp-caption p.wp-caption-text {
        font-size: 0.9em;
    }

    .sticky {
        position: fixed;
    }
}

Nun. Wenn ich die Variable auf no setze, wird in meinem Base-Style keine dieser Deklarationen zu finden sein, sobald Sass CSS daraus generiert hat. Hätte wir das mit CSS gemacht, hätten wir das einfach jedes Mal für ein WordPress Projekt neu gemacht, oder wir hätten es in einem Starter-File drin und hätten dann die deklarationen auch in unseren Nicht-WordPress-Projekten drin. Machen wir das mit allen Möglichen Snippets, kann das schnell die Ladezeiten unseres CSS-files verlängern. Mit Sass ist das einfacher. Ausserdem schreibt man weniger. Wie viel weniger, möchte ich in meinem nächsten Beispiel illustrieren.

Sass: Der Zeilensparer schlechthin.

Ich habe bisher nie gezählt wie viele Zeilen ich effektiv spare. Doch wirklich realisiert, wie viel Sass reduzieren kann, habe ich, als ich mich mit der Navbar von digitalmind.ch befasst habe. Wir wollten für jede Sektion der Seite eine Farbe haben. Diese sollte in der Startseite vertreten sein und sich dann jeweils (unter anderem) in der Navigationsbar wiederholen. Gelöst habe ich das wie folgt: Jede Seite bekommt eine body-Klasse. Und dann habe ich eine einfache Map erstellt und in einem @each directive definiert. In Zahlen äussert sich das so, dass sich die Länge des Codes mehr als verdoppelt hat. Ausserdem ist der Sass-Code viel einfacher zu erweitern. Ich erweitere bloss die Map um die Body-Klasse und die Farbe und schon wird meine CSS erweitert. Beim CSS heisst das dann drei neue Zeilen pro ein Sass Key-Value-Paar.

Sass:

$menu-items:( about: $color-1, skills: $color-2, team: $color-3, portfolio: $color-4, themes: $color-5, plugins: $color-6, blog: $color-7, contact: $color-8);

@each $bodyclass, $color in $menu-items {
    body.#{$bodyclass} {
        nav {
            background-color: $color;
        }
    }
}


CSS:

body.about nav {
    background-color: #005899;
}

body.skills nav {
    background-color: #1f71ad;
}

body.team nav {
    background-color: #2f5b7b;
}

body.portfolio nav {
    background-color: #008b99;
}

body.themes nav {
    background-color: #007199;
}

body.plugins nav {
    background-color: #a1a1a1;
}

body.blog nav {
    background-color: #5e5e5e;
}

body.contact nav {
    background-color: #004b99;
}

Wieviel mir mein Flexbox-Mixin schon gespart hat, wage ich gar nicht zu zählen (auch wenn Autoprefixer hier einige Punkte zuzuschreiben sind, nicht nur Sass). Sass macht Spass, weil man nicht nur Nerven spart. Sobald man die Toolbox hat, ist sie wie eine Schatzkiste, die man mit sich nimmt. Und für jede Person nimmt man ein paar andere Kostbarkeiten hervor. Für die einen wird es bunt, für die anderen elegant, wieder andere wollen es gerade. Mit einem settings-file und Variabeln macht das Grundstyling mehr Spass als jemals zuvor.


Fazit: Sass ist auf jeden Fall nicht nur einen Blick wert, sondern ganz viele und Bootstrap und anderen Frameworks kan man für Sass auf jeden Fall ohne schlechtes Gewissen den Laufpass geben.

  1. Bootstrap ist ein Webframework für HTML, CSS und JS. Es bietet Komponenten und Grundstyles, die man in das eigene Projekt einbinden kann, um die ganze mühsame CSS-Arbeit nicht mehr zu machen. (Verfügbar sind ebenfalls custom builds, bei denen man gewisse Dinge ändern kann, oder einige Komponenten ausschliessen, allerdings kommt es auch bei diesen nicht selten vor, dass man dennoch Deklarationen überschreibt, weil was nicht stimmt)

  2. vanilla: bezieht sich hier auf die Benutzung einer Sprache ohne Zusätze, keine Frameworks, keine Bibliotheken, bloss was die Sprache „out of the box“ bietet.

  3. Sass ist das offizielle Akronym für Syntactically Awesome Style Sheets, wie man der offiziellen Website entnehmen kann.

  4. Autoprefixer ist ein post-processor, der basierend auf Daten von caniuse.com der generierten CSS-Datei alle nötigen Prefixe beifügt, sodass man selbst nie wieder welche schreiben muss.