High Resolution Weblog

Vor 10 Jahren was CSS gerade mal dazu gut, Schrift- und Hintergrundfarbe von Texten festzulegen. Heute können wir dank CSS3 Transitions, Transforms und Animationen in allen modernen Browsern problemlos eine Horde gescheckter Kühe geschmeidig animiert (weil hardware-beschleunigt) über die Pixelweide treiben.

Was wir aber nicht können, sind vermeintlich simple Layoutaufgaben ohne abstruse CSS-Tricksereien realisieren. Schon vor einer kleinen Weile schlug Louis Lazaris mit seinem Blogbeitrag “CSS: The Bad Parts” in eine ähnliche Kerbe, wobei ich nur zum Teil die von ihm angesprochenen “Probleme” als solche wahrnehme.

Die Sache mit den Floats

Über den Sinn und Zweck von Floats lässt sich trefflich streiten. Vor 5..6 Jahren waren sie der Heilsbringer, der die CSS-Layouts dahin geführt hat, sich über den Layouttabellenschmarn des letzten Jahrhunderts zu erheben. Und in einem Umfeld, in dem überwiegend pixelexakte Layouts propagiert wurden, funktioniert dieser Ansatz auch leidlich. Nun hört man in den letzten Jahren – anfangs nur von Standards-Fetischisten – heute auch aus der breiten Frontendler-Masse, Floats wären ja laut Standard nie für Gestaltungsaufgaben vorgesehen gewesen und würden demzufolge für Layoutzwecke genauso missbraucht, wie seinerzeit die HTML-Tabellen.

Nun, diese Argumentation mag für Verschwörungstheoretiker brauchbar sein, für mehr aber auch nicht. Viel schwerwiegender ist doch die Erkenntnis, dass sich Floats trotz aller Widrigkeiten im Detail der Spezifikation durchgesetzt haben und wir monentan gar keine Alternativen dazu haben. Und damit bin ich wieder beim Aufhänger für diesen Blogpost. CSS 3 hat in den letzten 2 Jahren eine rasante Entwicklung hinter sich und vom Gefühl her beschleunigt diese Entwicklung noch immer. Nur passiert der technische Fortschritt auf ganz anderen Bereichen: Runde Ecken, Gradients, Schatten, Animationen, 3D, Schriften usw. usw.

All die neu hinzugekommenden CSS3 Features will man aber nun auch einsetzen und damit werden viele der Probleme, die es mit Floats gibt, erst jetzt mit Nachdruck sichbar. Umso unbefriedigender ist die Tatsache, dass mit CSS3 bisher kaum brauchbare Layoutkonzepte in die Standardisierung – geschweigedenn in die Praxis – Einzug gehalten haben.

Kein Float-Clearing ohne Nebenwirkungen

Wer bis heute der Meinung ist, die Clearing-Problematik wäre mit der Erfindung des Clearfix-Hacks gelöst, der führt zum einen ein offenbar gut behütetes Entwicklerleben und irrt zum anderen gewaltig. Schauen wir auf die aktuellen Webdesign-Trends: Responsive Webdesigns, flexible Grids und CSS3 Box-Shadows.

