Wieder ein neues CSS-Framework? Nein! Begonnen hat PostCSS als Postprozessor, war also für den Prozess nach dem Erstellen von CSS-Code gedacht. Mittlerweile hat sich PostCSS aber zum nützlichen Universalwerkzeug für die Manipulation von CSS entwickelt. Heute ist PostCSS für CSS das, was „Babel“ für Javascript ist: Es hilft Webworkern bei der Arbeit mit modernen Funktionen. Bei einigen Entwicklern gilt PostCSS deshalb auch schon als bessere Alternative zu Sass oder LESS. Ein Nachteil von Sass war es lange Zeit, dass Entwickler dafür Ruby installieren mussten und so unter Umständen ihren Entwicklungsprozess mit Abhängigkeiten belasteten. PostCSS ist dagegen ein kleines Node.js-Javascript-Tool, das einen CSS-Parser mitbringt und durch seine API das CSS verändert.

Der wohl größte Pluspunkt ist, dass Entwickler eigene Plugins für PostCSS schreiben können. Darüber hinaus gibt es aktuell eine große Auswahl an bereits bestehenden
Plugins aus der großen und umtriebigen Entwicklergemeinde. Mit mehr als hundert Plugins [1] für unterschiedliche Aufgaben wie CSS-Linting, Komprimierung, Asset-Handling oder das Umwandeln künftiger CSS-Eigenschaften können Entwickler ihre
Prozesse beliebig gestalten.

Das bekannteste und in den letzten Jahren auch nützlichste PostCSS-Plugin ist Autoprefixer. Webworker kennen das: Viele neue CSS3-Eigenschaften sind per Vendor-Präfixe in die Browser implementiert. Die meisten Hersteller haben fleißig mitgemacht und eigene Präfixe eingeführt. Ein beliebtes Beispiel ist „border-radius“. So las man oft folgendes Beispiel im Netz:

.rounded-corner { -webkit-border-radius: 1em; -moz-border-radius: 1em; border-radius: 1em; }

border-radius benötigt schon lange keine Vendor-Präfixe mehr, doch bei anderen Eigenschaften sieht das nicht so aus. Jede neue Eigenschaft doppelt und dreifach schreiben zu müssen ist jedoch nicht gerade optimal. Für Sass gab es das Plugin Compass, das eine Vielzahl an CSS3-Mixins lieferte, die diese Aufgabe übernahmen. Man inkludierte einmal das Mixin und Compass schrieb fortan die Vendor-Präfixe. Das Problem war, dass Compass die Vendor-Präfixe immer einsetzte, egal ob sie notwendig waren oder nicht.

Das löst Autoprefixer besser, denn bei dem Modul können Programmierer angeben, welchen Browser sie unterstützen möchten. Autoprefixer prüft dann anhand der caniuse.com-Daten [2], ob ein Präfix für die definierten Browser notwendig ist, und fügt die noch notwendigen Vendor-Präfixe zu den CSS-Eigenschaften hinzu.

['last 2 versions', 'ie >= 11', 'Android >= 4.4', 'Firefox ESR']

Entwickler können somit standardkonformes CSS schreiben und Autoprefixer wandelt dieses in ein CSS um, das alle Browser verstehen, die der Website-Betreiber unterstützen will – und zwar so intelligent, dass Autoprefixer auch die unterschiedlichen Flexbox-Syntaxen und die verschiedenen linear-gradienten Schreibweisen einfügt.

Anstatt der caniuse-Daten können Autoprefixer-Nutzer mittlerweile auch eigene Analytics-Daten zugrunde legen. So lässt sich beispielsweise angeben, dass das Plugin alle Browser prüft, über die mehr als fünf Prozent aller Zugriffe auf die Website kommen.

require('autoprefixer')({ browsers: ['> 5% in my stats', { stats: 'path/to/the/stats.json' }] })

