Weblog

Nachdem nun aber auch Toplisten kaum jemand mehr sehen und lesen mag, wird insbesondere bei den zahlreichen Online-Magazinen spürbar, dass es - bedingt durch den quälend langsamen Entwicklungsprozess bei HTML & CSS - ganz offensichtlich nicht mehr viel Neues und Spannendes zu entdecken gibt. Man sucht händeringend nach unverbrauchten Themen und neuen Autoren.

Als vor 14 Tagen bei Dr. Web der umstrittene Beitrag “Hintergrundbilder eindrucksvoll mit CSS skalieren” erschien und der Autor für seine (bzw. die auf der Webseite GOTO CHINA verwendeten Lösung) Viewport-füllende und horizontal + vertikal zentrierte Darstellung einer Hintergrundgrafik doch tatsächlich eine HTML-Tabelle als Grundlage vorsah, war ihm der Proteststurm der CSS-Community sicher. Fast niemand der Kommentatoren hat sich dabei die Mühe gemacht, die vorgestellte Technik vollständig zu verstehen bevor man sie in der Luft zerriss. Denn ganz so trivial wie viele vermuteten, ist sie dann eben doch nicht. Gleichermaßen hat es der Autor versäumt, seine Entscheidung pro Layouttabelle schlüssig zu begründen.

Nun finde ich Layouttabellen alles andere als charmant. Aber ich muss auch zugeben, dass ich eine optisch zu 100% gleichwertige und ebenso robuste Variante auf reiner CSS-Basis – zumindest innerhalb einiger Stunden – nicht präsentieren konnte. Auf der anderen Seite hatte ich jedoch sehr schnell eine alternative Lösung, die ohne Tabellen dem Vorbild sehr nahe kommt und lediglich die vertikale Zentrierung bei sehr kleinem Viewport vermissen lässt. Mein Testcase ist zunächst nur ein Schnellschuss, zeigt aber, dass es auch anders geht.

Nach vielen Jahren der Diskussion um Webstandards wundert es mich dann schon, dass der Autor Adrian Bechtold kein Wort darüber verliert und dadurch die massive Kommentarflut provoziert. Es ist nämlich die Frage, ob – wie im vorgestellten Beispiel – das Ergebnis die Mittel (Layouttabelle) wirklich rechtfertigt. Genau diese Folgediskussion wäre interessant gewesen, doch leider wollten sich hier weder der Autor noch die Kommentatoren darauf einlassen. Das Team von Dr. Web ist gerade dabei ist, dem eigenen Portal neues Leben einzuhauchen. Hier wäre eine Chance gewesen, doch ohne den Bezug zu aktuellen Layouttechniken wirkt der visuell beeindruckende Effekt in der Umsetzung verdammt altbacken.

Und damit kommen wir zum zweiten Fall. Auch das in die Jahre gekommene SelfHTML versucht mit neuen Fachartikeln den Anschluss zu halten. Doch dieser scheint sowohl beim Autor als auch bei der Redaktion bereits in weite Ferne gerückt zu sein. Stein des Anstoßes ist der Beitrag “Benutzerfreundliche Viewportweiche ohne JavaScript”.  Auf dem einstigen deutschsprachigen Aushängeschild, der langjährigen Lernplattform für unzählige angehende Webdesigner veröffentlicht man 2009 invaliden HTML-Code ohne Doctype (invalid selbst nach HTML 4.01 Transitional), mit Layouttabellen, Absatztrennung mit <br><br> und haufenweise Inline-Styles. Das ganze verpackt in einem Thema dessen Relevanz um den Nullpunkt schlingert und mit haarsträubenden Argumenten und Beispielen.

Und als ob das nicht bereits genug wäre, können weder die SelfHTML-Redaktion noch der Autor selbst mit der zwangsläufig aufkommenden Kritik sonderlich gut umgehen. Diese wird vom SelfHTML-Team als das Gemeckere eines “elitär kleinen Zirkel von Semantik-Fetischisten” und vom Autor Martin Suhr selbst als Quatsch eines nörgelnden Misanthropen gekontert. Inhaltlich geht man auf die Kritik natürlich nicht ein. Stattdessen rechtfertigt sich die Redaktion wir folgt:

Wenn ich an alle unsere Artikel, insbesondere an die, die noch zu schreiben sind, die höchsten Qualitätsansprüche stelle, nur um einen elitär kleinen Zirkel von Semantik-Fetischisten zufrieden zu stellen, habe ich keine Autoren mehr, die es überhaupt noch wagen werden, uns irgendwelche Inhalte zu liefern.

Liebes SelfHTML-Team, das ist ein peinliches Armutszeugnis und wenn Ihr das wirklich so seht, wenn euch die Qualität Eurer Artikel egal ist so lange Ihr nur etwas veröffentlichen könnt, dann SelfHTML: Ruhe in Frieden. Oder wie Jens Grochtdreis es in seinem Kommentar treffend formuliert:

