Wage ich zu bezweifeln. Soviel Bescheidenheit muß sein - ich habe sonst nicht so viel davon. >;->

Ich kann aber gerne mal einen "komprimierten" PHP-Source veröffentlichen.

Das ist ja schon mal ein Problem, PHP? Ich dachte an eine HTML Seite.

Wenn ich auf http://coding.binon.net/dhtml/index.htm gehe, müßte das Frameset nachgeladen werden und wenn das Frameset vorhanden ist, müßte ich die Unterseiten über das Memü bookmarken können, da muss wohl eher ein mod_rewrite Mechanismus eingebaut werden?

Und wenn man bedenkt, wieviel Aufwand generell in einem auch nur etwas umfangreicheren Webauftritt steckt, ist er sogar kaum messbar.

Ich deute das so, das du wenn du von den nicht vorhandenen Nachteile sprichst, du damit immer eine dnaymische, "etwas umfangreiche" Seite meinst.  Das kann ich zumindest ein bisschen nachvollziehen, auch wenn ich nach wie vor nicht überzeugt davon bin, das damit so leicht alle Nachteile von Frames beseitigt werden können.

Allerdings hat auch die überwiegende Mehrheit der Desktop-Applikationen fixe Bereiche um einen wechselnden Content herum. Ja, sogar bei Browsern ist es so (Menü, Toolbars, Sidebar, Statuszeile (gern auch bestückt mit Extension-Icons), ...). Also *soooo* ungewohnt kann dieses Konzept selbst für die User nicht sein, die Frame-Seiten nicht kennen (wobei: Für Web-Entwickler ist sicherlich dennoch die MSDN-Library Pflicht).

Das ist genau so ein Beispiel, wo ich mich diese Woche sehr geärgert habe. Die Seiten waren bis vor kurzem noch durchaus nutzbar (auch auf meinem alten Rechner mit einem 15" Monitor), trotz Frames. Als ich diese Woche mal dort was nachschauen wollte, ging fast gar nichts mehr, mein Monitor ist zu klein (17" mit einer 1024'er Auflösung):
http://null

und der andere Punkt. Klar hat meine Anwendung ein Menü und Systemelemente, aber ein Internetseite ist keine Anwendung, ich habe mit einem Frameset eher eine verschachtelte Anwendung, wie z.b. ein Execel Objekt in einem Worddokument. Das geht aber macht keinen Spaß.

Struppi.