F-LOG-GE

Sinn eines CSS-Frameworks

Ich habe vor Kurzem meinen aktuellen Arbeitsworkflow beschrieben. Dabei habe ich auch erwähnt, daß ich mich in der Frontendentwicklung auf zwei Frameworks verlasse: YAML für HTML und CSS sowie jQuery für Javascript. Da meine Arbeit sich auf die Erstellung von Frontendcode konzentriert und ich weder ein CMS direkt befeuere noch die Templates erstelle, muss ich mir keine Gedanken über ein CMS oder ein PHP-Framework machen.

Seit Jahren werbe ich immer wieder für die Nutzung von YAML. Nicht, weil ich dafür Geld bekäm, sondern weil ich die Nutzung eines Frameworks für sinnvoll erachte und YAML für das Beste der derzeit existierenden halte. YAML wird dabei immer wieder vorgeworfen, es sei so "schwer" und habe einen zu komplexen Code. Abwechselnd wird von DIVitis oder DIV-Wahnsinn gesprochen. Ihre dauernde Wiederholung macht allerdings diese Behauptungen nicht wahrer. Die Kritiken zeugen in meinen Augen davon, daß das Konzept von YAML nicht verstanden wurde. YAML bietet von Anfang an erst einmal alles. Der Trick besteht darin, das Unnötige wegzunehmen. So gehe ich auch in meinem Entwicklungsframework vor. Ich kann gut verstehen, daß das gewöhnungsbedürftig ist. Die Alternative wäre, eine ganz grobe Vorlage zu haben, in die man dann die benötigten Einzelteile einfügt. Das liefert mir prinzipiell jeder gute Editor, dafür brauche ich kein Framework. Zudem benötige ich einen Ort und eine Ordnungsmethode, um meine hinzuzufügednen Einzelteile zu finden und dann in meine neu entstehende Webseite einzufügen. Auch in diesem Falle benötige ich eine Art Framework-Grundlage. Ich bevorzuge, alle wichtigen Dateien und Skripte an einem Platz zu haben, so daß ich sie jederzeit anwenden kann, und die unnötigen am Ende schnell zu löschen.

Dirk Jesse schachelt bei YAML alle Layoutcontainer doppelt. Ich denke, es ist dieser Umstand, den viele kritisieren. Doch hinter der Verschachtelung steckt Sinn. Dirk entwickelt YAML immer mit dem Gedanken an flexible Layouts im Hinterkopf. Wenn man dementsprechend einem Container eine Breite in Prozent gibt, kann man ihm schwerlich ein Padding in Pixeln oder em geben. Schachtelt man nun einen Container in den Äußeren, dann gibt der Äußere die Breite vor und der Innere erzeugt über Padding oder Margin Abstände für die dann folgenden Inhalte. Natürlich kann ich auch den inneren Inhalten diese Abstände zuweisen. Doch das bedeutet mehr Schreibarbeit, schlechtere Wartbarkeit und weniger Flexibilität. Über die Verschachtelung ist sichergestellt, daß die Inhalte auf alle Fälle die korrekten Abstände bekommen. Zudem ist es egal, welche Inhalte in den inneren Container geschachtelt werden, sie bekommen immer den richtigen Abstand.

Die meisten Entwickler werden hingegen fixe Layouts mit Pixelbreiten erschaffen. Bei einem fixen Layout wird der innere Container nicht mehr zwangsweise für die Abstände benötigt. In diesem Falle kann man die inneren Container löschen. Das gilt für die Spaltencontainer #col1, #col2 und #col3 genauso wie für die diversen Subcolumns, also die Gridbausteine. Ohne die inneren Container kann man nicht mehr ernsthaft von DIVitits sprechen. Eine Lösung hingegen, in der ich Einheiten für Breiten und Abstände mische, kann ich schwerlich ohne zusätzliche Container lösen. Ich beglückwünsche jeden, der es dennoch geschafft hat. Ich wüßte dann aber auch gerne, ob die Lösung allgemein funktioniert, komplexe Layouts zuläßt und wie lange es gedauert hat, bis man auf sie kam.

Man kann also unter bestimmten Umständen die Struktur straffen. Andere Umstände erfordern hingegen diese verschachtelte Struktur. Denn abseits des Falles eines flexiblen Layouts gibt es genügend Gestaltungsideen, die einen zusätzlichen Container erfordern. Es dürfte schwerlich möglich sein, den Kunden zu erklären, man könne jetzt bedauerlicherweise sein Wunschlayout nicht erstellen, weil man dafür einen semantisch unnötigen Container einfügen müsse.