Diese Qualitätskontrolle erwarte ich auch bei SELFHTML. Dann sollten keine Codebeispiele Marke “Scheiss egal, was da steht, es geht erstmal ums grobe Prinzip” veröffentlicht werden.

Der nächste Entwickler, dem ich dann versuche seinen Tabellenlayouts auszureden, erzählt mir dann, daß er das bei SELFHTML gelesen hat. Und das müsse ja dann wahr sein.

Und wenn Du keine Qualitätsansprüche an Deine Publikation stellen willst, dann tut es mir um das ehemals richtig gute SELFHTML sehr leid. Dann ist es wohl wirklich an der Zeit, von diesem netten und informativen Dino Abschied zu nehmen. Die Referenzen von Sitepoint sind auf dem neuesten Stand und kommen ohne Tabellenlayouts aus.

In diesem Sinne, das war’s, was ich kurz anmerken wollte. Was meint Ihr?

Umso erstaunter war ich heute über drei aktuelle, englischsprachige Beiträge (Danke Angar, für den Hinweis), die sich erneut dem Thema widmen und weitere gute Argumente für elastische und fluide (oder allg. flexible) Layouts liefern.

• Page zoom does not mean the end of flexibility [456bereastreet.com]
• Why browser zoom shouldn’t kill flexible layouts [zomigi.com]
• Zoomfusion [Adactio]

Der Beitrag auf 456bereastreet.com bringt ein sehr interessantes Argument: die Mehrsprachigkeit. Allein aufgrund der Sprache, in der Inhalte ausgegeben werden, verändert sich die Textmenge, bzw. deren Platzbedarf. Flexible Layouts können sich hier deutlich besser anpassen als fixe Konstrukte. Der Beitrag von Zoe Mickley Gillenwater geht noch deutlich tiefer ins Detail und bringt sechs weitere, gut durchdachte Argumente pro elastischem bzw. flexiblen Layout. Besonders interessant dabei ist der Punkt “Preserve design proportions”. Genau dies wird aktuell sehr gern als Grund angeführt, warum elastische Layouts in Zeiten eines funktionierenden Seitenzooms praktisch keine Relevanz mehr hätten (noch dazu, da sie sehr aufwändig in der Erstellung seien). Das überzeugende Argument pro elastischem Layout ist wieder einmal der User mit seiner Möglichkeit, die Standardschriftgröße seines Browsers/Betriebssystems beliebig nach oben oder unten anzupassen. Ein fixes Layout - Seitenzoom hin oder her - kann sich derartigen Gegebenheiten nicht anpassen, die Laufweiten der Texte ändern sich zwangsläufig und die schönste Typografie kann den Bach runter gehen.

Ich möchte hier nicht alle Punkte wiederholen. Die Beiträge sind hervorragend geschrieben, also lest selbst. Der sehr schön formulierten Zusammenfassung von Zoe Mickley Gillenwater schließe ich mich hiermit aus ganzem Herzen an.

Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. ... Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.

“Why browser zoom shouldn’t kill flexible layouts”, Zoe Mickley Gillenwater

Das Diagramm zeigt drei Graphen für Auflösungen von 800x600, 1024x768 Pixeln und alle darüberliegenden Auflösungen (Higher) als Volllinien. Die gestrichelten Linien entsprechen meiner Prognose für die Entwicklung bis Januar 2009 vom Juni letzten Jahres.

Wie man sieht, liege ich ganz schön daneben – im positiven Sinne. Denn der Anteil der höheren Auflösungen hat exponentiell zugelegt, während ich damals vorsichtig herangegangen war und damals nur eine lineare Zunahme angenommen habe. Dementsprechend ist auch der Anteil für die 1024x768 Auflösung kräftiger gefallen als vermutet. Während ich eine Abnahme auf ca. 42% geschätzt hatte, weist die Statistik aktuell nur noch 36% aus.

Das Gesamtbild verdeutlicht, wie vielfältig und nicht vorhersagbar die Randbedingungen sind, mit der Webseiten im Browser betrachtet werden. Zumal noch hinzukommt, dass der Browser selten im Vollbildmodus betrieben wird, sodass die noch ein weiterer Unsicherheitsfaktor (die Größe des Viewports) hinzu kommt. Ich selbst arbeite mittlerweile sowohl dienstlich als auch privat nur noch in Auflösungen von 1680x1080 oder darüber, der Brower lasse ich ausschließlich in einem Fenster laufen, ziehe jedoch das Fenster meist sehr weit auf, um beim Surfen nicht von anderen Applikationan abgelenkt zu werden. Die Viewportbreite meines Browserfensters liegt daher gewohnheitsmäßig (je nach dem, an welchem Rechner ich gerade sitze) zwischen 1400 und 1600 Pixeln. Das war auch der Grund, weshalb ich das Layout dieser Seite flexibel gestaltet und für große Auflösungen entwickelt habe.

