Hellihello Mathias,

BTW: kannst Du in Deinem Browser zwei Tabs nebeneinander darstellen?

Bei einem Browser, der nicht nur Tabs, sondern integrierte Fenster unterstützt, ja.

Aber jetzt wirfst du Schreiben und Lesen des Webs durcheinander.

Ich wollte darauf hinaus, dass Tabs und Windows was anderes sind. Gunnars Frage war ja klar umgrenzt: was können Frames, was nicht anders geht.

Frames nehmen an, dass Tabs und Zurück-Navigation beim Wechseln zwischen Dokumenten einen signifikanteren Mehraufwand mit sich bringen. Nun sind diese Methoden viel flexibler, weil die »Parallelisierung« vom Nutzer vorgenommen wird.

Wenn Ersteller und Nutzer aber in einer Feedbackschleife hängen (Intranet, Eigennutz)?

Wie gesagt, man arbeitet ständig mit mehreren Tabs und wechselt zwischen ihnen - selbstständig als Anwender.

Du unterstellst hier ein StandardUserVerhalten.

Ein Frameset muss ein Webautor erstellen, die Zusammenstellung macht ein Autor einmal. Dass dabei gerade »logisch voneinander unabhängige Inhalte« vereinigt werden, ist eher die absolute Ausnahme.

Es geht nicht darum, wie oft das geschieht, sondern wie und ob es möglich ist und wenn ja, ob nur mit Frames. Dies war eine Antwort auf Gunnars konkrete Frage.

Während vor ein paar Jahren noch die autorenseitige Parallelisierung dominierte (target="_blank" für jeden »externen« Link, Popups allerorten, Frames sowieso), stelle ich eine radikale Verlagerung fest, die den Anwender ermächtigt.

Nun, externe Links sollen ausgezeichnet sein. Aber anders als mit target.

Dafür, dass diese Konzepte vor ein paar Jahren dermaßen hartnäckig vertreten wurden (»kein externer Link ohne target="_blank"!«

... externe Links als solche kennzeichnen...

, alle möglichen Unterinformationen wurden in Popups untergebracht), sind sie absurd sang- und klanglos abgetreten.

Doch aber nur, weil Popups geblockt werden, vom FF, von der GoogleToolbar etc. - wegen Werbungsmissbrauch.

Früher sah man das offenbar alles paternalistischer. Diese historische Perspektive relativiert für mich vieles.

Infos werden nach wie vor vor Ort in kleinen Fenstern angeboten. Mittlerweile als eingebautes absolut positioniertes Div per Javascript. Solche Vor-Ort-Deklarationen oder "steht-auf-einem-anderen-Blatt" machen ja oft auch viel Sinn.

Nein, zumindest nicht die Aufteilung Header fixe Höhe, Footer fixe Breite, Navi-links und News-rechts fixe Breite, Content den Rest in der Mitte, Scrollbar für den Content im Content-Fenster und sonst nirgends.

Das müsste gehen, die Frage ist, welchen Sinn so ein Layout hat...

Die Frage war, was geht mit Frames, was ohne nicht geht. Das o.g. Layout erklärt sich in seinem Sinn doch fast von selbst: Header (statische oder dynamische Kopfzeile) und Footer (s. Header) sind doch bekannt bei Dokumenten. Die Aufteilung einer Seite in drei Spalten wird oft betrieben. O.g. geht nicht, weil der Content seine Größe nicht kennt, und die müsste er kennen, um scrollbar zu werden (zumindest seine Höhe müsste er wissen).

Dieses div ist für den hier viel erwähnten Client so nichtssagend wie ein frameset

Der Vorwurf müsste eher heißen, die ul-Navigation ist nichtssagend, deshalb arbeitet man auch am nl-Element und nicht an derWirklicheDokumentinhaltOhneNavigation.

Nun, wieder auf Gunnars Frage zurückführen bitte. Wenn wir perspektivisch diskutieren, könnte man auch vorschlagen, für Frames reservierte Attributwerte vorzuschlagen:
title="header|footer|navi1-navi3|content|news|advertisement".

Ansonsten erwähnte ich ja auch, analog zum <nl>, dass ich mal las, dass <section> als umgegendes Element für <h?> und seine Absätze kommen soll.

Dank und Gruß,

frankx