Hallo Armin,
http://www.grewe.co.uk/temp/w3-wide.jpg
Eine ewig lange Zeile, die nur unter Muehe zu lesen ist. Ziemlich grosse leere Flaechen zwischen den Inhalten.
Jaja, die Möglichkeit von max-width sollte bekannt sein. Beim MSIE meinetwegen über expressions o.ä., das ist wahrlich kein Umstand. Es gibt auch schöne Tabellenlösungen, die gut mit CSS-Layout kombiniert werden können und die Wartbarkeit und Knappheit/Aufgeräumtheit des Codes nicht sehr einschränken, damit wäre die Funktionalität von max-width prinzipiell ab Netscape 4 möglich.
Ach Du je, da werden halbe Worte verschluckt:
http://www.grewe.co.uk/temp/w3-narrow-moz.jpg
Wie gut dass ich die Schrift nicht etwas groesser gestellt habe.
Hey, wohin ist denn die Suche verschwunden?:
http://www.grewe.co.uk/temp/w3-narrow-ie1.jpg
Haeh? Was ist das hier unten links denn auf einmal?:
http://www.grewe.co.uk/temp/w3-narrow-ie2.jpg
Es ist genau das eingetreten was ich erwartet habe.
Ähm, letzteres ist offenbar beabsichtigt bzw. einkalkuliert. Wenn du das Fenster noch kleiner ziehst, springt auch die mittlere Spalte unter die linke. Was ist dagegen einzuwenden? Es bietet sich bei floats an, die Mehrspaltigkeit nicht zu erzwingen, wenn der Platz arg gering wird wie in diesem Fall, sondern einen Umbruch in Kauf zu nehmen. Besser als aus der Box hinauslaufender Text (rechte Spalte) oder mit overflow versteckter (linke Spalte, »da werden halbe Worte verschluckt«) ist es auf jeden Fall. Das ist ein prinzipieller Vorteil von float gegenüber klassischen Tabellenspalten, welche zwar bis zum längsten Wort bzw. Inhaltselement zusammengestaucht werden können, dann aber zwangsläufig horizontale Scrollbalken erzeugen. Floats hingegen sind da flexibler, wie auch immer man das bewerten will, ich halte es für vorteilhaft.
Und jetzt komm mir nicht mit "ja, wenn man da so extreme Einstellungen benutzt" an, das interessiert mich nicht.
Wieso nicht? Es ist eine Binsenweisheit, dass das Layout auseinanderfällt, wenn man den Viewport so klein zieht, dass die Spalten kleiner sind, als die längsten Wörter im Kontext ihrer Inhaltsstrukturen (hier z.B. Listen) verlangen. Anders herum ist es eine Binsenweisheit, dass es töricht ist, von angeblich unbegrenzt skalierbaren Layouts zu schwärmen, vor allem wenn es um elaborierte screen-Spaltenlayouts versus Mikro-Handhelds oder x-facher Vergrößerung geht. Bei Dreispaltigkeit sind die Grenzen schnell erreicht, darüber hinaus vermindert die schlechte Raumaufteilung entsprechend die Benutzbarkeit.
Dem ließe sich höchstens dadurch begegnen, radikal alle Mehrspaltigkeit linearisierbar zu machen, eine Position, die z.B. Thomas Scholz vertritt, siehe etwa http://www.beerdigungsinstitut-ludwig.de/. Die Seite kann ich hier relativ problemlos mit Opera auf 400% skalieren und das Fenster bis 250 Pixel Breite verkleinern. Zum Beispiel bei http://home.t-online.de/home/dj5nu/sterne.html sind es aufgrund der festen margin-left der rechten Spalte »nur« 300% und 390 Pixel, wobei dann die Hälfte des Bildschirms leer wäre. http://home.t-online.de/home/dj5nu/sterne-tourtermine.html erfordert schon 605px (bei vergleichsweise kleinen 1em-Einstellungen), hier ist die erzwungene Mehrspaltigkeit keineswegs von Vorteil.
Zum einen sehe ich die nicht als so extrem an (auf einem Handheld duerfte die Breite so ungefaehr hinkommen), zum anderen ist doch das Argument man muesse auf alle Moeglichkeiten vorbereitet sein.
Man kann sich im Idealfall auch darauf vorbereiten. Man könnte etwa ein Stylesheet mit media="handheld" anbieten, welches entsprechend die Mehrspaltigkeit entschärft; von der Praxistauglichkeit einmal abgesehen (CSS Mobile Profile existiert, ob das viele Geräte unterstützen, weiß ich nicht). Wirklich schön wäre es mit http://www.w3.org/TR/css3-mediaqueries/, da kann man Komposition und zur Verfügung stehende Breite direkt aneinanderkoppeln.
Mathias
--
»The Web is the minimal concession to hypertext that a sequence-and-hierarchy chauvinist could possibly make.« (Ted Nelson)