yellowled.de

Dieser Artikel ist archiviert. Er wurde am in YellowLeds Weblog v2 veröffentlicht. Der Inhalt ist inzwischen wahrscheinlich veraltet. Kommentare und Trackbacks wurden entfernt. – Zur Archivübersicht

Was ist eigentlich PostCSS?

Früher, als bekanntlich alles besser war, da haben wir ja noch „einfach CSS geschrieben“. Also damals, kurz nach dem Browserkrieg, als so langsam den meisten Webworkern klar wurde, dass dieser Blödsinn mit Spacer-GIFs in Layout-Tabellen so nicht weiter gehen kann.

Heute, wo jedes Byte einer Website durch einen Buildprozess und mehrere automatisierte Tests geblasen wird, ehe es dann vollautomatisiert deployt werden kann, geht das natürlich nicht mehr, heutzutage wird CSS von Prä- und Post-Prozessoren erzeugt. Das ist nichts Schlechtes, auch wenn der erste Absatz dieses Artikels danach klingen mag. Präprozessoren wie Sass, LESS und Stylus sind in meinen Augen ein Teil des Prozesses, Frontend-Entwicklung zu professionalisieren und zu automatisieren. Für die meisten dürfte einer davon heute zum täglichen Handwerk gehören, der eine oder die andere wird (wie ich) seit Monaten kein „Vanilla-CSS“ mehr geschrieben haben.

Und was ist jetzt dieses PostCSS?

PostCSS ist ein sogenannter „CSS-Post-Prozessor“, d.h. ein – in JavaScript geschriebenes, auf Node basierendes – Tool, um CSS zu verändern. Genauer gesagt verändert PostCSS selbst noch gar nichts, es „zerlegt“ CSS lediglich in einen abstrakten Syntaxbaum, schickt diesen durch Plugins, setzt das Ganze wieder zu CSS zusammen und „verfolgt“ anhand von Sourcemaps, was sich verändert hat.

Um PostCSS einsetzen zu können, benötigt man irgendein™ Build-Tool, für das es ein PostCSS-Plugin gibt. Die Abdeckung ist da schon jetzt enorm, und natürlich gibt es neben Plugins für die wohl beliebtesten Taskrunner Grunt und Gulp auch die Möglichkeit, ein PostCSS-Kommandozeilentool über npm auszuführen.

Plugins für so ziemlich alles

Das klingt natürlich bisher komplett abstrakt, was daran liegt, dass die eigentliche „Arbeit“ eben nicht PostCSS selbst macht, sondern die Plugins. Von denen gibt es viele, es werden quasi täglich mehr und glücklicherweise gibt es bereits ein filterbares Verzeichnis. Diese in JavaScript geschriebenen Plugins können im Grunde alles mit CSS machen – sinnvoll oder auch nicht; im Verzeichnis findet sich z.B. ein Plugin, das es möglich macht, Stylesheets auf Deutsch zu schreiben.

Sinnvolle Anwendungen

Das wahrscheinlich bekannteste PostCSS-Plugin, von dem viele vielleicht gar nicht wussten, dass es eben kein eigenes Tool ist, dürfte autoprefixer sein. autoprefixer fügt Stylesheets automagisch Vendor-Präfixe hinzu, und zwar – das ist der Clou daran – basierend auf der Can I Use-Datenbank.

Das bedeutet praktisch: Man „erklärt“ autoprefixer, welche Browser in welchen Versionen man unterstützen will oder muss und das Tool ergänzt die für diese Browser benötigten Vendor-Präfixe automagisch im Stylesheet. (Und stört sich dabei ggf. nicht einmal daran, wenn im Stylesheet bereits Vendor-Präfixe geschrieben wurden.) Kurz gesagt: autoprefixer macht es unnötig (aber natürlich nicht sinnlos!), sich zu merken, welche Version von welchem Browser wofür welches Präfix braucht. Supernützlich.

Weitere nützliche Plugins sind z.B. pixrem, das ein Fallback in px für die Einheit rem erzeugt, oder css-mqpacker, welches „verstreute“ @media-Anweisungen kombiniert. (Sven hat z.B. weitere Empfehlungen gebloggt.)

Die meisten PostCSS-Plugins mit „sinnvollen“ Einsatzzwecken dienen entweder der Optimierung des CSS oder dem Vorhaben, modernes CSS zu schreiben und Fallbacks dafür automagisch erzeugen zu lassen, also im weitesten Sinne der Automatisierung. Und (fast) alle nehmen uns Denkarbeit ab, die wir statt dessen ins (moderne) CSS stecken können.