CSS - Warum ich DIY mag

Meine ersten Begegnungen mit CSS hatte ich im Jahr 2003. Da dieses Konzept damals noch in den Kinderschuhen steckte, wurden die Gestaltungselemente mittels einer Tabelle platziert. Das Ganze nannte sich Tabellenlayout. Außerdem musste eine Website damals in einem Internetexplorer mit der Version 5.5 angezeigt werden. Zum Glück ist das aber lange lange her und in diesem Artikel soll es darum gehen, wie man sein Frontend mit modernen Mitteln schlank und übersichtlich hält.

Framework

Viele Programmierer verwenden heutzutage CSS-Frameworks. Allen voran Bootstrap, Foundation und Tailwind. Das Schöne an diesen Frameworks ist, dass sie viele Dinge, wie Beispielsweise ein Raster oder rudimentäre Elemente wie Buttons und Formulare mitbringen. Bootstrap hat in der Variante 5.x 24 solcher Komponenten. Außerdem gibt es ein 12-Spaltenraster, Massenhaft Farben und Effekte bis hin zu kompletten Navigationen. Für jemanden der eine neue Seite ohne große Ansprüche mal eben aus dem Boden stampfen möchte, gibt es alles was das Herz begehrt. Ein weiterer Vorteil von solchen Frameworks ist, dass man ein einheiltliche Methode an Klassenamen hat und somit jeder Entwickler, der neu zum Projekt kommt, sofort weiß wie er neue Elemente anlegen kann. Hört sich doch gut an, nehmen wir - denkt man sich. Doch in der Praxis sieht das immer ein bisschen anders aus.

Spoileralarm

In diesem kommen die Frameworks nicht gut weg und ich möchte mich auch nicht lange mit ihnen aufhalten. Meine Devise lautet: Selbermachen.

Nicht benutztes CSS

