Der Bootstrap-Klassen-Horror

Eine praktische Anleitung zur fortschrittlichen Verwendung des Grid-Frameworks Bootstrap, wie sich Layout und Markup durch die Verwendung von Sass voneinander trennen lassen und warum Codes wie der folgende der Horror sind:

„Viel hilft viel“ scheint häufig das Motto zu sein, wenn es um CSS-Klassen geht, mit denen man sein Web-Template geradezu inflationär aufpumpen kann. Angestachelt von der Bootstrap-Dokumentation werden Positionierungen von Elementen, Farben, Border, Abstände, Text-Formatierungen, Typografie und was das Herz sonst noch begehrt im Markup verewigt. Hier sollte man allerdings kritisch hinterfragen, ob das – was anscheinend ja gut funktioniert – auch einem zeitgemäßen Qualitätsanspruch der Frontend-Programmierung entspricht.

Neben längeren Ladezeiten von Websites, da im Gegensatz zum Markup das CSS vom Browser in der Regel gecached wird, sind vor allem starre und unflexible Web-Templates das nervende Resultat einer unkontrollierten Misswirtschaft von CSS-Klassen. Nicht nur nachträgliche Anpassungen und Änderungen, sondern bereits die Umsetzung eines Templates werden dadurch meist deutlich zeitaufwendiger.

Lässt man den Faktor „responsive“ mal außer Acht, verfallen viele Frontend-Entwickler gleich einem Ex-Süchtigen gerne zurück in alte Muster.

Als die anfängliche Programmierung von Internetseiten über Tabellen geschah, welche durch jede Menge <table>, <tr> und <td> Tags gebaut wurden, läutete der Hype „Layout und Content müssen voneinander getrennt werden“ das neue Zeitalter der Frontend-Entwicklung ein. Anordnung und Gestaltung fanden nun forciert im CSS statt, welches ein unbeflecktes Markup anhand von IDs und Klassen beschrieb.

Heute stehen wir wieder am gleichen Punkt wie zehn Jahre zuvor, nur dass statt der Tabellen-Tags Klassen wie „container“, „row“ und „col-x“ auf alles angewandt werden, was zu finden ist. Werden nun noch Typografie, Farben und Abstände durch CSS-Klassen definiert, erscheint die alte Tabellen-Variante beinahe schon wieder chic.

Fairerweise muss hier natürlich zwischen Hobby-Programmierern der Website eines oberbayerischen Kaninchenzucht-Vereins (Beispiele finden Sie hier) und professionellen Programmierern unterschieden werden. Gerade bei Zweiteren werden Templates in CMS-Systemen und Online-Shops über unterschiedliche Module, Plugins, Templates und Partials gesteuert.

In der Ausführung eines aufgepumten Bootstrap-Klassen-Markups bedeutet dies, in sämtlichen HTML-Files oder bereits in der Control-Ebene im MVC-Modell seine Klassen einzuschleusen, was häufig großen Aufwand verursacht.

Spätere Anpassungen, beispielsweise um die Abstände zwischen Modulen global zu erhöhen, hat zur Folge, dass sämtliche Modul-Templates einzeln editiert werden müssen, um beispielsweise ein „mt-5“ in ein „mt-6“ zu ändern.

Bei der Umsetzung eines Web-Templates liegt die Kunst des Programmierens gerade darin, Gemeinsamkeiten zu erkennen, globale Parameter, Sass-Mixins und Klassen zu erstellen. Ein Template sollte mit erklärenden Klassen versehen werden, welche über CSS gesteuert werden:

Die Klasse „content-module“ definiert (wie erwartet) die Darstellung eines Content-Moduls, nicht mehr und nicht weniger. Statt das Content-Modul im Markup zusätzlich mit „container“ und „rounded“, „border“, „mt-2“, „mt-4-md“ und „mt-5-lg“ zu vergewaltigen, sollten diese layoutspezifischen Einstellungen zur Darstellung global und allgemein im CSS festgehalten werden.

Nun kann beispielsweise mit der Anpassung eines einzelnen Wertes im CSS gleichermaßen allen Modulen ein größerer Abstand zueinander erteilt werden, wobei der HTML-Output reduziert, nachvollziehbar und übersichtlich bleibt.

