Abschied von CSS-Frameworks

Warum ich keine CSS-Frameworks mehr benutze.
Die Hardt in Wuppertal

Zusammenfassung

  • Ein CSS-Framework erleichtert die Arbeit, mehrere machen Arbeit.
  • Die Entdeckung von CSS Grid gab den letzten Anstoß.
  • Die Einarbeitung in CSS Grid lohnt sich.
  • Ich überwand meinen Respekt vor den Media-Queries.
  • CSS-Frameworks blähen den HTML-Code auf.
  • Und sie verstoßen gegen das Prinzip der Trennung von Inhalt und Gestaltung.
  • CSS ist ein offizieller Standard. Frameworks nicht.
  • CSS ist deshalb das nachhaltigere Wissen.

Als ich vor einigen Jahren Hugo entdeckte, begann ich, das Design meiner Websites wieder selbst zu erstellen. Mehr als ein Jahrzehnt hatte ich das nicht mehr getan, sodass ich im Prinzip alles neu lernen musste. Mir erschien es damals am einfachsten, ein CSS-Framework zu benutzen. Ich probierte Bootstrap, Bulma und einige andere. Schließlich landete ich bei Tachyons. Damit erstellte ich eine ganze Reihe von Websites.

Wechsel des Frameworks erfordert Umdenken

Die größte Hugo-Website, an deren Gestaltung und Pflege ich beteiligt bin, ist die Website meiner Hosting-Genossenschaft Hostsharing eG. Bei Hostsharing setzen wir Bootstrap als CSS-Framework ein. Ich musste mich also regelmäßig mit zwei verschiedenen CSS-Frameworks auseinandersetzen und ständig umzudenken.

Ich ertappte mich dabei, dass ich immer wieder die Bootstrap- oder Tachyons-Dokumentation zu Rate ziehen musste, weil ich mir die jeweiligen CSS-Klassen nicht immer merken konnte. Außerdem haben beide Frameworks auch noch eine recht unterschiedliche Philosophie. Besonders frustrierend war die Erkenntnis, dass man oft trotz Framework nicht ohne eigenes CSS auskommt.

CSS Grid gab den letzten Anstoß

Schließlich entschloss ich mich, einmal eine Website ganz ohne CSS-Framework zu gestalten. Den letzten Anstoß gab mir die Entdeckung von CSS-Grid.

CSS-Grid ist ein Standard-CSS-Modul, um zweidimensionale Raster-Layouts in HTML zu erstellen. Die CSS-Frameworks, die ich kennen, nutzen für diesen Zweck Flexbox, das aber etwas anders funktioniert. Die Unterschiede zwischen CSS-Grid und Flexbox erklärt Chris Coyier in seinem Blog.

Der Start war mühsam. Es hat eine ganze Weile gedauert, bis ich verstanden hatte, wie CSS-Grid funktioniert. Hilfreich waren folgende Quellen: A Complete Guide to Grid, CSS Grid Layout Module, CSS Grid Layout und CSS Grid – Einführung in Gestaltungsraster mit dem Grid Layout Module.

Nun kann man sicherlich mit mehr oder weniger großem Aufwand CSS Grid mit den gängigen CSS-Frameworks kombinieren. Ich wollte jedoch die Gelegenheit nutzen, um eine Website mit eigenem CSS zu erarbeiten. Bei der Arbeit habe ich nun folgende Erfahrungen gemacht.

Zunächst habe ich CSS Grid vermutlich völlig falsch benutzt, denn ich versuchte ein großes Raster-Layout zu erstellen, um Elemente wie auf einem Schachbrett hin- und herzuschieben. Aber eine Webseite ist auch in den 20er Jahren des 21. Jahrhunderts immer noch keine Druckseite. Außerdem hat mich die Flexibilität, mit der man einzelne Grid-Zellen, Grid-Zeilen, Grid-Spalten oder Grid-Bereiche bezeichnen kann, anfänglich irritiert. Erst als ich alle Möglichkeiten halbwegs verstanden hatte, konnte ich eine Entscheidung treffen, was ich nicht brauche.

Die wurde leichter, als anfing, möglichst einfache Raster zu definieren. So reicht für das globale Seiten-Layout oftmals ein Raster mit zwei oder drei Spalten. Für kleinere Einheiten wie zum Beispiel die gekachelte Startseite auf dieser Website, die Leiste mit der Bücherbewerbung oder das Element mit verwandten Artikeln habe ich jeweils neue Grids definiert, die innerhalb dieser Elemente funktionieren. Eine große Hilfe waren die Developer-Tools vom Firefox, mit denen man die Grids anzeigen kann.

Keine Angst vor Media-Queries

Ich hatte zu CSS-Frameworks Zuflucht genommen, weil mir die Media-Queries gehörigen Respekt einflößten und ich mich nicht mit dem Thema beschäftigen wollte. Deshalb haben mir die Media-Queries in meinem eigenen CSS anfänglich Probleme bereitet, bis ich begriff, dass man das Layout im CSS im buchstäblichen Sinne mobile-first aufbauen kann.

Man fängt in der CSS-Datei mit dem kleinsten Bildschirm und den Stildefinitionen an, die überall gelten. Dann springt man nach und nach zu den größeren Bildschirmen und definiert Ausnahmen. Das ist einfacher als umgekehrt. Vermutlich lernen Mediengestalter das in der ersten Stunde, ich habe dafür länger gebraucht.

Media-Queries für die größeren Bildschirmen werden bei diesem Vorgehen mit min-width definiert.

@media screen and (min-width: 720px) {
...
   }

