Samstag,
17. Mai 2008

In der letzten Zeit lese ich immer häufiger in verschiedenen Blogs vom nahenden Ende der flexible Layouts. Begründet wird diese Untergangsvision mit der Ankunft des Firefox 3, der als dritter großer Webbrowser (neben IE 7 und Opera 9) den Seitenzoom mitbringen wird. Der Nutzer kann sich somit jedes noch so fest in ein Pixelraster gemeißeltes Layout skalieren. Wenn der Nutzer sich also selbst kümmern kann, so können sich Webentwickler endgültig ohne Gewissensbisse auf die ach so einfachen und beliebten fixen Layouts beschränken.

Nun, ich sehe das etwas anders und werde versuchen, diese These anhand von fünf Punkten zu widerlegen.

#1 „Der Glaube an den heiligen Seitenzoom“ oder „Nutzer, hilf Dir selbst!“

Wie oben bereits angesprochen, werden mit dem Firefox 3, dem IE 7 und dem Opera 9 in Kürze drei wichtige Browser den Seitenzoom unterstützen. Die These: Damit würde jedes fixe Layout skalierbar und der Aufwand für flexible Layouts sei nicht mehr gerechtfertigt.

Falsch gedacht, denn zwischen fix und flexibel besteht auch weiterhin ein fundamentaler Unterschied. Ein flexibles Layout passt sich im Rahmen der CSS-Vorgaben in seiner Breite dem aktuellen Ausgabemedium an. Ein fixes Layout hingegen kann dies nicht. Der Seitenzoom ermöglicht es lediglich dem Nutzer, die Seite nachträglich selbst im Browser nach seinen Bedürfnissen zu vergrößern, ohne dass das Layout größeren Schaden nimmt. Das ist in der Tat eine technische Verbesserung der aktuellen Browsergeneration, jedoch kein Argument gegen flexible Layouts. Noch immer liegt der IE6 in den weltweiten Browserstatistiken bei ca. 40%, (und nochmal ca. 40% für den IE7) d.h. fast jeder zweite User surft ohne dieses Feature.

Noch störender an dieser Argumentation finde ich aber die unterschwellige Botschaft: Anwender, hilf Dir doch selbst. Vorbei ist es offenbar mit der Rücksicht auf die Zugänglichkeit. Das ist dann ungefähr so als gäbe es im Klamottenladen nur noch Hosen in Größe 32. Wem die nicht passen, der darf sich gern auf dem Wühltisch kostenlos Stoffkeile, Nadel und Faden mitnehmen und sich die Hose zuhause selber umnähen. Soll sich das Web wirklich in diese Richtung entwickeln?

Nur zur Erinnerung: Kein Webdesigner hat die Kontrolle über sein Layout. Über die Darstellung entscheidet einzig und allein der User durch Browserwahl, Schriftgrößeneinstellungen (gern auch mal übers Betriebssystem), alternative Nutzer-Stylesheets und so weiter. Ein fixes Layout lässt sich für den Rechner und Lieblingsbrowser des eigenen Chefs oder des Auftraggebers optimieren, aber eben nicht für die grenzenlose Vielfalt der Nutzeranforderungen im großen wilden Internet.

#2 Das Märchen vom flexiblen Problembär

Wenn es darum geht, gegen flexible Layouts zu argumentieren, stehen zwei Argumente immer ganz weit vorn. Fangen wir mit dem Ersten an:

Bei flexiblen Layouts läuft der Text beim Aufziehen des Browserfensters unkontrolliert in die Breite, was ihn letztlich schwer lesbar macht.

Falsch gedacht, denn genau dafür hat der liebe CSS-Gott die Eigenschaften min-width und max-width erfunden. Und schon höre ich die Zwischenrufe, dass der IE6 diese Eigenschaften doch nicht unterstütze. Na und? Der IE6 hat auch ein kaputtes Box- und Float-Modell. Hält das irgend jemanden davon ab, Layouts für diesen Browser zu erstellen? Auch für min-width und max-width gibt es sowohl per CSS als auch per JavaScript adäquate Workarounds.