Darin besteht vermutlich der Knackpunkt in der ganzen Geschichte. Mit purem CSS ist man beinahe chancenlos, wenn es darum geht, auch nur die vier Breakpoints einer einfachen „container“-Klasse nachzubilden. Deshalb kommt hier Sass zum Einsatz. Im obigen Beispiel der Klasse „content-module“ könnten die Eigenschaften der Klasse „container“ einfach wie im folgenden Beispiel angewandt werden. Egal welche dieser drei Varianten zum Einsatz kommt, das Endresultat ist 100 Prozent Bootstrap, ohne dabei einen sauberen Aufbau des Web-Templates zu verlieren.

Styles der Klasse "container" verwenden:

/* Variante a */
.content-module {
  @extent .container
} 

/* Varinte b */
.content-module {
  @include make-container;
  @include make-container-max-widths;
}

/* Varinte c */
%wrapper {
  @include make-container;
  @include make-container-max-widths;
}

.content-module {
  @extend %wrapper;
}

Wie bereits erwähnt, kann viel Zeit eingespart werden, wenn Module, Plugins und Themes seltener umgeschrieben werden müssen und sich die Leserlichkeit des Codes gleichzeitig um ein Vielfaches verbessert. Auch im Fall von Multidomain-Pages oder Landingpages, die sich zwar die selben Core-Dateien und Funktionen teilen, jedoch in einem anderen Gewand ausgegeben werden sollen, legt einem die Überschwemmung von Bootstrap-Klassen im HTML einige Steine in den Weg.

Sollte eine bestehende Website zukünftig eine Sidebar bekommen, worin ebenfalls die Klassen „content-module“ verwendet werden, könnten statt alternativer HTML-Templates lediglich einzelne Eigenschaften der Klasse „container“ unwirksam gemacht werden, um eventuell schon das gewünschte Ergebnis zu erhalten.

Haupteigenschaften der Klasse "container" entfernen:

.sidebar {
  .content-module {
    max-width: none;
    padding-right: 0;
    padding-left: 0;
  }
}

Ähnlich der Automatismen des Rettungs-Dienstes – Blutdruck messen, Puls messen – schießen Frontend-Programmier meist drauflos, erst mal eine „container“-Klasse und eine „row“-Klasse zu erstellen. Nachdem das Notwendigste erledigt wurde, kann nun im nächsten Schritt das weitere Vorgehen überlegt werden.

Gerade durch durch die Nutzung von Sass stehen hierbei ganz „neue“ Möglichkeiten zur Verfügung. Somit haben nachfolgende Beispiele ein identisches Ergebnis, wobei das erste Beispiel zunächst 3 Wrapper benötigt, das zweite Beispiel dagegen mit einem schlichten h1-Tag für die Überschrift auskommt. Die verwendeten Mixins und Variablen stehen dabei bereits allesamt in Bootstrap zur Verfügung.

Beispiel 1 - Blindes Bootstrap-Klassen-Gedudel:

<div class="container">
  <div class="row">
    <div class="col-12 col-sm-8 offset-sm-2">
      <h1>Title</h1>
    </div>
  </div>
</div>

Beispiel 2 - Alternativer Weg mit Sass:

<h1 class="title">Title</h1>

.title {
  @include make-container;

  @each $breakpoint, $container-max-width in $container-max-widths {
    @include media-breakpoint-up($breakpoint) {
      max-width: $container-max-width / $grid-columns * 8;
    }
  }
}

Bootstrap ist ein feines Tool zur Erstellung responsiver Websites und bietet viel Unterstützung. Natürlich macht es in einzelnen Fällen auch durchaus Sinn, Klassen dieses Frameworks zu nutzen, gerade wenn beispielsweise Grids über ein CMS im Backend definiert werden können. Aber, bitte, liebe Frontend-Programmierer:

Bevor ihr alles, was keucht und fleucht, mit heillosem Bootstrap-Klassen-Gewirr vollstopft, fangt an nachzudenken, um Templates wieder leserlich und in ordentlicher Semantik zu erstellen!

Danke!

Der Rückschritt von Frontend-Programmierung

Der Tod für modulare Templates

Schlüssige Benennung von Klassen

Sass: der beste Freund des Menschen

Warum das Ganze?

Nachdenken statt Spalten zählen!

Fazit