In diesem Zusammenhang auch spannend, die aktuelle Display-Statisik von YAML.de, eine Seite mit recht ordentlichem internationalen Besucherverkehr. Wie man sieht, ist der Anteil der 1024er Auflösung mit 12% bereits deutlich niedriger. Den größten Einzelposten kann die 1280er Auflösung für sich beanspruchen mit 43%. Zusammen mit der 1024er sind das knapp über die Hälfte aller User. Das zeigt zum einen, dass der allgemeine Focus für die Breite einer Webseite sich in diesem Bereich bewegen sollte (alles andere hätte auch verwundert). Aber man sieht auch wie kräftig 1440, 1680 und die HD-Auflösung mit 1920 Pixeln Breite mittlerweile vertreten sind. Und für diese drei Auflösungen prognostiziere ich für Januar 2010 einen weiteren deutlichen Anstieg, während die kleineren Auflösungen, einschließlich der 1280er Breite stark federn lassen werden.

Egal, für welche Breite man letztlich sein Layout auslegt. In jedem Fall sollte die Zentrierung einer linksbündigen Anordnung vorgezogen werden. Denn bei einer fixen Breite von 760px bedeutet das schon bei der 1280er Auflösung, dass 40 Prozent der Viewportbreite ungenutzt bleiben. Steigt die Auflösung beim User - oder werden Inhalte innerhalb des Layout nicht über die volle Breite darsgestellt (typisch für Mehrspaltenlayouts), verschiebt sich das Verhältnis im Regelfall noch weiter in die Richtung, dass der ungenutzte Raum dominiert.
 

Das Blog wird vollständig in englisch geführt werden. Der Grund hierfür ist einfach: YAML hat eine stetig wachsende weltweite Community, die schon lange die Grenzen der deutschen Sprache überwunden hat. Es war also längst an der Zeit, dieser Entwicklung Rechnung zu tragen. Zum zweiten erleichtert es die Arbeit, wenn nicht jede kleine Nachricht zeitlich synchron zweisprachig erscheinen muss. Ich habe vor, dieses Entwicklerblog mittelfristig auch für Drittentwickler zu öffnen, sodass hier ein neuer Informationspool mit Links und Tutorials entsteht.

Und damit zurück zu YAML. Volle 6 Monate Entwicklung stecken in der neuen Version - mit einigen größeren Pausen. Der Versionssprung von 3.0.6 auf 3.1 mag gering erscheinen. Für mich und ich denke auch für alle Anwender ist es dennoch ein großer Meilenstein, denn die zahlreichen neuen Features machen das Framework nun endgültig zu einem Werkzeug, welches den Webentwickler über den gesamten Erstellungsprozess einer Webseite begleitet und unterstützt. Das beginnt beim Screenlayout, über die Gestaltung der Inhalte, der Erstellung von Formularen mit Hilfe des nagelneuen Formularbaukastens bis hin zu einer perfekten Druckversion der Webseite. In allen Bereichen sorgt das Framework dafür, dass sich der Entwickler auf das Wesentliche - seinen Layoutentwurf - konzentrieren kann und der Internet Explorer (ebenso wie zahlreiche CSS-Bugs anderer Browser) weitgehend seinen Schrecken verloren hat.

Ich werde im Verlauf der nächsten Tage an dieser Stelle noch im Detail auf die interessantesten neuen Funktionen von YAML 3.1 eingehen. Im Rahmen dieser Kurzmeldung will ich es bei der Verlinkung der interessantesten neuen Layoutbeispiele belassen, die einen guten Eindruck von der stark erweiterten Leistungsfähigkeit des Systems vermitteln.

• Umfassende Vorlagen zur Gestaltung von Inhalten
• ein vielseitiger Formularbaukasten
• Viele neue Variationsmöglichkeiten mit Fullpage-Layouts
• Gleichhohe Inhaltsboxen auf Basis der Subtemplates
• Unterstützung für Microformate (Add-on)
• Unterstützung von RTL-Sprachen (Add-on) 

Daneben gibt es zahlreiche weitere kleine Verbesserungen über die in Summe wie immer das Changelog Auskunft gibt. Sowohl das “Simple Project” als auch der YAML-Builder wurden bereits auf YAML 3.1 aktualisiert, wobei der Builder natürlich noch nicht die neuen Gestaltungsmöglichkeiten unterstützt (so schnell bin ich nun auch wieder nicht) aber zumindest zu YAML 3.1 kompatiblen Code generiert.

Damit wünsche ich allen Anwendern viel Spaß mit der neuen Version.