Weblog

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?

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.

• 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

Aus aktuellem Anlass: Beiträge in der Form ...

• Don’t use [include any HTML element / CSS property / software project you want]
• [include any HTML element / CSS property / software project you want] considered harmful

... sind aus meiner Sicht – zumindest was den Bereich der Webentwicklung betrifft – in den seltensten Fällen geeignet, den Focus auf die wirklich wichtigen Probleme zu richten.

So, das musste einfach mal raus.

CSS-Frameworks sind bei mir immer wieder Thema. Klar, ich entwickle ja auch ein eigenes. Dennoch – vergleichbar mit der Argumentation pro & contra CSS-Layouts, die David Maciejewski, Tomas Caspers und ich in der letzten Technikwürze diskutiert haben – mache ich mir bereits seit längerem Gedanken um eine gehaltvollere Argumentation in der öffentlichen Diskussion. Die Anzahl der Framework-Projekte wuchs im letzten Jahr fast wöchentlich und noch immer kommen regelmäßig neue Projekte hinzu. Gleichzeitig wird die Streubreite der Layoutansätze, Funktionsumfang und Intention der Projekte (Layout, Formulare, Menüs) immer größer, sodass ein Vergleich zwischen einzelnen Frameworks nicht gerade einfach ist, ganz zu schweigen von der nicht weniger weitgefächerten Erwartungshaltung von Webentwicklern an derartige Projekte. Zudem gibt es weder im deutschen noch im englischen Sprachraum nur sehr wenige Beiträge, die sich eingängig mit dem übergeordneten Konzeptes eines Frameworks im Beich HTML & CSS beschäftigen. Einer der wenigen Beiträge in dieser Richtung “Frameworks for Designers” wurde im Juli 2007 von Jeff Croft auf A List Apart veröffentlicht.

Fast in direkter Folge auf diesen Artikel erschien seinerzeit Blueprint CSS auf der Bildfläche und leitete einen weltweiten Hype ein, obgleich Projekte wie YAMLoder YUI Grids zu diesem Zeitpunkt bereits jeweils etwa 2 Jahre Entwicklungszeit hinter sich hatten. Keines der beiden Projekte vermochte aber die Aufwerksamkeit der Gemeinde der Webentwickler derart aufzurütteln.

Mit Blueprint CSS und seinem geradlinigen Grid-Ansatz kamen die Diskussionen um CSS-Frameworks in Schwung, wobei insbesondere im englischen Sprachraum aufgrund des Hypes die beiden Bezeichnungen “CSS-Frameworks” und “Blueprint CSS” sehr eng miteinander verbunden. Positive Stimmen heben den Gridansatz von Blueprint (und damit CSS-Frameworks) in den Himmel, kritische Stimmen bemängeln den tabellenähnlichen Aufbau des Markups, weiten ihre Kritik aber ebenso wie die Beführworter meist pauschal auf alle Framework-Projekte aus. Hinzu kommt die verbreitete Liebe zu Top-Listen-Blogbeiträgen (“Die 10 besten ...”, “Die 100 besten ...”), wobei das Hinterfragen der unterschiedlichen Projektansätze zugunsten der Masse auf der Strecke bleibt.

Bereits auf dem Webkongress 2008 in Erlangen habe ich deshalb in meinem Vortrag versucht, einen etwas differenzierteren Blick auf die Vielzahl der Frameworkprojekte zu werfen und dabei die individuellen Stärken und Grenzen der Projekte, wie auch die allgemeinen Vorteile der Arbeit mit CSS-Frameworks herauszuarbeiten. Der im Verlauf der letzten 3 Wochen in Zusammenarbeit mit Nils Pooker entstandene Essay “Was Sie über CSS-Frameworks wissen sollten!” ist eine Fortführung dieser Betrachtung, der parallel auch in englischer Sprache veröffentlicht wird.

