nicht angemeldet
Hallo,
Serverseitig wird das HTML zusammengebaut, damit clientseitig bestimmte CSS-Regeln angreifen können. Dazu muss, wie gesagt, der Text getrennt werden und in unterschiedlichen Elementen für die jeweiligen Spalten untergebracht werden.
sehr schön, dann baue doch mal serverseitig das passende HTML zusammen, welches berücksichtigt, dass die Höhe des Anzeigebereichs im Browser bei mir Wert XYZ und bei meinem Nachbar 2xXYZ beträgt. Ich bin gespannt ;-)
Mir ist klar, dass diese Anforderung auf diesem Weg nicht erfüllt werden kann. Aber meiner Wahrnehmung nach auch nicht zufriedenstellend auf andere Weise. Das ist sowieso nur die Spitze des Eisbergs.
Ich lasse mich sogar zu der Behauptung hinreissen, dass ein wirklich sinnvolles mehrspaltiges Layout bei längeren Texten nur mit der Hilfe von JavaScript - ähnlich dem Beispiel der IHT-Website - möglich ist.
Auf was du mit der IHT-Seite hinweisen wolltest, ist mir erst jetzt klargeworden, da die Webseite eine offenbar unsinnige Browserweiche hat. Der Clou daran ist eben, dass dort der Text überhaupt nicht aufgeteilt wird, sondern in jede Spalte einmal komplett geschrieben wird, woraufhin die Spalten so positioniert werden, dass nur die jeweiligen Ausschnitte zu sehen sind (top:-4186px usw.).
Ich verstehe aber nicht, was daran der entscheidende Vorzug ist. Diese Lösung reagiert auf den einen Faktor Anzeigehöhe, was eine serverseitige Lösung, die sich darüber keine Gedanken macht und die kein »Blättern« erlaubt, logischerweise nicht kann. Dafür geht sie von einer festen Breite aus. Dafür muss sie es zwangsläufig unterbinden, dass der Benutzer über den Browser die Schriftgröße und verwandte Einstellungen verändern kann (und bietet notdürftig eine JavaScript-Skalierung an, bei welcher die Proportionen nicht berücksichtigt werden). Dafür muss sie die Anzeige pixelgenau abschätzen können, somit ist das Layout sehr anfällig gegenüber abweichenden Konfigurationen. Dafür ist das gesamte Konstrukt nicht linearisierbar, weil der Text dreifach im Dokumentbaum steht (besonders spaßig beim Lesen über Screenreader). Wenn man also schon von Seiten der Usability und der Flexibilität argumentiert, dann hat eine JavaScript-Lösung dieser Art letztlich keine entscheidend besseren Karten. Sicherlich ist die IHT-Umsetzung nicht die bestmögliche Implementation des Konzepts, aber die Nachteile sind eben größtenteils konzeptionelle.
Es ist wenig sinnvoll, wenn die einzelnen Spalten länger als die Anzeigeflächenhöhe sind, bei jeder Spalte runter und dann, für die jeweils nächste Spalte, wieder hochscrollen kann es ja auch nicht sein.
Das verstehe ich durchaus, ich sehe nur keine brauchbare Alternative, wie es besser gelöst werden könnte, außer eben der besagten Trickserei mit Nebenwirkungen. Verglichen mit der in diesem Punkt defizitären serverseitigen Lösung sticht jene JavaScript-Lösung, die gerade einmal auf die zur Verfügung stehende Höhe reagiert (bzw. reagieren kann), eben nicht durch allgemeine Flexibilität hervor.
Natürlich darf da jeder gern anderer Meinung sein, aber wenn ich etwas mehrspaltig am Bildschirm lesen will, dann sollte die Höhe der Spalte maximal die Höhe des Anzeigebereiches im Browser haben
Das ist wie gesagt nicht der einzige zu berücksichtigende Umstand, wenngleich ein wichtiger. Aber vor dem Hintergrund der Probleme, die bei der Lösung dieses Teilproblems auftreten, bleibt es letztlich unmöglich, eine in jedem Fall lesbare und flexible Raumaufteilung zu erzielen. Damit wären wir wieder einmal bei der Erkenntnis, dass ein solches Spaltenlayout im Web ziemlicher Käse ist.
Mathias