Zwischen den Klammern werden die Stile definieren, die nur auf Bildschirmen zur Anwendung kommen, die mindestens 720px groß sind. Und so geht es weiter bis zu den größten Bildschirmen. Schritt für Schritt entfaltet sich das Layout. Es beginnt einspaltig und faltet sich dann an den entsprechenden Breakpoints auf und wird zwei- und schließlich dreispaltig. Die CSS-Grid-Anweisungen können natürlich auch je nach Bildschirmgröße verändert werden.

Mit CSS-Grid kann man so inhaltliche oder gestalterische Einheiten auf einer Website sehr flexibel und responsiv positionieren und gestalten. Das hat den Vorteil, dass man im HTML leichter auf den logisch richtigen Aufbau achten kann, ohne sich Gedanken darüber zu machen, wo die Elemente später einmal auftauchen.

Übersichtlicherer HTML-Code

Der HTML-Code wird übersichtlicher, wenn man ohne ein CSS-Framework arbeitet. Mit Tachyons sah die Definition der Zusammenfassung am Anfang eines Blogbeitrags folgendermaßen aus.

{{ with .Params.abstract }}
<div class="ba b--white pa3 bg-black-20 sans-serif">
  <div class="measure-wide">
    <div id="text" class="f3">Zusammenfassung</div>
    <div class="lh-copy">{{ . | markdownify }}</div>
  </div>
</div>
{{ end }}

Ohne CSS-Framework ist es deutlich übersichtlicher:

{{ with .Params.abstract }}
<div class="abstract">
  <h3>Zusammenfassung</h3>
  <div>{{ . | markdownify }}</div>
</div>
{{ end }}

Die Ersparnis im Beispiel sieht nicht sehr groß aus. Aber bei komplexen Templates wirken sich die Unterschiede spürbar aus. Ich habe die spezielle Markup für Hugo-Templates im Beispiel belassen, damit deutlich wird, dass Templates noch einmal komplexer sein können als das finale HTML. Gerade beim Schreiben von Templates ist weniger Code eine Erleichterung.

Wenn man in größeren Projekten verschiedene Templates für die Gestaltung von Webseiten in verschiedenen Bereichen nutzt (z.B. Blogpost, Termine, Übersichten), wiederholen sich an vielen verschiedenen Stellen die gleichen Klassen. So könnte es zum Beispiel auf Blogposts, Terminen und Übersichten eine Zusammenfassung geben, die immer gleich aussehen soll. Man muss dann immer die gleiche, lange Reihe von Klassen in die HTML-Tags hineinschreiben. Und ändert man die Gestaltung der Zusammenfassung ändert, muss man alle Templates anpassen. Fehler sind so vorprogrammiert. Templates noch weiter in kleinere, wiederverwendbare Snippets zu zerlegen, wäre eine Lösung. Man schafft damit aber eine neue Unübersichtlichkeit. Bei eigenen Klassen wie im zweiten Beispiel verändert man lediglich die CSS-Definition der Klasse abstract und schon ist das Aussehen der Zusammenfassung an allen Stellen angepasst.

CSS-Frameworks – ein Missverständnis?

CSS-Frameworks scheinen gegen den Grundsatz der Trennung von Inhalt und Form anzukämpfen. Dabei war diese Trennung die Idee hinter den Stylesheets. Stattdessen wirbt das CSS-Framework Tailwind auf seiner Website mit dem Spruch: »Rapidly build modern websites without ever leaving your HTML.« Das mag bequem sein. Der Grundgedanke von CSS wird damit aber ad absurdum geführt.

Sind CSS-Frameworks ein Missverständnis? Meines Wissens kam die Idee auf, als Twitter sein für interne Zwecke erstelltes CSS-Framework unter dem Namen Bootstrap veröffentlichte. Das Unternehmen verfolgte mit dem Framework mindestens zwei Ziele. Die Entwicklung von Webseiten sollte schneller erfolgen und es sollte ein einheitliches Aussehen gewährleistet werden. Letzteres war leider so erfolgreich, dass es sehr viel Arbeit macht, mit Bootstrap ein Design zu erstellen, das nicht gleich als Bootstrap-Design erkennbar ist. Bootstrap und die meisten anderen Frameworks sind deshalb heute anpassbar. Man kann viele Komponenten wie zum Beispiel das Farbschema verändern. Erspart das Arbeit? Oder schafft es neue Arbeit?

Statt von Twitter zu lernen und unternehmensintern ein eigenes Framework zu entwickeln, hat sich die Branche auf Bootstrap gestürzt und visuell austauschbare Websites geschaffen. Natürlich ist dieses Urteil übertrieben. Aber CSS-Frameworks lenken das Design immer in eine bestimmte Richtung. Frameworks wie Tachyons oder Tailwind, die mit sehr kleinen Klassen arbeiten, lassen dem Gestalter mehr Spielraum. Der Preis ist ein unübersichtlicheres HTML.

Nachhaltigeres Wissen

Um eine Website mit eigenem Stylesheet erstellen zu können, musste ich mich erstmals intensiv mit CSS auseinandersetzen. CSS ist ein offizieller W3C-Standard. Frameworks gehorchen eigenen, inoffiziellen Regeln. Es ist nachhaltiger, sich mit einem offiziellen Standard auseinanderzusetzen, als mit den jeweils individuellen Regeln eines Frameworks. Denn wenn mein nächstes Projekt nicht mit dem Framework erstellt wird, das ich kenne, muss ich neue Regeln lernen. Die CSS-Spezifikation ist in allen Projekten die gleiche. CSS ist ein nachhaltigeres Wissen als Bootstrap.