Ich denke, ich als Autor sollte jetzt mal ein Statement abgeben, bzw. einen Erklärungsversuch, wie es aus meiner Sicht zu diesem Eklat gekommen ist. Und wie ich die Dinge mittlerweile sehe:

- Ich kann verstehen dass auf den Artikel und seine Veröffentlichung mit "Verwunderung" reagiert wurde.

- Die Kritik am Code ist uneingeschränkt berechtigt. Da gibt es nichts zu beschönigen.

- Auch was Sinn oder Unsinn von Viewportweichen betrifft, kann ich die Kritik nachvollziehen, mein Artikel bleibt eine detailierte Auseinandersetzung damit schuldig. Trotzdem kann ich diese Kritik nicht in allen Punkten einfach so hinnehmen, dazu unten mehr.

Ich bin an die Veröffentlichung wohl mit zu großer Naivität herangegangen. Mir ging es im Wesentlichen darum, eine kleine Bereicherung zum Web zu leisten - und eventuell eine Pagerank-Verbesserung meiner eigenen Seiten zu erreichen, was ja, wie mir jeder zugestehen wird, legitim ist. Von der hier aufgebrandeten Kritik war ich dann doch - milde ausgedrückt - etwas überrascht und musste mich erstmal davon erholen. Dass ich hier derart "zwischen die Fronten" geraten würde, habe ich nicht geahnt.

Die Anfänge der von mir entwickelten javascriptlosen Viewportwieche liegen schon ein paar Jährchen zurück, ich habe immer wieder mal daran gebastelt, bis das Ding für den User so perfekt geworden war, wie es IMO nur sein kann.

Mit Liquid-, Fluid oder Elastic-Layouts sowie der heute bestehenden Forderung nach semantischem Code habe ich mich bisher nicht näher beschäftigt. Daher maße ich mir auch nicht an, die hier offensichtlich versammelte Fachkompetenz in diesen Dingen in Zweifel zu ziehen. Im Gegenteil, nachdem ich mich vom Schock des Kritik-Tsunamis erholt habe, setze ich mich mit den einzelnen Punkten auseinander und das kann nur gut sein.

Ich will den neuen, ausführlichen SELFHTML-Artikel, der jetzt in Arbeit geht, nicht vorwegnehmen, aber vielleicht sei es mir erlaubt, dass ich hier ein paar Kritikpunkte nochmal meinerseits kritisch betrachte - so daneben kann ich mit meinen Gedanken nicht liegen, lasse mich aber korrigieren, und dies auch gerne, solange es fair geschieht:

1. Kritikpunkt "SELFHTML ist in erster Linie für Anfänger gedacht":

Diese Aussage ist natürlich ein gutes Argument bezüglich des unsauberen Codes - geschenkt.

Aber was ist denn einfacher zu coden: eine Viewportweiche oder Liquidlayouts? Gerade im Hinblick auf Anfänger halte ich eine Viewportweiche im Vergleich zu Liquidlayouts erstmal für die wesentlich einfachere Lösung - sowohl der Part mit Javascript, als auch meine Ergänzung ohne Javascript. Und unter gewissen Vorraussetzungen kann auch die sich aus der Viewportweiche ergebende Weiterverarbeitung der gewonnenen Daten die einfachere Lösung bleiben:

2. Kritikpunkt "Was tut man, wenn man die Viewportgröße kennt?

Bei kleinen Webseiten (und wenn man sich am Nachteil des "duplicate content" für Google und Co nicht stört), ist sicherlich das Vorhalten mehrerer einfacher, für verschiedene Größen optimierter Html-Seiten die einfachere Lösung, was IMHO bei kleineren Projekten einer Viewportweiche Berechtigung verleihen kann.

Bei größeren Projekten ist Sessiontracking per Cookies eine Möglichkeit. Kritisiert wurde hier ja vor allem, dass die dafür nötige serverseitige Programmierung zu komplex sei. Ich habe genau dies aber auf meinen eigenen Seiten (auch wenn es sich dabei um ein kleines Projekt handelt) mit jsp realisiert: hat man einmal ein Framework erstellt, ist es gar nicht mehr so kompliziert und arbeitsaufwändig, wie man vielleicht denkt - letztlich ist es dann nur noch copy-and-paste. Gut, die Mühe für ein solches Framework muss man sich natürlcih erstmal machen aver dann kann man es für weitere Seiten und natürlich auch für andere Projekte wiederverwenden.

Natürlich bleibt aber weiter das Argument bestehen, wer Javascript deaktiviert, akzeptiert mit erhöhter Wahrscheinlichkeit auch keine Coookies. Denkbar wäre daher als Alternative zu Sessiontracking auch ein serverseitiges Framework (beispielsweise mit Servlets, JSP oder PHP), mittels dessen die einmal ermittelte Viewportgröße per GET- oder POST innerhalb des Webangebots einfach immer weitergereicht wird - das käme wie gesagt ganz ohne Cookies aus und wäre wohl auch suchmachinenfreundlich weil frei von duplicate content. Und das Gesagte bezüglich Wiederverwendbarkeit gilt dann natürlich genauso.

