Donnerstag,
05. April 2012

Ein wenig überrascht war ich ja schon, ob der zahlreichen Reaktionen auf meinen Blogbeitrag “Von fliegenden Kühen und anderen Merkwürdigkeiten” und deshalb möchte ich mit diesem Folgebeitrag ein paar Dinge ergänzen, die mir aktuell in der aktuellen Weiterentwicklung von CSS fehlen, also die “missing parts” von CSS.

Nochmal zu Floats

Das Konzept, ein Layout zu beschreiben, indem man einzelnen Elementen eine Breite x zuweist und lediglich deren Ausrichtung links- oder rechtsbündig innerhalb des Elternelements bestimmt, ist keine Erfindung von CSS. Sowas gibt es schon sehr viel länger. Ich kenne ein solches System beispielsweise von der Erstellung von Benutzeroberflächen für den Amiga. Bei Software für dessen dessen Desktop-Oberfläche (Workbench) war schon in den 80er Jahren schlau, sich auf sehr unterschiedliche Bildschirmauflösungen und skalierbare Fonts einzustellen. Aus diesem Grund waren Floats für mich auch nie ein Mittel, welches allein zur Contentgestaltung herangezogen werden sollte. Wenn dem so wäre, hätte man im CSS Standard die Eigenschaft float auch einfach nur für das Image-Element definieren können. Dem ist aber nicht so.

Ich setze Floats seither sehr gern ein, weil ich sie mittlerweile in allen Browsern sehr robust geworden sind auch für die älteren Browsergenerationen gut dokumentierte, stabile Workarounds für die wichtigsten Bugs existieren. Nicht umsonst arbeiten die Layoutmodule von YAML mit Floats.

Dennoch wünsche ich mir eine Verbesserung der aktuellen Situation, denn auch wenn ich bisher fast jedes an mich herangetragene CSS-Problem lösen konnte, ist dies in – aus meiner Sicht zuvielen praxisrelevanten Standardaufgaben – nur mühsam zu erreichen. Als Beispiele wären da ...

Containing Floats

Wir benötigen eine Eigenschaft, die es ermöglicht, floatende Elemente durch den Elterncontainer sauber umschließen zu lassen. Aktuell nutzen wir dazu CSS-Eigenschaften wie overflow:hidden oder display:table, die diesen Effekt quasi als Nebenprodukt mitliefern. Da es uns in diesen Fällen aber gar nicht um das Verstecken übergroßer Elemente (overflow:hidden) oder das Rendern von Tabellen (display:table) geht, schleppen wir die Auswirkungen dieser Eigenschaften als störende Nebeneffekte zwangsläufig mit.

Was wir benötigen, damit Floats leichter handhabbar werden, ist CSS-Eigenschaft, die das Einschließen floatender Kind-Elemente zur Hauptaufgabe macht, wie z.B float:contain;. Die vom CSS-Standard dem am nächsten kommende Eigenschaft ist clear. Allerdings ist sie für Inhaltskonzepte konzipiert, weswegen ihre Wirkungsweise uns für Layoutzwecke solche Probleme bereitet und uns an diesem Punkt nicht weiterhilft.

Flexible Breiten & Source Order

Bei der Umsetzung flexibler (responsive) Layouts stößt man unweigerlich auf Probleme, wenn fixe und flexible Seitenbereiche nebeneinander zu platzieren sind. Wir platzieren sekundäre Inhalte typischerweise am Rand (Stichwort: Sidebar), neben den zentral gelegenen Hauptinhalten. Die Reihenfolge der Inhalte im Quelltext sollte die Relevanz natürlich widerspiegeln, womit auch hier erst der Hauptinhalt und dann die sekundären Infos folgen sollten. Diese Markupkonstellation stellt uns aber hinsichtlich des Layouts mit Floats vor ein konzeptionelles Problem, da laut CSS-Standard das Element, welches umflossen werden soll (hier bricht die inhaltsbezogene Ansatz von Floats im CSS-Standard durch), im Quelltext zwingend vor den Elementen, stehen muss, die es umfließen (man achte auf die aktive/passive Formulierung).

Das Problem sind hier nicht die Floats ansich, sondern dass wir kein Layout-Modul in CSS kennen, welches dieser Aufgabe gewachsen ist. Die Aufgabe besteht darin, die zur Verfügung stehende Gesamtbreite in einen Bereich mit definierter Breite (Maßeinheit em,% oder px) und einen flexiblen Rest zu unterteilen. Genau dieser flexible Rest ist in CSS nur für statische Elemente spezifiziert über width:auto. Auf positionierte (position:absolute|fixed) oder floatenden (float:left|right) Element lässt sich diese Breitenangabe aber nicht anwenden.

Deshalb ist es uns ohne Tricksereien nicht möglich, eine horizontale Zweiteilung durch zwei “gleichwertige” Layoutbausteine vorzunehmen. Wir greifen mangels Alternativen auf Floats zurück, wobei hierbei immer der Zwang besteht, dass das floatende Element im Quelltext vor den statischen Element stehen muss.