Die meisten Frameworks stellen eine Unmenge an nützlicher Klassen bereit - über alle Breakpoints und für alle Spalten. Das bedeutet, die Entwickler müssen eine großen Aufwand betreiben und nicht benötigten CSS-Code aus den Projekt zu entfernen. Als Ausnahme sei hier Tailwind genannt. Diese analysiert den HTML-Code und bindet nur die verwendeten Klassen ein. Die Idee finde ich zwar ganz witzig, allerdings muss ich mir hier einen Mechanismus überlegen wie ich dem Kompiler mitteile, welche Klassen ich dynamisch, während der Laufzeit oder im Renderingprozess einbinden möchte. Ich nehme an, dass es eine Lösung dazu gibt. Da ich Tailwind noch nie im Einsatz hatte, kann ich nichts weiter dazu sagen. Bei Bootstrap muss man entscheiden welche Breakpoints verwendet werden und wie viele Spalten im Design vorhanden sind. Außerdem kann man unbenutzte Komponenten entfernen. In der Praxis habe ich nur den letzten Schritt gemacht. Ich immer alle Spalten und alle Breakpoint und alle Farben mit mir herum geschleppt. Danach kann der HTML-Code analysiert werden und mit Helfern wie PurgeCSS (https://purgecss.com/) kann dann noch überflüssiges CSS entfernt werden. Bei letzten Schritt muss ich auch eine Methode finden um mit dynamischen CSS-Klassen umzugehen. Oder man akzeptiert einfach, dass massenhaft CSS ausgeliefert wird, das nie in Benutzung ist.

Das eigentliche Problem

In meiner ganzen Zeit als Webentwickler habe nicht ein einziges Design bekommen, das nicht irgendwo mit einem Framework kollidierte! Die Navigation: Ich habe Tage damit verbracht ein Navigation mithilfe von Bootstrap-Komponenten umzusetzen und am Ende alles selbst gemacht. Die Spalten: Designer sind kreativ. Sie platzieren sie Elemente auf der Website so dass es gut aussieht und dann kommt der Programmierer und sagt: Das passt aber nicht in meine Spalten rein. Mit dem Ergebnis, dass ein gutes Design am Ende wie eine Bootstrapseite aussieht - nur mit anderen Akzentfarben und einer anderen Font. Einmal hat ein Entwickler gesagt: Die Designer müssen halt verstehen, dass nicht alles möglich ist. Das ist falsch. Es ist meine Aufgabe als Programmierer die Gestaltung so gut wie möglich umzusetzen. Wenn ich das falsche Werkzeug habe, kann ich nicht den Designer zwingen etwas hässliches zu erstellen.

Die Alternative - Selbermachen

Wenn ich ein neues Design bekomme, versuche ich, alle Elemente in die folgenden Kategorien einzuordnen:

Typografie

Diesen Teil hat hoffentlich der Designer zur Genüge ausgearbeitet. Hier werden die Schriften und Akzente hinterlegt. Hier lege ich den Gestaltern nahe, für die verschiedenen Endgeräte entsprechende Ausarbeitungen zu machen. Da erspart unnötige Zyklen und Anpassungen bei der Abnahme.

Seite und Raster

In einem Design gibt es immer Bereich die auf allen Seiten gleich sind: Header, Footer, Navigation etc. Im diesem Schritt muss also definiert werden, wo die Abgrenzung ist und wie viele verschiedene Seitentypen benötigt werden. Danach kann ich entscheiden, wie die Seiten sich auf den verschiedenen Endgeräten zu verhalten haben. Danach schaue ich die Inhaltsbereiche der Seiten an und überlege mir ob es ein seitenübergreifendes Spaltensystem geben soll. In der Regel werden hier eine Handvoll Spalten benötigt. Meist im Verhältnis 1:1, 1:2 und 1:3. Wohlgemerkt auf dem Desktop. Auf den anderen Geräten brechen die meisten Designs einfach bei jeder Spalte um. Und in diesem Schritt liegt auch oft der Konflikt. Der Gestalter möchte ein Element mit bestimmten Spaltenbreiten und Abständen die aber vom Raster meines Frameworks nicht vorgesehen sind. An dieser Stelle muss entweder der Designer seine Kreativität beschränken oder ich muss um das Framework herum programmieren. Beides macht keinen Spaß!

Atome

Das sind Komponenten die man überall benötigt: Buttons, CTA, Formularelemente. Auch hier kollidiert die Anforderung der Gestaltung in den meisten Fällen mit dem Framework. Abgesehen davon, dass das Framework tonnenweise Varianten bereit hält, die ich überhaupt nicht benötige. Das CSS für die Atome muss so gestaltet sein, dass es in allen Kontexten ohne viel Aufwand funktioniert.

Komponenten

Text mit Bild, Galerie, Akkordeon und wie sie alle heißen. Hier kommen wir zu dem Punkt warum ich das alles gerne selbst mache. Die Komponenten sollten in sich funktionieren. Egal an welcher Stelle in der Website sie zum Einsatz kommen. Das bedeutet: Ein Akkordeon muss auf der Startseite oder einer Unterseite, in der Hauptspalte oder in der Marginalspalte funktionieren. Ein Text mit Bild muss für sich alleine, in einer Lightbox oder in einem Akkordeon funktionieren. Das bedeutet, dass ich mein CSS für die einzelnen Komponenten, kontextunabhängig schreiben muss. Darüber hinaus darf eine Komponente keine Effekte auf ihre Umgebung haben. Das bedeutet das Verwenden von IDs ist von vornherein verboten. Wer eine ID im CSS verwendet, muss das vor dem gesamten Team erklären und sich darauf gefasst machen, dass dafür geteert und gefedert wird. Javascript muss so programmiert sein, dass es keine Fehler produziert wenn das Element fehlt oder wenn mehrere gleiche Elemente vorhanden sind.

Die Lösung: BEM

Ich muss gestehen, es hat einige Jahre gedauert bis ich das entdeckte und es hat zwei Menschen benötigt die mir das erklären mussten: Patrick und David (Hier nochmal: Danke!) Zitat: BEM - ist eine Methodik, die dir hilft, wiederverwendbare Komponenten und gemeinsamen Code in der Front-End-Entwicklung zu erstellen Ich möchte hier überhaupt nicht viel schreiben und die Autoren selbst zu Wort kommen lassen. Aber eines vorweg: Seit ich versuche BEM umzusetzen, macht mir Frontend Spaß und es ermöglicht, die Anforderungen von oben verständlich und schlank umzusetzen. https://getbem.com/