Framepage in Frames aufrufen

[molily]

Hallo Ingo,

diese methode hatte ich früher auch benutzt, bis ich nach recht viel experimentieren und suchen eine lösung gefunden hatte, die z.b. keinen abbruch bei der framenamenabfrage über die domaingrenze hinweg verursacht und bei modernen browsern außer dem ie nicht erst das standard-frameset anzeigt:
http://www.1ngo.de/web/framesets.html

| Framesets sind zwar vom W3C als deprecated (missbilligt) eingestuft und im aktuellen XHTML Strict nicht mehr zulässig

Frames sind nicht im Sinne der Specs »deprecated«! Frames sind formal gesehen Teil der Transitional-DTD, weil sie eine reine Präsentationstechnik sind und somit tatsächlich nicht »Strict«. Wenngleich die Elemente (frameset, frame, noframes, iframe...) und Attribute (u.a. target) rund um Frames ebenso wie Deprecated-Elemente und -Attribute nur auf die visuelle Ausgabe ausgelegt ist und somit »presentational markup« sind, sind sie nicht »deprecated«.

Frames waren nie in den Strict-Varianten von HTML zulässig, insofern ist der Hinweis, dass Frames in XHTML 1.0 Strict nicht erlaubt sind, unpassend. XHTML 1.0 Frameset existiert. Der XFrames-Standard ist auf dem Weg. So what?(tm)

Ich wiederhole mich...
</archiv/2003/2/38526/#m211664>
</archiv/2003/3/40483/#m221914>

Zum Inhalt selbst:

Du schreibst:
»Man sollte daher entsprechende Vorsorge treffen und:

• auf jeder Seite Anbieterangaben und einen Link zur Navigation bzw. dem Frameset setzen oder
• serverseitige Lösungen verwenden, um eine Anzeige im Frameset zu realisieren oder
• das Frameset mittels JavaScript nachladen«

Dies sollte kein ausschließendes »oder« sein. Ein breadcrumb trail bzw. ein statischer Link, welcher die aktuelle Seite im Frameset nachlädt, sollte immer angeboten werden. Serverseitige Möglichkeiten sollten soweit wie möglich genutzt werden - sie sind immer zuverlässiger als Javascript. Javascript darf nur die optionale Sahnehaube sein.

Ich würde immer dazu raten, eine komplette Weiterleitung zu realisieren, und zwar mit location.href, nicht mit location.replace. Denn es gibt viele Fälle, in welchen die Seite bewusst außerhalb des Framesets gezeigt werden soll (Drucken, Skalieren, kleiner Bildschirm, ...). Dann ist es zumindest in einigen Browsern (dennoch leider zu wenigen) möglich, die Seite durch die Zurück-Funktion einzeln anzuzeigen. Des weiteren finde ich das Neubeschreiben des Fensters insofern unvorteilhaft, dass die URL dieselbe bleibt. Ich fände es angemessener, wenn möglich die »Frameset-URL« (frameset.html?seite.html) anzuzeigen, weil der Part des Generieren des Framesets serverseitig gelöst werden kann. Somit ist er nicht von JavaScript abhängig. Ansätze bietet http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/ - aber keinesfalls den noframes-Bereich leer lassen! Auch dort muss neben generellen Links am Anfang der Link zur als Parameter übergebenen Seite ausgegeben werden.

Generell sind solche automatischen Nachlade-Skripte arg problematisch, da es eben vorkommt, dass manche, um die Probleme von Frames zu umgehen, das Dokument bewusst außerhalb des Framesets ansehen wollen.

Die Abfrage von navigator.appName ist letztlich sinnfrei, siehe Archiv. Das Script ist in dieser Form nicht nachhaltig.

onerror = FremdURL ist insofern blöd, dass auch andere unkalkulierbare Fehler auftreten können und in diesen Fällen unpassend ist, die Funktion FremdURL auszuführen.

Was document.images damit zu tun hat, ist mir schleierhaft, speziell in der Funktion LadeFrame - man sollte auf die Methoden und Objekte prüfen, die benutzen zu gedenkt.

Grüße,
Mathias