PostCSS, wieso, weshalb, warum?

Für die Entwickler:innen unter euch ist wahrscheinlich schon klar, es geht um sogenannte „Cascading Style Sheets“, kurz CSS.

Der technologische Wandel des Internets und vor allem die Wirkung vom Javascript im gesamten Web-Tooling-Bereich haben in den letzten Jahren viel Fortschritt und Veränderung gebracht.

Was bisher geschah

Wer schon etwas länger in der Frontend-Entwicklung tätig ist, dem sollte SASS (Syntactically Awesome Stylesheets) ein Begriff sein.

Erstmals 2007 erschien mit SASS ein CSS-Präprozessor, mit dem *.sass-Dateien in valides CSS kompiliert werden konnten.

Der Vollständigkeit halber soll hier auch noch LESS erwähnt werden, was im Grunde so ziemlich dieselben Probleme löst – ob man das ein oder andere nutzte, war am Ende hauptsächlich Geschmacksfrage.

Ein kleiner Eindruck durch Code:

// Variablen
$red: #FF0000;
$blue: #0000FF;

.container {
    // Verschachtelte Selektoren
    .ein-element {
        color: $red;
    }
}

// Mixins um nervige Prefixes nur einmal tippen zu müssen
@mixin flex($attr) {
    display: -ms-flexbox;
    display: flex;
    -ms-flex-pack: $attr;
    justify-content: $attr;
    -ms-flex-align: $attr;
    align-items: $attr;
}

.zentrierterInhalt {
    @include flex(center);
}

// Extends um CSS-Blöcke wiederverwendbar zu machen
%toast {
    font-size: 0.8rem;
    background-color: $blue;
}

.container {
    @extend %toast;
}

Hier seht ihr nur einen kleinen Teil der Möglichkeiten, zur damaligen Zeit hat das die CSS-Welt und damalige Workflows revolutioniert.

Des Weiteren konnten SASS Dateien „importiert“ werden. Das konnte man auch schon in regulären Stylesheets, allerdings feuern native CSS-Imports weitere HTTP-Requests, was zu damaligen HTTP1.1 Zeiten bei größeren Projekten unschöne Performance-Einbußen mit sich brachte.

Mithilfe vom SASS-Compiler werden diese Imports bereits während der Entwicklung aufgelöst und zu einer einzigen .css-Datei zusammengefasst.

Somit kann man seinen Code strukturell deutlich sauberer halten und kann auch direkt beim „bauen“ Performance-Optimierungen vornehmen (Minifizierung, GZIP etc.).

Etwas später in der Entwicklung kam sogar „SASS-Script“ dazu, was rudimentäre Scripting-Möglichkeiten innerhalb von SASS-Dateien wie Kalkulationen oder Interpolation ermöglichte.

Was heute passiert

Seit Mitte 2017 ist nun auch PostCSS massentauglich geworden (erster stable release).

Es grenzt sich insofern von SASS und LESS ab, da es keine „CSS-Template“-Sprache ist, sondern vielmehr ein CSS-„Transformer“.

SASS hat ein eigenes (Datei-)„Format“ entwickelt, welches in valides CSS kompiliert wird – PostCSS verschlingt hingegen schon valides CSS und transformiert dieses.

Das passiert durch Plugins, die man frei wählen und kombinieren kann. Diese Plugins enthalten Regeln und Optionen, die bestimmen, was mit dem ursprünglichen CSS passieren soll.

Das Tolle hierbei ist vor allem der hohe Grad an Flexibilität, da man selbst bestimmen kann, welche Plugins in welcher Reihenfolge den Code transformieren sollen.

Oftmals sind diese Plugins sogar noch konfigurierbar.

Im Folgenden möchte ich ein paar wenige dieser Plugins kurz erwähnen, um zu zeigen, dass man sein „CSS-Game“ eventuell erweitern kann (soll?), und dass es als SASS-User mittlerweile noch viel Luft nach oben gibt.

Am weitesten verbreitet unter den PostCSS Plugins ist sicherlich der Autoprefixer, den viele schon seit SASS-Zeiten nutzen.

Man sagt ihm nur, welche Browser man unterstützen möchte und er versorgt euer CSS automatisch mit den entsprechenden Vendor-Prefixen für verschiedenste Plattformen.

Ein weiteres Plugin, ohne das wir nicht mehr leben möchten, ist CSSNext.

Ähnlich wie bei Babel für Javascript, kann man hiermit die neuesten und modernsten CSS-Features verwenden.

Das Plugin transformiert diese dann in mehr massentaugliches CSS.

Dies löst viele meiner SASS-Helper ab, lediglich die Syntax ist ein wenig anders. Hier ein kleiner Schnipsel mit Beispielen:

/* Variablen */
:root {
  --red: rgba(231, 0, 0);
}

a {
  color: var(--red);
}

/* Color Funktionen */
a {
  color: color(var(--red) alpha(10%));
}

a {
  color: color(var(--red) lightness(80%));
}

/* Custom Media Queries */
@custom-media --tablet (max-width: 768px);

@media (--tablet) {
  a {
    color: blue;
  }
}

/* Nesting */
a {
  & span {
    margin-left: 1rem;
  }
}

/* Custom Properties (Hallo Mixins?) */
:root {
  --centered {
    display: flex;
    justfiy-content: center;
    align-items: center;
  }
}

div {
  @apply --centered;
}

Selbst Grid-Systeme sind als PostCSS-Plugin erhältlich.

Ein Beispiel hierfür ist das beliebte LostGrid. Es stellt viele Helper zur Verfügung, die es sehr einfach machen in einem 12-Grid-System zu arbeiten, wie es zuvor auch mit vielen CSS-Frameworks wie Bootstrap oder Bulma oder wie sie alle heißen möglich war.

Die Syntax hierfür ist sehr prägnant und leicht lernbar:

section {
  lost-align: center;
}

div {
  lost-column: 1/3;
}

div:first-child {
  lost-offset: 1/3;
}

Dies ist natürlich nur ein kleiner Ausschnitt der PostCSS-Welt, aber wie ich hoffentlich zeigen konnte, sind nicht nur SASS/LESS Features einfach abbildbar, man erhält sogar noch viel mehr on-top.

Das Ökosystem ist gerade erst in seinen Kinderschuhen und bietet jetzt schon bei weitem mehr Flexibilität und Features als in der Vergangenheit möglich waren.

Selbst Optimierungen (minifizieren) können nun über PostCSS Plugins laufen und müssen nicht mehr Teil des Grunt/Gulp-Tasks sein.

Das Erlernen der neuen Syntax ist hierbei aber meiner Meinung nach marginal und ist wirklich nicht allzu schmerzhaft – vor allem, da CSS an sich auch keine wirklich „komplizierte Sprache“ ist.

Wer absolut nicht ohne SASS-Syntax leben möchte, für den gibt es auch noch das passende PostCSS Plugin, um weiterhin SASS im PostCSS zu schreiben. ;)

Nützliche Links

PostCSS – Hauptseite

Autoprefixer

CSSNext – Future CSS

LostGrid – Grid System

PreCSS – (SASS-Syntax)

PostCSS.parts – Plugin-Sammlung