Ich denke, die Struktur können wir als nicht zu sehr aufgeblasen abhaken. Wie steht es nun mit dem CSS? YAML benötigt zwei Dateien, um zu funktionieren. Jede weitere Datei gehört zum individuellen Layout. Die slim_base.css hat 2,34 KB und hält damit für ziemlich viele Problemfälle Lösungen parat. Wer will, kann sich die Datei noch um die wenigen Einträge kürzen, die er definitv nicht benötigt wird. Man sollte dabei aber wissen was man tut. Angesichts der geringen Dateigröße halte ich eine solche händische Straffung allerdings für albern. Alle IE bis einschließlich Version 7 müssen 5 KB CSS-Dateien laden, da für sie ein separates Patchfile hinzukommt. (Siehe Dirks Artikel über YAML 3.2.)

Ich kann beim besten Willen an diesen Werten nichts Schlimmes entdecken. Die genannten Dateien sind eine Sammlung von Best Practices, an denen man schwerlich vorbeikommen wird. Es ist natürlich etwas Anderes, wenn man solche CSS-Dateien selber zusammensucht. Doch wird dies kaum über einen kurzen Zeitraum geschehen. Man wird seine selbst zusammengestellten Best Practices also nicht zwangsweise besser kennen, als man die YAML-Dateien kennen kann, wenn man sich einmal mit ihnen beschäftigt hat. In meinen Augen unterscheidet sich YAML von den anderen Frameworks dadurch, daß es auf Anwender setzt, die sich mit dem Code auseinandersetzen wollen und können. Es ist nicht einfach nur zum Anwenden da, wie die diversen Grid-Frameworks. YAML will erkundet, erforscht, erobert werden.

Wer sich also mit dem System beschäftigt, wird schnell die Vorteile erkennen. Ich habe mein gesamtes bisheriges Berufsleben meinen eigenen Code geschrieben. Bei meinem letzten Großprojekt für SinnerSchrader habe ich sogar ein eigenes kleines CSS-Framework geschrieben, das uns die Arbeit sehr erleichterte. Dieses war allerdings auf den Nutzungskontext zugeschnitten. Ich genieße es derzeit, daß mir YAML alle Gedanken um das Grundlayout abnimmt und ich mich um die eigentlichen Problemfälle der Entwürfe kümmern kann, von denen es noch genügend gibt.

Die Nutzung eines Frameworks hat für mich im wesentlichen folgende Vorteile:

Die Sorge um unnötige DIV-Container finde ich zudem übertrieben. Ich habe eher den Eindruck, es ist ein vorgeschobenes Argument. Und es wird schwer, solche unnötigen Container immer und überall zu identifizieren. Semantisch sind sicherlich sehr viele DIV-Container sinnlos. Sie machen semantisch da Sinn, wo sie eine Webseite in Bereiche unterteilen. Doch leider ist die Frontendentwicklung kein idealer Ort und wir können Layouts nicht der reinen Lehre nach nur mit CSS-Mitteln bewerkstelligen. Wir benötigen immer wieder zusätzliche DIV-Container, um Layouts zu erreichen. Das kann man kritisieren, outet sich dann aber in meinen Augen als Förderer schlichter Textwüsten.

Viele Seiten sind zudem keine simplen Bloglayouts oder einfache Seiten, die von einer Person für eine andere erstellt werden. Große Seiten werden von einem Redaktionsteam betreut, bekommen Daten von aussen angeliefert, bekommen oft Werbung von aussen eingebunden und sollen vielleicht sogar ein flexibel anpassbares Design haben. Wer all dies bewerkstelligen muss, der ist über das eine oder andere zusätzliche DIV sehr froh, das ihm die Arbeit sehr erleichtert. Die zusätzlichen 11 Byte tun weder dem Entwickler, noch dem Nutzer weh.

In Deutschland haben immer mehr Auftraggeber den zeit- und geldsparenden Effekt von Frameworks begriffen und fragen konkret nach einer Umsetzung mit YAML nach. Das hat für sie den großen Vorteil, daß sie den Frontendcode von anderen Entwicklern einfacher warten lassen können, wenn sie es aus welchen Gründen auch immer wollen. Ich sehe derzeit keine Veranlassung, wieder zu meinen alten Methoden zurückzukehren und meinen Code komplett selber zu schreiben.

Dies ist ein Archiv meines alten Weblogs, das von Oktober 2006 bis Dezember 2022 als Wordpress-Instanz existierte.