Wir haben dabei bewusst die Länge des Essays in Kauf genommen, denn wir wollten alle in der öffentlichen Diskussion befindlichen Aspekte ansprechen und nicht in einer Serie Einzelartikeln in Details verlieren. Zu schnell ginge in der Hitze der Diskussion der Blick auf das übergeordnete Konzept verloren. Erwartungsgemäß steckt in diesem Essay unsere meine Meinung pro CSS-Frameworks, denn sonst würde ich mich wohl kaum um die Weiterentwicklung von YAML kümmern. Wir hoffen, mit diesem Essay die Diskussion anregen zu können und freuen uns auf hoffentlich zahlreiche Kommentare und Blogbeiträge, gern auch mit gegenteiligen Meinungen. Bei Interesse antworten wir auf interessante Diskussionspunkte auch gern mit einem Folgebeitrag.

In diesem Sinne, viel Spaß beim Lesen ...

Vor etwas mehr als 8 Monaten hat dieses Webseite ein umfassendes Redesign erfahren. Damit einher ging ein Testballon, meine Eigenentwicklung einer dynamischen Kommentaransicht. Die Kommentare erscheinen jeweils rechts neben den Blogbeiträgen, ältere Kommentare werden dynamisch ausgeblendet, damit auch bei vielen Kommentaren kein Zaunlattenlayout (the long tail) entsteht, welches endloses Scrollen erfordert. Nach fast einem dreiviertel Jahre wird es Zeit, sich über die Zukunft dieses Features ein paar Gedanken zu machen.

Die dynamische Kommentaransicht wurde mit jQuery realisiert und blendet die jeweils neuesten 5 Kommentare ein. Ältere Kommentare werden dynamisch paginiert und können bei Interesse entweder in schrittweise (jeweils 5 Kommentare) oder vollständig aufgeklappt werden. Anfängliche Schwierigkeiten mit dem Anspringen der neuesten Kommentare von der Highresolution-Startseite waren schnell behoben. Ebenfalls bereits seit ein paar Monaten gibt es auch den von Alexander Farkas angeregten Yellow-Fade-Effekt, mit dem der angesprungene Kommentar kurzzeitig gelb hervorgehoben wird.

Im damaligen Relaunch-Artikel gab es insgesamt viel Lob aber auch einige kritische bzw. bedenkliche Stimmen, was die Position der Kommentare bzw. die ungewohnte Art der Präsentation angeht.

8 Monate später ist mein Resümee dieses Experimentes durchweg positiv. Ein Absinken des Kommentaraufkommens konnte ich nicht feststellen, das neue Bloglayout hat eher dafür gesorgt, dass viele neue Leser offensichtlich gern in diesem flexiblen Layout verweilen und durchaus auch gern und umfangreich kommentieren – obwohl ich durchschnittlich kaum mehr als 3 Beiträge pro Monat schreibe. Optisch hat die Lösung die gesetzten Ziele voll erfüllt, denn das Layout ist auf dein meisten Artikelseiten sehr gleichmäßig ausgelastet und die rechte Spalte läuft nicht mehr ins endlos nach unten. Meine Leser scheinen – zumindest ist das mein Eindruck – mit der Kommentaransicht gleichfalls gut zurecht zu kommen, denn Diskussionen innerhalb der Kommentare finden auch gelegentlich statt.

So gesehen, werde ich dieses Feature also beibehalten und möchte deshalb hier die Frage in den Raum stellen, ob grundsätzlich Interesse an einer Plugin-Lösung auf jQuery-Basis für die dynamische Kommentaransicht besteht? Der Quelltext befindet sich grundsätzlich in recht ordentlichem Zustand, sodass die Umwandlung in ein Plugin keinen zu großen Aufwand bedeuten würde. Allerdings stellt sich eben zuvor die Frage, ob überhaupt Interesse an dieser Darstellungsform besteht – nicht nur an einer exemplarischen Umsetzung sondern auch das Interesse, ein solches Plugin im eigenen Blog einzusetzen. Ich bin gespannt auf Eure Antworten.