Ein weiteres sehr nützliches PostCSS-Plugin, das zur Code-Qualität beiträgt, ist doiuse. Es überprüft, ob ein Entwickler im Projekt CSS-Eigenschaften verwendet hat, die einer der konfigurierten Zielbrowser nicht versteht.

require('doiuse')({ browsers: ['last 2 versions', 'ie >= 9', 'Android >= 4.3'], ignore: ['rem', 'css-boxshadow', 'css-transitions'] })

Der Beispiel-Code oben gibt etwa an, dass der Internet Explorer ab Version 9 die darin verwendeten Eigenschaften unterstützten soll. Verwendet ein Webworker nun Flexbox-Eigenschaften in seinem CSS, schlägt das Plugin Alarm, da der IE9 dies nicht versteht. Wer die Anweisung „calc()“ nutzt, erhält ebenfalls eine Warnung, da Android in älteren Versionen als 4.4 diese Funktion nicht unterstützt.

Einen teilweisen oder fehlerhaften Support zeigt doiuse ebenfalls als entsprechend an. Das Plugin überprüft aber nicht, ob der „buggy“-Fall im CSS überhaupt Anwendung findet. Das kann leicht verwirren. Dieses Verhalten soll sich laut Plugin-Autor aber in Zukunft ändern. Das Plugin soll dann besser kennzeichnen, welche Eigenschaft fehlerhaften oder teilweisen Support hat und welcher Browser die Eigenschaft überhaupt nicht versteht.

Das Linting überprüft, ob ein Code den Coding-Guidelines entspricht, und ist aus Javascript (JSlint) bekannt. Ähnlich können Entwickler mit Stylelint ihr CSS auf korrekten Code-Style überprüfen. Kommt ein Präprozessor wie Sass oder LESS im Workflow zum Einsatz, überprüft Stylelint das geschriebene SCSS/LESS vor dem Kompilieren. Dieses und einige andere Plugins haben dafür gesorgt, dass sich PostCSS vom reinen Postprozessor zum allgemeinen CSS-Werkzeug entwickelt hat. Stylelint sichert nicht nur die Code-Qualität sondern findet auch Fehler im CSS. Es sollte in einem modernem Workflow daher nicht fehlen.

Zwei der meist genutzten Funktionen von Sass sind zum einen @import, die Sass-Partials in andere Dateien einfügt, und zum anderen Nesting, das Anweisungen und Variablen verschachtelt. Die PostCSS-Plugins „postcss-import“, „postcss-simple-vars“ und „postcss-nested“ bieten diese Funktionen ohne Sass. Für modulare Code-Strukturen ist das unverzichtbar.

Variablen finden hier in einer ähnlichen Weise wie bei Sass/LESS Verwendung. Im Unterschied zu nativen CSS-Variablen (Custom Properties) liegen sie nur in einfacher Schreibweise vor. Wer aber die standardisierten CSS-Custom-Properties nutzen will, kann CSS Next (etwa „postcss-css-variables“ oder „postcss-custom-properties“) gebrauchen.

Die Frage bleibt, wie sinnvoll es ist, durch eine Vielzahl an Plugins einen Workflow zu verkomplizieren. Doch einen Präprozessor kann man mit PostCSS definitiv ablösen.

CSS Next [3] ist ein Sammelsurium an Plugins, die mehrere Funktionen haben. Entwickler können mit CSS Next jetzt schon die CSS-Syntax der Zukunft schreiben.Es ermöglicht unter anderem die Definition von Variablen in nativer Variablen-Syntax (Custom Properties), den Einsatz von Custom Media Queries oder es wandelt Pixel-Angaben automatisch in rem-Werte um. Zudem bringt CSS Next auch den Autoprefixer und Sass-Funktionen wie etwa das Nesting mit. Es ist damit eine Art Transpiler für CSS.

