nicht angemeldet
Hallo,
http://frames.jan-andresen.de/08_nt_5_skal.php verstehe ich schlichtweg nicht. »Die Definition des Framesets erfordert die Angabe von festen Fenstergrößen. Doch weder die Angabe in Pixel noch in Prozent nimmt Rücksicht auf die Inhalte der anzuzeigenden Seiten.« - Und bei CSS-Layout ist das anders? Da lassen sich Spaltenbreiten auch nicht flexibler festlegen, es sei denn, man verwirft das Spaltenkonzept.
CSS bietet mehr als nur Pixel und Prozent als Einheiten - insbesondere die schriftgrößenabhängigen Einheiten em und ex erlauben m.E. doch etwas mehr Flexibilität, nämlich die Anpassung einer Spaltenbreite an den enthaltenen Text unabhängig von der Schriftgröße.
Wenn ich ein Frameset mit zwei Spalten habe, also etwa das klassische Schema »Navigation links mit x Pixel, Inhalt rechts mit der verbleibenden Breite«, dann reagieren die Spaltenbreiten logischerweise nicht auf die Schriftgröße. Wenn ich die Schrift vergrößere und gleichzeitig unterschiedliche Fensterbreiten annehme, dann kommt es irgendwann dazu, dass die Zeilen extrem schmal werden. Beim längsten Wort hört das Gestauche auf und spätestens dann werden im linken Frame horizontale Scrollleisten angezeigt.
Der rechte Frame wäre noch besser dran, weil der linken Frame vielleicht eine vorgegebene Breite von 250-300 Pixel hätte. Damit wäre der rechte selbst bei extrem wirklichkeitsfremden 620 Pixeln Fenster(innen)breite geringfügig breiter. Insofern wäre eine kleine Fensterbreite an sich kein gravierendes Problem im Vergleich zur Textvergrößerung. Wenn man vorher nichts gequetscht hat und lange Wörter hat, kommt es schon vielleicht bei 150-prozentiger Vergrößerung zu einer horizontalen Scrollleiste im linken Frame. Da kann ein Frameset natürlich nicht mithalten. Allerdings besteht hier die Möglichkeit, die Framegrenzen beliebig zu verschieben und somit dem einen Frame vorübergehend die gesamte Breite zu geben und den anderen auszublenden.
Wenn dieses klassische Spaltenlayout nun mit float:left und bspw. width:12-15em bzw. margin-left:12-15em in CSS umgesetzt wird (im Prinzip kann aber höchstens geschätzt werden, wie breit ein bestimmter Text bei der Darstellung sein wird) und in der rechten Spalte nur frei fließender Text ist (dasselbe habe ich oben angenommen), dann ist es ebenfalls relativ unempfindlich gegenüber die gängigen Varianzen der Fenster(innen)breite. (Auf einem Mikrodisplay sind jegliche Layouts, die so arbeiten, hinfällig, das Argument zieht nicht.) Bei Schriftvergrößerung wächst die linke Spalte glücklicherweise mit, sodass bei entsprechender Breite Vergrößerungen bis zu 200% problemlos möglich sind. Wenn vergrößerte Schrift und schmale Fenster zusammentreffen, bleibt die linke Spalte mit fester em-Breite standhaft. Breite Worte bzw. Objekte daneben in der rechten Spalte fließen aus dem Container und erzeugen eine horizontale Scrollleiste. Letztendlich ist diese Zweispaltigkeit starrer als die des Framesets, deren Spaltenaufteilung sich wenigstens steuern und temporär außer Kraft setzen lässt (ob das nun gerade intuitiv ist, ist eine andere Frage).
Man könnte zwar Argumentieren, dass man CSS ja abschalten kann, was bei 200% Vergrößerung und mickrigem Display sowieso ratsam wäre, aber was zählt das? Dann könnte man auch mit abgeschalteten Frames surfen, das ist letztlich eine ähnliche Form, um erzwungene Mehrspaltigkeit, die sowohl beim beschriebenen Frames- als auch beim CSS-Layout vorliegt, zu verhindern.
Ich sehe, was solche extremen Situationen angeht, in denen Flexibilität wirklich eine Rolle spielt, keine großen Unterschiede zwischen einem Frames-Spaltenlayout und einem äquivalenten CSS-Layout. Der Frame-Verteidiger könnte argumentieren, dass er einfach den linken Frame verbreitert und somit die Schwelle, an der die Mehrspaltigkeit problematisch wird, nach oben setzt und sich somit der Schwelle des CSS-Layouts annähert.
Mathias