3. Kritikpunkt "vorgeschaltete Seiten sind heutzutage eine Zumutung" (jedenfalls sinngemäß wurde das ja so gesagt):

Klar sind vorgeschaltete Seiten unschön. Aber es sind ja auch nur sehr wenige, die ohne Javascript unterwegs sind, und da diese bewußt Nachteile in Kauf nehmen, sollte es für sie wohl kaum sehr tragisch sein, wenn sie mal eben auf einen Knopf drücken müssen, um trotz deaktiviertem Javascript ein Webangebot in einer für sie optimalen Größe präsentiert zu bekommen. DIESE User - und nur für die ist meine Viewportweiche ja gedacht - werden sich über eine zusätzlich vorgeschaltete Seite wohl kaum übermäßig aufregen. Besser jedenfalls, als sie ganz auszuschließen oder ihnen eine Liste verschiedener Auflösungen zu präsentieren. Der weitaus größte Teil der Besucher, also der MIT Javascript, wird bei entsprechender Verzweigung von der vorgeschalteten Seite ja sowieso nichts mitbekommen.

4. Kritikpunkt "Entweder macht man ein elastisches oder ein fluides oder ein fixes Layout."

4.1. Ich bin ja kein Fachmann für Liquid, Fluid- und sonstige selbstanpassende Layouts, aber wie schon gesagt, für mich sehen diese eigentlich fast immer gleich aus - oben Kopfzeile, unten 1 bis mehr Spalten, und fertig - bitte korrigiert mich, wenn ich da falsch liege, vielleicht gibt es ja gute Gegenbeispiele, dann bitte mit Link, ich lass mich gerne überzeugen. Dass diese Layouts in vielerlei Hinsicht die am meisten ausgereiften Lösungen sind, mag sein. Dennoch sehe ich nicht (zumindest noch nicht), warum es keine Berechtigung geben darf für Webseiten, die eben NICHT durch ein einfaches Spaltenlayout gelöst werden können. Aber vielleicht ist ja mit Fluid, Elastic, Liquid und Co tatsächlich mehr möglich, als ich glaube.

4.2. Vorgehaltene Bilder müssen eine gewisse Mindestgröße haben, damit sie bei Vergrößerung auf sehr großen Bildschirmen nicht pixelig werden. In Hinblick auf die auch in der kritik immer wieder gerne genannten mobilen Endgeräte wahrscheinlich nicht gerade eine performante Lösung.

4.3. Ich habe noch ein Argument gegen Liquid Layouts gefunden, kann aber sein, dass das auf Elastic Layouts so nicht mehr zutrifft?

Möglicherweise sind meine Argumente ja auch alle Schwachsinn, aber man mag mir zugestehen, dass ich die Kritik zumindest skeptisch betrachte.

zum Schluss @Jens:

liege ich etwa so falsch mit meiner Vermutung, dass du zum Zeitpunkt deines ersten Postings nicht bis zur eigentlichen Viewportweiche vorgedrungen warst? Zitat aus deinen ersten Posting:

Und btw: welcher Nutzer sucht sich denn die Breite seines Monitors aus? Das müffelt doch nach 1997, nur ein wenig modifiziert. Früher sagte man dem Nutzer, er solle sich einen anderen Browser installieren oder er mußte erst auf einen Begrüßungsbildschirm klicken. Heute soll er dann erst die Größe seines Bildschirms angeben?

Sorry, selbst auf die Gefahr hin, hier wieder etwas vom Zaum zu brechen, das ich eigentlich gar nicht will, aber da MUSS ich nun noch mal erneut nachhaken, denn dieser Absatz hat mich nun wirklich sehr geärgert: Er ist nicht sachlich, sondern schlicht falsch und zudem polemisch. Falsch, weil ich genau dieses Auswählen aus einer Liste von Auflösungen mit meiner Vieportweiche eben vermeiden will. Und polemisch weil - naja, die Bemerkung über gewisse Gerüche aus alten Zeiten tut so ihre Wirkung. Dass sich bei so etwas in mir der Verdacht regt, dass der Kritiker entweder nicht richtig oder nicht bis zum Ende gelesen hat, oder aber nur noch einen draufsetzten wollte, oder sogar beides, sollte nachvollziehbar sein. Leider habe ich mich zu einer Betitelung deiner Person hinreißen lassen, die dann auch nicht mehr sonderlich kommunikationsförderlich war. Ich entschuldige mich dafür - doch wie gesagt - wie man in den Wald hineinruft...