Und gleich noch ein Zwischenruf: JavaScript könne man ja nicht vorausgesetzt werden. Auch das stimmt, jedoch wird das Layout ohne JavaScript nicht automatisch unbenutzbar, sondern ggf. nur leicht in der Darstellungsqualität eingeschränkt – aber auch nur dann, wenn der Nutzer gleichzeitig ein sehr breites Browserfenster verwendet. In jedem Fall skaliert das Layout weiterhin und ist in > 90% der Fälle uneingeschränkt nutzbar.

Wie macht man es also richtig: Die Breite wird bei flexiblen Layouts in Prozent angegeben, entweder über width:auto (entspricht dem maximal verfügbaren Breite) oder einem Wert kleiner 100%. Als Untergrenze (min-width) sollte man einen Wert in der Einheit Pixel (px) wählen. Auf diese Weise lassen sich Grafiken (i.d.R. pixelbasiert) einfach an die minimale Layoutbreite anpassen und das Layout kann nicht unkontrolliert zusammengestaucht werden. Als obere Grenze (max-width) eignet sich entweder der Wert 100%, wenn man horizontale Scrollbalken in jedem Fall verhindern will, oder aber (was ich persönlich empfehle) einen Wert in der Einheit EM (z.B. 100 em). Auf diese Weise kann die Laufweite von Fließtexten innerhalb des Layouts auf ein gut lesbares Maß begrenzt werden, gleichzeitig skaliert das Layout aber weiterhin bei Änderungen der Basisschriftgröße.

#3 Alle Macht ... ähm, dem Designer? Oder wie?

Während das erste Argument wenigstens noch einen technischen Hintergrund hat, ist das zweite nicht viel mehr als ein verbaler ausgetreckter Zeigefinger, mit dem man die Verantwortung auf einen anderen schiebt.

Der Designer wünscht sich eine pixelgenaue Umsetzung seines Layouts. Da ist kein Spielraum für Flexibilität in der Umsetzung in HTML und CSS.

Falsch gedacht, denn das Layout soll ja nach der Fertigstellung nicht nur einen schönen Screenshot im Portfolio des Designers abgeben sondern den Usern einen möglichst attraktiven und gleichzeitig ungehinderten Zugang zu den Informationen der Seite bieten (Klingelt’s? Thema: Barrierefreiheit). Designer erarbeiten das Layout üblicherweise in Photoshop, also auf einem digitalen Blatt Papier. Wir alle wissen aber, dass das Web so nicht funktioniert. Warum sollte man daher diese Entscheidung allein dem Grafiker überlassen? Steht denn irgendwo geschrieben, dass Navigationselemente schon beim einmaligen Vergrößern der Schriftgröße aus ihren Fake-Boxen (rechteckige Hintergrundgrafiken) herausfallen müssen?

Grafisch anspruchsvolle flexible Layouts verlangen auch von Grafikern ein gewisses Verständnis der Materie. Dass sich dieses Ziel nicht immer realisieren lässt ist mir klar, in vielen Fällen ist es jedoch durchaus möglich und sinnvoll. Üblicherweise arbeitet man hier mit halbtransparenten Übergängen, Farbverläufen oder kleinformatigen grafischen Mustern. Diese werden im Layout geschickt skalierbaren Elemente (oder sonstigen ungenutzten Flächen) zugeordnet und schon lassen sich sehr attraktive Entwürfe umsetzen.

#4 Handy-Browser – Denn sie wissen nicht, was sie tun

Nun ja, das taten sie in der Vergangenheit wirklich und meine letzten beiden ehemaligen Handys boten zwar Internet-Zugriff aber konnten kaum eine aktuelle Webseite fehlerfrei darstellen. Dann wäre noch die Möglichkeit alternativer Stylesheets, womit Desktopdarstellung und das Rendering auf mobilen Geräten eh unabhängig voneinander laufe. Aber diese Zeiten sind vorbei, deshalb schon wieder ...

