Zentrale Frage:
Wie kann man aus 222tsd Zeilen CSS möglichst viel ‚Clutter‘ herausschneiden, ohne die damit definierte Template-Anzeige auf verschiedenen Devices zu limitieren?
Der 2011 erstmalig vorgestellte Static-Site-Generator Hugo ist inzwischen in Webkreisen ziemlich populär (Link). Auf der offiziellen Theme-Seite des Projekts wird auch das
Tokiwa-Template von He Yeshuang vorgestellt bzw. zum Download angeboten.
Das Template wird im Begleittext vorgestellt als „A minimal blog theme inspired by the color tokiwa-iro“. Diese Farbe wiederum bezeichnet im Japanischen das dunkle Grün immergrüner Bäume, wie Zeder oder Pinie. Zusammenhängend ausgesprochen ‚Tokiwairo‘ erhielt es in der Edo-Periode, der Zeit der japanischen Shogun von 1603-1868, die Zuschreibung „as a good luck color, and as a color that celebrates the ever-changing green, it is also said to be a color that symbolizes the wish for permanence, longevity, and prosperity.“(Link). Die Farbe selbst ist im Web, etwas prosaischer, als „Bottle Green ~ #1f9967“ kodifiziert.
Mein Anlass für diesen Post ist die initiale Bezeichnung des Templates, nämlich als „minimal blog theme“, bei der mich zuerst die wirklich sagenhaft gute Typografie angesprochen hat. Aber sie kommt zu einem Preis. Denn die Autoren möchten das Template für lateinische wie chinesische Schriftzeichen optimieren und im Zuge dessen ist die CSS-Datei der Vorlage unglaubliche 222.497 Zeilen aufgeblasen worden.
Und das Problem dabei ist, dass man diese Monster-Datei nicht einfach, wahrscheinlich gar nicht, auf eine vernünftige Größe zurückführen kann. Dafür sorgt zunächst die Kaskadierung von CSS – man kann nie wissen, in welchen Beziehungen zu anderen Styles und HTML-Elementen eine CSS-Anweisung steht. Weiter wird CSS auch immer funktionaler, also komplexer, da es mit Berechnungen und Abfragen hinsichtlich flexiben Layouts stetig weiter entwickelt wird. Tokiwa setzt dabei auf den CSS-Frame Tailwind , dessen Entwickler, Adam Wathan, hier seine Ideen bezüglich guter CSS-Architektur beschreibt.
Reduktion in Kollaboration
Gerne würde ich diesen Prozess – also wie man ‚Look & Feel‘ des Templates erhalten kann, aber die CSS-Datei auf eine ebenfalls minimales Maß herunterschraubt – als Gemeinschaftsprojekt verwirklichen. Dazu müsste das Projekt in den entsprechenden Foren und wahrscheinlich auch auf Englisch vorgestellt werden. Und natürlich sollte man den/die Autor/in des Ganzen, He Yeshuang dafür kontaktieren. Was aber nicht möglich ist, weil alle Quellen dazu ins Nichts laufen. Es ist ein sagenhaft elaboriertes Theme, das von einem Anonymous hergestellt wurde. Damit ist auch absolut nicht klar, wie der Produktionscode des Templates aussieht, was da eigentlich „unter der Haube“ geschieht.
Julian denkt über die CSS-Schlacht des Template Tokiwa nach:
Julian Reisenberger hat als textpattern-Experte freundlicherweise meine Webseite neu aufgestellt. Er schreibt jetzt zum CSS des Templates bzw. antwortet auf meine Gedanken:
Das ist natürlich unglaublich … ja eigentlich unverantwortlich, 4,5 MB an CSS-Anweisungen durch die Leitung zu schicken. Die Noto Webfonts mit den chinesischen Schriftzeichen sind weitere 2+ MB pro Schriftschnitt!! Mein Browser sagt, dass die Markdown-Beispielseite auf der Homepage 8 MB schwer ist. Dein Artikel dazu (sc: also das, was Sie gerade lesen) ist mit Textpattern 306 KB, also ~40-mal kleiner.
Dabei ist der Quellcode der Tokiwa Styles gar nicht so riesig: 7kb + 5kb für die Reset-Styles. Der Rest ist Tailwind. Üblicherweise wird man die Styles, die auf der Homepage nicht zur Verwendung kommen, mittels PurgeCSS o.ä. daraus löschen, aber der Autor hat das unterbunden. Vielleicht gibt es einen Grund dafür, vielleicht hat er/sie es nur vergessen? Bei solchen Static-Site-Generatoren wie Hugo, die auf Flat-Files basieren, ist dieser Schritt denkbar, weil das System die Inhalte der Homepage kennt – sie liegen ja als Dateien vor und beim Generieren der HTML-Seiten kann das System merken, welche Classes usw. verwendet werden. Ich denke, das ist die vielversprechendste Ansatz, wenn das Theme wie vorhanden weiter auf Basis von Tailwind basieren soll.
Vielleicht ist es auch möglich, nur ausgewählte Teile von Tailwind einzubinden, quasi eine kleinere, granuläre Auswahl von Tailwind-Komponenten von Anfang an festzulegen. Ich kenne mich allerdings zu wenig damit aus. Ich vermute, es wird dennoch eine recht große CSS-Datei erzeugt.
Es gibt Tools um normale Webseiten in Tailwind zu konvertieren, aber in der umgekehrten Richtung – also Tailwind zu Vanilla CSS – kenne ich keine … wahrscheinlich, weil man Webseiten auf so unterschiedliche Weisen erstellen kann.
Wenn ich vor dieser Aufgabe stehen würde, würde ich – offen gesagt – die Homepage neu nachbauen bzw. ‘nachempfinden’. Zum einen ist der HTML-Code mit Tailwind Classes durchsäht, was das Erkennen der Grundstruktur erschwert. Wenn man nicht mehr mit Tailwind arbeiten will, muss man all die class-Attribute ausräumen. Ich würde dies durch „semantische“ (also Aufgabe-bezogene) Classnames ersetzen und dann mein CSS nach diesen semantischen Prinzipien wieder aufbauen. Mittlerweile kann CSS immer besser auf unterschiedliche Gerätegrößen reagieren, ohne dass man immer ein neues Layout pro Media-Query (Breakpoint) definieren muss. Media-Queries sind zwar immer noch nützlich, wenn grundlegende Layoutänderungen notwendig sind, aber man muss nicht mehr so viel festlegen wie vorher. Es wird auch, mit der heutigen Bandbreite an Gerätegrößen, immer schwerer festzulegen, welche Breakpoints man braucht. Leute wie Andy Bell & co gezeigt, dass bestimmte Layout-Prinzipien mit relativ geringen Mitteln zu erreichen sind.
Auch CSS-Variablen sind hier super hilfreich um Code zu sparen: früher müsste man pro Breakpoint, CSS-Anweisungen für jedes Element, das z.B. eine andere font-size bekommen soll, angeben; jetzt muss man nur einmal der Wert der Variable in ein Breakpoint ändern und es betrifft alle Stellen, wo die Variable eingesetzt ist.
Auch schreibst du, dass man nie wissen kann, in welchen Beziehungen HTML-Elementen und CSS-Styles zueinander stehen. Eine Reaktion darauf wäre, classnames zu verwenden, die möglichst eindeutig sind, sodass die Gefahr von Style-Clashes weniger gegeben ist (z.B. nach dem BEM-Prinzip, was sehr populär war und ist). Das kommt allerdings mit dem Nebeneffekt, dass man durch die Vermeidung von Überschneidungen auch die „Cascade“-Eigenschaft von CSS – also dass Styles aufeinander auswirken bzw. aufbauen – nicht wirklich ausnutzt, sondern versucht zu umgehen. Inzwischen sind Mittelwege gängiger, wo man eine Kombination aus strukturelle Classes, die aufeinander bauen, und dann sog. „utility“ oder “helper” classes (nicht unähnlich von Tailwind) nach Gebrauch hinzuzieht (z.B. wie bei der „CUBE“-Methodologie). Mit so einem Ansatz kommt man zu guten und flexiblen Ergebnissen mit weit weniger Code.