High Resolution Weblog

Einen etwas ausführlicheren Beitrag zu effizientem Code (HTML & CSS) habe ich mir schon lange vorgenommen – dieser hier ist es noch nicht. Dennoch hat mich diese kürzlich erschienene Evaluation der vier bekanntesten CSS-Frameworks zu diesem Beitrag bewogen. YAML ist wohl mit Abstand das komplexeste Framework unter den genannten und bedingt aufgrund seiner Ausrichtung (flexible Layouts) sowie der Vielzahl an Möglichkeiten, Dateien und Beispiele auch eine steilere Lernkurve. Schnell kann dabei der Eindruck entstehen, dass die Komplexität (und die umfangreiche Browserunterstützung) zu einem überbordenden Umfang des Frameworks führen. Also gehe ich dieser These hier mit einem kleinen Vergleich mal auf den Grund und verleiche das CSS-Volumen der Framework-Cores.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

• YAML 3.2 (aktuelle Entwickerversion Beta 3)
• YAML 3.1
• YUI 3.0 beta1
• 960 grid system
• Blueprint CSS 0.9

Eine weitere Differenzierung betrifft die Handhabung von Browserinkompatibilitäten und dem Umgang mit den daraus resultierenden CSS-Hacks, um diese zu fixen oder zu umgehen. Hier gibt es verschiedene Herangehensweisen, auf die ich in meinem Essay “Was Sie über CSS-Frameworks wissen wollten!” im Detail eingegangen bin. Speziell ist hier das Thema: Auslagerung der Hacks über Conditional Comments gemeint. Ich werde deshalb die Frameworks-Cores hinsichtlich zweier Sichtweisen untersuchen:

Crossbrowser-Core

Der Crossbrowser Core beschreibt Umfang an CSS-Code, der notwendig ist, um alle alle aktuell relevanten Browserversionen zu unterstützen: Internet Explorer 6.0+, Firefox, Safari, Opera

Modern-Browser-Core

Der Modern Browser Core beschreibt Umfang an CSS-Code, der notwendig ist (bzw. im Browser geladen wird), um die aktuelle Browsergeneration zu unterstützen, welche durchweg standardkonform arbeitet: Internet Explorer 8.0, Firefox, Safari, Opera

Bevor es mit Zahlen losgeht, folgt noch die Einteilung, welche Bestandteile des jeweiligen Frameworks zum Core gehören. Bei YAML sind dies die Dateien base.css, iehacks.css und die print_base.css* (nur bis YAML 3.1 vorhanden). Bei Blueprint CSS ist es die Dateien reset.css, grids.css und ie.css, bei 960.gs besteht der Core aus reset.css und 960.css und bei YUI sind es die Komponenten reset.css, grids.css und fonts.css. Die fonts.css rechne ich in diesem Fall bei YUI bewusst dazu, da das YUI-Reset den Browser in einem derart egalisierten Zustand hinterlässt, dass die Darstellung im Browser ohne diesen Baustein keinerlei Strukturierung der Inhalte mehr erkennbar ist.

Erkennbar ist an dieser Auflistung bereits, dass alle aufgeführten Frameworks modular arbeiten und sich der Core aus 2 bis 4 Modulen zusammensetzt. Bis auf Blueprint CSS werden bei allen Projekten dateigrößenoptimierte Dateifassungen für den Livebetrieb bereitgestellt, in denen Kommentare und unnötige Whitespaces entfernt wurden. Diese Fassungen nehme ich als Grundlage für den Vergleich. Die Dateien des Blueprint-Frameworks wurden dafür im CSS Compressor mit maximalen Einstellungen komprimiert.

Unter diesen Randbedingungen sollte trotz unterschiedlicher Funktionalität und Arbeitsweise der Frameworks eine Vergleichbarkeit gegeben sein, da ausschließlich die Framework-Cores in ihren Dateigrößen unter Produktivbedingungen verglichen werden und somit als einzige Bedingung die grundsätzliche Funktionalität des Cores gegeben sein muss.

Die Ergebnisse in der Übersicht

Crossbrowser Cores - Support für IE 6.0+, Firefox, Safari, Opera

Gesamtvolumen

Aufgesplittet in Einzelmodule

Modern Browser Cores - Support für IE 8.0, Firefox, Safari, Opera

Gesamtvolumen

Aufgesplittet in Einzelmodule

Diskussion

Die Diagramme sprechen eine klare – und in dieser Klarheit selbst für mich überraschende – Sprache. Obwohl YAML von vielen Nutzern aufgrund der vielfältigen Möglichkeiten (und vielleicht auch der umfangreichen Dokumentation) als sehr komplexes Werk wahrgenommen wird, so beinhaltet es doch mit 5.753 Bytes für YAML 3.1 unter den vier vorgestellten Frameworks den kleinsten Crossbrowser-Core. Die Entwicklerfassung von YAML 3.2 ist zwar noch etwas schlanker, aber auch noch nicht veröffentlicht.

Noch deutlicher wird der Unterschied zwischen den verschiedenen Frameworks, wenn man sich die Zahlen für den Modern-Browser-Core ansieht. Hier zeigen YAML und Blueprint-CSS wie effektiv die konsequente Abtrennung der Browser-Hacks vom regulären CSS ist und wie sich dieser Effekt in modernen Browsern auswirkt. In modernen Browsern braucht YAML 3.2 gerade einmal 2,4 kB (und damit unter 50% des Crossbrowser-Cores) für die Bereitstellung der Layoutfunktionalität, auch bei Blueprint-CSS werden ca. 2 kB gespart, während die Vermischung von regulärem CSS und Hacks bei YUI und 960.gs dazu führt, dass der Code zur Altlastenbehebung auch in der modernsten Browsergeneration als unnötiger Ballast mitgeschleift werden muss, solange IE 6 und IE7 unterstützt werden müssen.

Und letztlich lässt sich aus den gesplitteten Zahlen ein weiterer Trend ableiten. Die CSS-Formulierungen für pixelgenaue Grids sind offensichtlich umfangreich und wachsen mit der Feinheit des Grids. Die Definition des 12- und 16-Spalten-Grids bei 960.gs benötigen ca. 5300 Byte, während bei 24-Spalten-Grid von Blueprint CSS schon 7000 Byte erforderlich sind. Natürlich gibt es auch hier Unterschiede in der Funktionalität, dennoch ist es bemerkenswert, dass YAML mit seinen flexiblen Grids offensichtlich deutlich effizienteren CSS-Code ermöglicht.

Fazit

Was lässt sich nun daraus ableiten? Mit Sicherheit lässt sich aus diesen Zahlen nicht pauschal sagen, welches der Projekte ein “gutes” oder ein “schlechtes” CSS-Framework ist. Um diesen Vergleich zu führen müsste man projektabhängig eine 100-prozentige Handcodierung gegenüberstellen und vergleichen, welcher Anteil des CSS-Volumens bei Handkodierung auf Layout und Crossbrowser-Konformität verwandt wird.

Eine generelle Aussage lässt sich aber dann doch treffen. Vergleicht man nämlich diese Zahlen mit dem CSS-Volumen realer Webseiten, so wird man feststellen, dass angefangen mit einfachen Bloglayouts (10-15 kB CSS) über umfangreicher gestaltete Seiten (30-50 kB CSS) bis hin zu großen Portalen (70-100 kB CSS) der Anteil eines evlt. eingesetzten Frameworks in Bezug auf das CSS-Volumen immer geringer wird. Und damit möchte ich dieses kleine Zahlenspiel beenden und bin gespannt auf die Diskussion.