Natürlich ist es dennoch möglich, dieses Problem mit den aktuellen Bordmitteln zu lösen. Entsprechend Codebeispiele dafür habe ich in die Dokumentation des Spaltenmoduls von YAML aufgenommen (achtet auf die verschiedenen Layoutansätze für 2-Spalter). Das ganze geht zurück auf die cleveren Ansätze aus dem Beitrag “In Search of the Holy Grail” von A-List-Apart vom Januar 2006. Seither sind 6 Jahre vergangen, in denen sich CSS enorm weiterentwickelt hat. Dieses Grundproblem flexibler Layouts wurde jedoch bisher nicht zufriedenstellend gelöst.

User Interfaces für Webapplikationen

Als drittes möchte ich nochmal darauf hinweisen, dass gemäß der Logik der CSS-Spezifikation Webseiten eine definierbare Breite haben, in ihrer Länge aber grundsätzlich als unendlich definiert werden, weswegen es im Grunde keine Möglichkeiten gibt, den vertikalen Layoutaufbau sinnvoll zu gestalten, außer durch den linearen Aufbau des Markups und einer abschnittsweisen Gestaltung der aufeinander folgenden Elemente (Header, Content, Footer). Der CSS-Standard ist für HTML-Seiten konzipiert, das vertikale Scrollen gehört quasi zum Konzept dazu, um die theoretisch unendliche Informationsmenge einer HTML-Seite durch das Schlüsselloch Browserfenster (mit begrenzten Dimensionen) betrachten zu können. Schon für einen sticky Footer nutzen wir CSS-Kniffe, die ein Großteil von CSS-Einsteigern nicht mehr voll durchdringt und deshalb nur schwer auf die eigenen Randbedingungen anpassen kann.

Nun hat sich aber der HTML5 Standard auf die Fahnen geschrieben, HTML fit für Webapps zu machen. Befeuert wird diese Entwicklung durch potente Smartphones und Tablets. Man will eine echte Alternative zu nativen Applikationen schaffen, die naturgemäß für jedes OS separat entwickelt.

Der Gedanke ist ausgesprochen reizvoll, jedoch ist einer der grundlegenden Unterschiede, dass User Interfaces in nativen Applikationen anders funktionieren als eine Website. Niemand will auf der Suche nach einem wichtigen Funktion erst mühsam nach unten scrollen müssen, um dann für den Klick auf einen Menüpunkt wieder nach oben zu scrollen usw. Ihr versteht, was ich meine?

Es geht also um User Interfaces, die mit dem verfügbaren Platz in horizontaler und vertikaler Ausdehnung auskommen müssen/sollen – ohne Scrollen. Im CSS-Standard haben wir nichts, womit diese Aufgaben zu bewältigen wären. Der aktuelle Umweg geht hier über JavaScript. ExtJS bietet in seinen UI Komponenten so genannte Layout Manager, für jQuery gibt es das von mir hoch geschätzte Layout Plugin. Speziell auf den Mobilbereich ausgelegt, gesellen sich Projekte wie jQuery Mobile und Sencha Touch hinzu.

Diese JavaScript-basierenden Tools liefern uns die Layoutwerkzeuge, ohne die es kaum denkbar wäre, webbasierte Applikationen zu schreiben, die sich wie eine native App anfühlen. Dennoch stelle ich mir die Frage, ob wir es uns dauerhaft leisten wollen, Layoutaufgaben, die eigentlich der Browser für uns viel schneller und effizienter lösen könnte, an JavaScript auszulagern. An anderer Stelle diskutieren wir bis aufs Messer um jedes Byte, was wir aus Performancegründen weglassen können. Beim Layout jedoch sind wir jedoch JavaScript praktisch ausgeliefert, was nie so schnell werden kann wie die hardwarebeschleunigte Rendering-Engine eines Browsers (oder eben die des Betriebssystems, die jeder nativen App zur Verfügung steht). Und das hat auch die Konsequenz, dass eine native App sich – zumindest aus dieser Sicht – immer flüssiger anfühlen und reagieren wird als eine clientseitige JS-Implementation.

Damit will ich den gedanklichen Steifzug durch meine CSS-Phantasien beenden. Wichtig war mir, aufzuzeigen, dass wir Layouts aktuell noch mit vergleichsweise unausgereiften Techniken bauen, obgleich die technischen und qualitativen Anforderungen an CSS-basierte Layouts durch die heutige Vielzahl der Endgeräte enorm gestiegen ist und ich neben den tollen CSS3 Entwicklungen der letzten Jahre (Schatten, Gradienten, Webfonts, Animationen, etc), die niemand mehr missen will, hier eigentlich dringender Nachholebedarf und erhebliches Potential performantere Lösungen besteht. Auch habe ich mich bei dieser Liste ausschließlich auf die Belange des Seitenlayouts beschränkt. Schaut man sich andere Bereiche, könnte man hier sicherlich endlos weitere Wünsche ergänzen.


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.