Falsch gedacht, denn kaum ein Handy unterstützt den Medientyp @media handheld, mit dessen Hilfe man auf einfachem Wege alternative Stylesheets zur Verfügung stellen könnte. Erschwerend kommt hinzu, dass in den letzten zwei Jahren die Mobilbrowser stark aufgeholt haben (Opera Mini oder Safari auf dem iPhone) und mittlerweile ganz selbstverständlich das normale Screenlayout rendern – weitgehend fehlerfrei, versteht sich. Und selbst die Werbung verspricht mittlerweile das wahre Internet und keine kryptischen WAP-Seiten mehr. Mein iPhone, zum Beispiel, passt flexible Layouts automatisch optimal dem Hoch- oder Querformat an, während ich z.B. die Spiegel-Seite (fixes Layout) jedesmal von neuem erst einmal aufzoomen muss, damit sie wirklich den gesamten Bildschirm ausfüllt und Überschriften und Texte lesbar werden.

Und was für mobile Geräte gilt, gilt ebenso für Drucker: Nur komischerweise widerspricht mir hier in der Regel niemand, wenn ich von den Vorteilen der Flexibilität bei der Druckausgabe rede – obwohl es sich für den Browser nur um ein weiteres Ausgabemedium mit etwas anderen technischen Daten darstellt. Woran das wohl liegt?

Indem ich als Webdesigner ein flexibles Layout erstelle und somit vermeintlich die „Kontrolle verliere“, gewinne ich stattdessen in Wirklichkeit selbige hinzu. Denn durch Vorgabe von Rendering-Regeln (Mindestabstände, Ausrichtung usw.) anstatt fester Pixelvorgaben, kann der Browser beim Rendering auf die Wünsche des Nutzers eingehen, anstatt einen in Pixelsteine gemeißeltes Layout auszugeben, komme was das wolle.

#5 Die Zukunft, das unentdeckte Land

Das mobile Internet wird immer wichtiger werden. Fangen wir deshalb wieder an für 640x480 oder 800x600 Pixel zu optimieren – wer das meint, darf ruhig die Hand heben? Die Monitorauflösungen wachsen rasant. Ich entwickle Software und brauche Platz am Bildschirm. Mein Desktop-Monitor (27 Zoll) hat eine Auflösung von 1900x1200 Pixeln, mein Notebook (15 Zoll) steht dem mit 1680x1050 Pixeln kaum nach. Zwar liegen diese Werte derzeit noch etwas über dem Durchschnitt aber schon jetzt ist das keine Besonderheit mehr und die Preise für hochauflösende LCDs fallen weiter. Parallel dazu wächst nicht nur physikalische Auflösung der Geräte, auch die Punktdichte (dpi) steigt immer weiter, wodurch sich die absolute Größe eines Pixels zusätzlich verringert. Es ist daher nicht verwunderlich, dass pixelbasierte Größenangaben immer weniger aussagekräftig und zeitgemäß sind.

Oder wie wäre es mit SVG- oder Canvas-Grafiken? Gerade erst haben sich Opera und Safari ein Wettrennen um SVG-Unterstützung im ACID3-Test geliefert. Ich frage mich wozu das Internet vektorbasierte Grafikformate braucht, wenn fixe Layouts wirklich der Weisheit letzter Schluss sein sollen?

Die Schere zwischen niedrig- und hochauflösenden Ausgabemedien hat sich in den letzten 10 Jahren nicht geschlossen. Ganz im Gegenteil: Sie geht immer weiter auf. Allein schon dieser Fakt verdeutlicht, wie wichtig flexible Layoutansätze heute und in der Zukunft sein werden und wie wenig hier fixe Layouts in Zukunft noch ein Optimum für die Mehrheit der Nutzer sein werden.

Fazit

Ich denke, die eingangs genannte These ist kurzsichtig und mit Sicherheit nicht im Sinne eines besseren Webs. Und um den Fortbestand flexibler Layouts braucht man sich keine Sorgen machen.


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.