Mittwoch,
04. April 2007

Gerade habe ich in die Kommentare zu Gerrits Rezension meines Buches - für die ich mich hiermit herzlich bedanken möchte - geschaut und dabei ein Thema entdeckt, dem ich mich in der Vergangenheit immer wieder stellen musste, bisher jedoch keinen Blogbeitrag dazu verfasst hatte.

Stein des Anstoßes in allen Diskussionen dieser Art, die ich bisher miterleben durfte, ist die “große” Anzahl von vordefinierten DIV-Containern innerhalb der Quelltextstruktur von YAML. Die Kritik bezieht sich dabei in erster Linie auf die Schachtelungstiefe der Container bis zum eigentlichen Inhalt. Gleiches ist auch für die Grids von Yahoo zu vermuten. Ich möchte hier nicht die Quelltexte auseinander nehmen. Wer die Projekte nicht kennt, für den stehen die jeweiligen Online-Dokumentationen (Grids & YAML) bereit. Stattdessen möchte ich einige, ggf. kontroverse Thesen in den Raum werfen, um die Diskussion anzuregen.

Es stellt sich die Frage: Steht ein XHMTL/CSS-Framework (wie YAML oder Yahoo Grids) ernsthaft in Konkurrenz zu dem Ziel, schlanken Code zu erzeugen?

Das Ziel eines Layout-Frameworks liegt meines Erachtens darin, ein voll funktionsfähiges Layout zu liefern indem die dafür erforderlichen Strukturen unabhängig von den späteren Inhalten bereit gestellt werden. Speziell bei YAML bedeutet dies erstens, dem Nutzer alle Freiheiten bei der Wahl fixer oder flexibler Layouts bzw. Spaltenbreiten zu lassen. Zweitens soll auch ein entsprechender Komfort geboten werden, weshalb oft benötigte Elemente vordefiniert sind bzw. gestalterische Erfordernisse in der Struktur berücksichtigt werden.

Das Ergebnis ist eine Quelltext-Struktur, die sich bei bekannten Randbedingungen (z.B. einem fixen Layout) relativ problemlos um zwei bis drei der fünf DIV-Ebenen reduzieren lässt. Allerdings sind bei dieser Optimierung bereits gute CSS-Kenntnisse (und Sicherheit im Umgang mit CSS-Bugs) erforderlich, um auch die von YAML gebotene browserübergreifende Kompatibilität weiterhin aufrecht zu erhalten, was für erfahrene Webdesigner kein Problem darstellen sollte. Soll hingegen ein flexibles Layout umgesetzt werden, schrumpft diese Potential sehr schnell auf annähernd Null zusammen.

Nun sind fixe Layouts heute die Regel. Dagegen bilden wirklich konsequent aufgebaute flexible Strukturen bisher die Ausnahme, obwohl sie für den Nutzer mit zahlreichen Vorteilen verbunden sind. Die Gründe hierfür sind vielfältig und sollen an dieser Stelle nicht diskutiert werden, das würde vom Thema ablenken.

Schauen wir vielmehr, ob sich das eben angedeutete Optimierungspotentail bei einem fixen Layout in Zahlen ausdrücken lässt. Bei Optimierung der YAML-Quelltextstruktur ließen sich in diesem speziellen Fall drei DIV-Ebenen einsparen (die beiden äußeren Ebenen sowie jeweils ein DIV der verschachtelten Content-Container), macht insgesamt 5 DIV’s (<div>...</div> ). In einem greifbaren Maß ausgedrückt sind das etwa 60 Byte, über die wir im Optimalfall reden müssten. Ist das jetzt viel oder wenig?

Dazu ein Blick über den Tellerrand. Das Ajax-Framework jQuery zählt zu den schlanken Vertretern seiner Zunft und misst in der komprimierten Fassung der aktuellen Version schlanke 19kb. Auch der Funktionsumfang von jQuery ist um ein vielfaches größer als das, was letztlich an Funktionen innerhalb einer Webseite eingesetzt wird. In den meisten Fällen beschränkt sich das auf ein zwei grafische Effekte. Doch egal wie viel oder wenig man davon benötigt, jQuery muss im Browser vollständig geladen werden. Bei diesen Anwendungen werden Dateigrößen weitgehend diskussionslos hingenommen. Sicherlich hat jeder User die Auswahl aus einer Vielzahl von Ajax-Frameworks aber gegenüber den oben erwähnten 60 Bytes, schleppen wir hier bereitwillig den Faktor 400 und mehr mit, nur um unserer Webseite ein wenig Web2.0 Feeling durch ausklappende Container einzuhauchen.

Wie sieht es beim Grafikeinsatz aus? Ohne grafische Elemente kommt heutzutage keine Webseite mehr aus. Der Grafikumfang einer üblichen Webseite erreicht schnell den Wert von 50kb und mehr. Auch hier steckt - für einen fähigen Grafiker - Optimierungspotential im ein- bis zweistelligen Kilobyte-Bereich. Nur macht sich kaum jemand die Mühe, alles bis auf’s letzte Byte auszureizen. Und dennoch, schon bei fiktiven 6kb - Einspaarpotential haben wir auch hier den Faktor 100 gegenüber der Quelltext-Optimierung ereicht.

Für mich stellt sich aus diesen Beispielen die Frage nach der Verhältnismäßigkeit, der oben genannten Kritik an aktuellen XHTML/CSS-Frameworks. Schlanker Quellcode ist gut und wichtig, semantisch korrekte Auszeichnung der Inhalte gehört selbstverständlich dazu. In der Strukturbildung ist der Seitenersteller jedoch bei (X)HTML frei und eine auf universellen Einsatz getrimmte Struktur wie YAML oder Grids sie bieten, ist weder automatisch schlechter zu bewerten, noch ist es eine DIV-Suppe, wie HTML-Puristen immer wieder gerne als Schlagwort einwerfen. Es sind in Abhängigkeit vom jeweils umgesetzten Layout unter Umständen ein paar Bytes mehr als unbedingt nötig. Für den Seitenersteller bieten Frameworks als Gegenwert wieder verwendbare Strukturen für unterschiedliche Einsatzzwecke. Der Besucher einer Webseite wird diese 60 Byte auch mit einem 56k-Modem nicht spüren.

Fazit: Das Ziel von YAML und Grids ist die Schaffung universeller Strukturen. Dafür ein paar Byte in die Waagschale zu werfen, halte ich nicht für “unelegant” sondern für vorausschauend. Der Nutzer spürt eine Optimierung einer Webseite in erster Linie an den Ladezeiten und der Einfluss der Quelltextstruktur der beiden Frameworks an diesem Byte-Kuchen ist nahezu verschwindend gering. XHTML/CSS-Frameworks wie YAML oder Grids von Yahoo stellen damit keinen Widerspruch zu schlanken Webseiten dar, die es letztlich zu erstellen gilt.


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.