Hallo Stefan,

Weil, irgendwann ist es mal an der Zeit, konsequent zu sein und
zu sagen, dass ein Browser mit einem Anteil von rund 5% nicht der
ausschlaggebende Punkt sein kann.

Siehe mein Posting an Soenke. So koennt ihr euch natuerlich rausreden, und ein Layout, dass im Mozilla und im IE 6 gut aussieht, bekomme ich sogar ohne fremde Hilfe hin *g*. Ich moechte auch vermeiden, hier schon wieder die unselige NS4-Diskussion loszutreten, davon haben wir genug im Archiv. Nehmt es halt einfach als gegeben hin, dass ich es mir bis auf weiteres nicht leisten will, mehreren tausend SELF-Usern nur noch einen Scherbenhaufen am Bildschirm zu praesentieren.

Will sagen, es geht hier nicht darum, Leute zu benachteiligen,
sondern die Entscheidung zu treffen, ob 5% wirklich als Argument
für die "Benachteiligung" des Restes ausreichen.

Das wuerde ich auf keinen Fall wollen! Es geht nur darum, nicht 100% auf neueste Technik zu setzen, sondern auf moeglichst "intelligente" Weise eine Hintertuer-Rueckwaertskompatibilitaet anzubieten.

http://aktuell.de.selfhtml.org/tippstricks/css/ausrichtung/ und
text-align:center; sollten doch ausreichend sein oder was genau
meinst Du?

Jo, da hab ich natuerlich nicht geguckt. Das darf ich ja noch gar nicht - ist ja noch gar nicht offiziell *g*.

Beide Bereiche bekommen ein umgebendes DIV, einer der Bereiche
noch ein Extra-DIV und wenn man die Größe verändert, passen sich
beide Bereiche an.

So hab ich es auch geloest. Irgendwann hat man dann halt dreifach verschachtelte Divs, genauso, wie man frueher dreifach verschachtelte Tabellen hatte, um "Stabilitaet" in die Sache reinzubekommen. Die hohe Schule des schlanken Codes ist das dann aber auch nicht mehr so ganz.

Wie lösen Tabellen das Problem, dass die Navigation mit ausgedruckt
wird, weil sie in der einen Spalte steht? ;-)

Warum sollte ich Probleme loesen wollen, die ich gar nicht habe? Ich finde es das Normalste von der Welt, wenn beim Ausdruck einer Datenseite aus SELFHTML die Sublinks am Anfang mit gedruckt werden.

Wie lösen Tabellen das Problem, das sie sich nur bis zu einer gew.
Grenze skalieren lassen, falls das Anzeigemedium zu klein ist? ;-)

Weiss ich jetzt nicht, wie du das genau meinst. Wer Angst hat, darf halt nur mit relativen Angaben arbeiten. Aber das ist bei positionierten Elementen nicht anders.

Wie lösen Tabellen das Problem, dass der Quelltext oft unübersicht-
lich für den Ersteller ist

Siehe oben - dreifach verschachtelte Divs werden bei unbedarften Wysiwyg-Juengern kaum fuer mehr Durchblick sorgen.

nimmst Du NC4 als Argument, und so ist die Sache letztendlich zum
Scheitern verurteilt.

Siehe die Kompromiss-Loesung von Herbalizer. Natuerlich ist es nur ein Kompromiss. Aber vielleicht kann man sogar noch ein bischen was daran optimieren.

Wo ist bei DTP die unbekannte Größe der Anzeigefläche
des Ausgabemediums,

Das Argument verstehe ich irgendwie nicht ganz (als Argument fuer Divs und gegen Tabellen) ...

wo benötigt man dort versch. Layouts für Print und Screen,

Benoetige ich zumindest nicht. Weiss nicht, kann sein, dass ich mal ein Stylesheet fuer print mit anbiete, aber ist mir nicht so wichtig. Und auch das verstehe ich irgendwie nicht ganz (als Argument fuer Divs und gegen Tabellen) ...

wo benutzen dort die Leser vielleicht UAs, bei denen
die logische Struktur von Belang ist und wo wird dort die Sache
für den Ersteller unübersichtlich, weil darin etliche miteinander
verschachtelte Tabellen stehen?

Das ist in der Tat ein Argument gegen Tabellen, vor allem gegen verschachtelte. Akustische Ausgabemedien, die tatsaechlich nach die HTML-Struktur parsen und dann versuchen, einem Zuhoerer die Struktur der Seite zu erklaeren - das ist uebel.

PS: Ich weiß nicht, ob Deine Entscheidung bereits gefallen ist.

Nein ;-)
Ich wollte einfach mal vorfuehlen und sehen, ob vielleicht einfach nur ich zu doof bin, um das gewuenschte Ziel zu erreichen. Belehrungen ueber die reine Kunst der Positionierung und ueber NS4 wollte ich eigentlich vermeiden in diesem Thread ;-)

viele Gruesse
  Stefan Muenz