• Der Clearfix-Hack hat das Ärgernis beseitigt, für das Clearing der Floats zusätzliche Elemente ins Markup stopfen zu müssen. Er hat aber schon immer das Problem, Auswirkungen auf die Positionierung anderer floatender Elemente im gleichen Kontext zu haben, was seinen Einsatzzweck zum Einschließen von Floats stark einschränkt.
• Die Eigenschaft overflow:hidden schien zur Hochzeit von CSS2 nahezu nebenwirkungsfrei zum Einschließen von Floats. Mit der Praxistauglichkeit von CSS3 ist dieser Status dahin, denn CSS-Schatten von Child-Elementen werden an den Elementrändern gnadenlos abgeschnitten.
• Die Eigenschaft display:table scheint auf den ersten Blick die Nachteile von overflow:hidden mit CSS3 ausgleichen zu können, denn es wird nichts abgeschnitten. Dafür ist die Implementation in den Browsern uneinheitlich, was schon damit beginnt, wie sich ein Element mit dieser Eigenschaft hinsichtlich seiner Breite verhält. Dazu kommt ein noch tiefer liegendes Problem, welches nicht immer sofort sichtbar wird. Die Eigenschaft display:table hebelt eines der grundlegenden Rendering-Prinzipien von CSS aus, dass ein Elterncontainer nicht mit der Breite seines Kind-Elementes mitwächst. Sichtbar wird dieses Verhalten, wenn man beispielsweise flexible Grids damit baut und linearisiert, ohne den einzelnen “Zellen” eine Breite zuzuweisen (wozu auch, Blockelemente dehnen sich von allein auf die Größe des Elternelementes aus). Fügt man in ein solches CSS-Konstrukt allerdings ein flexibles Bild ein, wird dieses plötzlich nicht mehr skaliert dargestellt, sondern in voller Größe und die Elterncontainer werden entsprechend ausgedehnt – genauso wie bei Tabellen. Dieses Problem ist bisher kaum bekannt. Aber ihr könnt mir glauben, es ist extrem mühsam, die eigentliche Ursache beim Debugging überhaupt zu erkennen.

Mit dem Durchbruch flexibler Layouts unter dem Deckmantel des Buzzwords “Responsive Design” werden weitere Probleme sichtbar. Wir sind bei CSS weit davon entfernt, Elemente unabhängig vom Markup im Screendesign anordnen zu können. Zahlreiche Entwickler bemerken erst jetzt bei der Umstellung von fixen Grid-Systemen auf Grids in Prozentwerten, was es heisst, mit Rundungsfehlern der Browser offensiv umzugehen. Und und und ...

Fehlende Alternativen

Tja, was gibt’s hier? Der eine oder andere weiß sicher, dass einige CSS-Frameworks (z.B.: die Grid-Komponente von YUI3) auf display:inline-block aufbauen. Auch diese Eigenschaft ist keine Lösung, denn sie wurde noch viel weniger für Layoutzwecke entworfen als Floats. Das äußert sich insbesondere darin, dass ein Grid mit diesem CSS-Konzept plötzlich höchst sensibel auf Leerzeichen und Zeilenumbrüche im Quelltext zwischen den einzelnen Grid-Zellen reagiert. Es braucht nicht viel Phantasie, um sich die Probleme vorzustellen, wenn man als Entwickler keine vollständige Kontrolle über den Quellcode hat. Und wer hat die schon? Denkt nur an verschachtelte Templates in einem CMS und die dadurch entstehenden Zeilenumbrüche im Quelltext.

CSS3 verspricht uns gleich vier neue Layout-Module: Multicolumn, Grid-Layout, Flex-Box und das Template-Modul. Das Multicolumn-Modul ist als einziges bereits beim Status “Testing” angekommen allerdings lässt es sich im Grunde nur auf Fließtext sinnvoll anwenden. Für den Bau eines Seitenlayouts im herkömmlichen Sinne ist es ungeeignet. Die anderen drei pendeln zwischen “Revising” und “Exploring”, d.h. ihre Anwendbarkeit liegt in weiter Ferne. Erschwerend kommt hinzu, dass der visuelle Seitenaufbau ein so grundlegender Baustein ist, dass sich hier kaum sinnvolle Progressive-Enhancement-Strategien realisieren lassen. Entweder die gesamte relevante Browserlandschaft unterstützt die Technik fehlerfrei oder sie ist für den Alltag noch nicht reif. Sprich: Wir lesen uns 2016 wieder.

Während wir mittlerweile selbst auf Smartphones gut und gerne 50 animierte Kühe per CSS fliegen lassen können, mühen wir uns bei den grundlegenden Gestaltungswerkzeugen im Web auch in den nächsten Jahren noch mit unzureichenden Techniken ab. Und es verblüfft mich schon ein wenig, dass wir uns so bereitwillig von all dem HTML5- und CSS3-Bling Bling blenden lassen.

Nachtrag: Für die Zweifler unter Euch: Zwar keine fliegenden Kühe, dafür nicht minder knuffige, fliegende Schweine. (gefunden und mir zugetragen von Christian Heilmann).