Montag29. Juni 2009

Ich unterbreche die temporäre Funkstille in diesem Weblog für eine kleine Diskussion, die mir nun schon seit ein paar Wochen auf dem Magen liegt. Irgendwie wird man das Gefühl nicht los, bei HTML & CSS wäre entwicklungstechnisch die Luft raus. Seit Monaten überschlagen sich Online-Magazine für Webdesigner mit Toplisten, in denen bestehende Informationen aus dem Netz nach mehr oder minder sinnvollen Kriterien immer wieder neu zusammengestellt und wiedergekaut werden. Echte Fachartikel mit “a-ha” Effekt sind in diesen Tagen äußerst selten geworden.

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?


Donnerstag18. Juni 2009

Fast auf den Tag genau vor einem Jahr habe ich bei Dr. Web und im Smashing Magazine einen längeren Essay über “Flexible Layouts als die Herausforderung der Zukunft” veröffentlicht.

Schon damals – lange bevor mit dem IE8 und dem Safari 4 die letzten beiden Browsergrößen auf den Seitenzoom-Zug aufsprungen – war ich der Meinung, dass die von Opera 9 und Firefox 3 eingeführte Technik nicht das Allheilmittel für die zahlreichen Limitierungen pixelbasierter Layouts, bzw. der Sargnagel für flexible Layouts sein wird und hatte dies in den beiden Artikeln mit der immer weiter aufklaffenden Schere von Bildschirmauflösungen und der verstärkten Nutzung von Smartphones und Netbooks begründet. Seinerzeit entbrannte eine heiße Diskussion, danach war aber eigentlich die Luft raus und kaum jemand widmete sich mehr diesem Thema.

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.

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


Seite 1 von 1 Seiten