/* custom properties */ :root { --heading-color: #ff0000; } /* custom selectors */ @custom-selector :--headings h1, h2, h3, h4; /* usage */ :--headings { color: var(--heading-color); }

h1, h2, h3, h4 { color: #ff0000; }

Es ist praktisch, dass Entwickler somit neue Syntaxen und Techniken ausprobieren und im Projektalltag einsetzen können, ohne darauf zu warten, dass alle Browser die neuen Funktionen unterstützen.

Compass (für Sass) liefert eine besonders praktische Funktion: Es kann die Breite und Höhe einer Datei auslesen. Diese Funktion gibt es auch über das Plugin „postcss-assets“.

.logo { width: width("logo.svg"); height: height("logo.svg"); }

.logo { width: 100px; height: 40px; }

Zudem können Entwickler mit postcss-assets Grafikdateien direkt ins CSS einbetten lassen, also extern verlinkte Dateien in sogenannte Inline-Images umwandeln, was HTTP-Requests spart. Am Beispiel eines background-image sähe das so aus:

.logo { background-image: inline("logo.svg"); }

background-image: url("data:image/svg+xml,%3Csvg...")

Desweiteren lässt sich in dem Plugin eine Cachebusting-Funktion für die im CSS verlinkten Bilder aktivieren, was bei Seiten mit sehr aggressiv eingestelltem Clientside-Caching sehr hilfreich ist.

Das Plugin postcss-svg stellt, wie der Name schon andeutet, Hilfen für die Arbeit mit SVGs bereit. Wie bei der postcss-asset-Funktion „inline()“ können Webworker auch mit postcss-svg SVG-Dateien direkt ins CSS einbetten.

.svg-bg { background-image: svg('path/to/bg-svg'); }

.svg-bg { background-image: url("data:image/svg+xml,%3Csvg...") }

So weit so gut – doch so richtig hilfreich wird das Plugin erst, wenn Entwickler mehrere gleiche Assets mit unterschiedlichen Farben benötigen. Mit postcss-svg können sie nämlich die SVG-Dateien über Parameter verändern:

.svg-bg1 { background-image: svg('path/to/bg-svg', '[fill]: #{$color-text}'); } .svg-bg2 { background-image: svg('path/to/bg-svg', '[fill]: #{$color-main}'); }

Wer Assets kodiert ins CSS einbindet, muss die Datei vorher unbedingt so stark wie möglich komprimieren. Auch dafür gibt es mit PostCSS mehrere Möglichkeiten.

Zur Komprimierung von SVG eignet sich die Script-Sammlung CSSnano [4]. Letztere will weitergehen als die CSS-Minifier von Sass und Co. Daher entfernt es nicht nur „Whitespaces“, sondern zieht auch die CSS-Regeln zusammen, die den gleichen Selektor haben. Allerdings ist dabei Vorsicht geboten, da sich dadurch die Kaskade und damit das Ergebnis ungewollt verändern können.

Zudem will CSSnano z-Indizes simplifizieren. Auch das führt manchmal dazu, dass sich die Optik ändert. Es empfiehlt sich daher, CSSnano vor dem Praxiseinsatz ausführlich gegenüber dem bisherigen CSS-Minifier zu testen. Wer auf Nummer sicher gehen will, sollte die Anweisung „options.safe = true“ setzen, um die aggressiven Optimierungen nicht durchzuführen.

Die Liste an Plugins für PostCSS ist lang. Wer einen Präprozessor ersetzen will, kann CSSNext oder PreCSS [5] verwenden. Und wer nicht in die Falle von Flexbugs [6] tappen möchte, kann mit postcss-flexbugs-fixes [7] viele der Bugs bereits im Buildtask eliminieren. Mit postcss-debug können Entwickler die einzelnen Stufen debuggen, wenn sie mehrere Plugins verwenden und die Ausgabe nicht wie erwartet läuft.

Auch für die Barrierefreiheit bietet PostCSS Plugins, die unterschiedliche CSS-Versionen erstellen. So gibt es sicher für jeden Entwickler nützliche Plugins. Die Seite postcss.parts führt viele PostCSS-Plugins in mehreren Kategorien auf. Zudem vereinfacht die umfangreiche Dokumentation und einfache API die Entwicklung eigener Plugins.