Hallo,

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.

Damit hast Du ja eigentlich recht, auch wenn es wohl Viele für überflüssig, doppelt und nicht ins Design passend ansehen.

Tja, das lässt sich schlecht verhindern. Im Übrigen denke ich nicht, dass ein zusätzlicher breadcrumb trail zur Orientierung überflüssig ist - aber das hängt von der Sitestruktur ab. Verschachtelte Sitestrukturen sind mit Frames nicht einfach intuitiv zu lösen, da helfen solche Pfadangaben durchaus, ganz unabhängig von der Nachlade-Problematik.

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

Dem steht jedoch entgegen, daß die meisten Browser nichts davon haben und das Frameset erneut nachgeladen werden muß.

Deshalb liegt es eher näher, auf automatische Weiterleitungen zu verzichten.

Und wer die Seite ohne Frameset nutzen will, kann dies bei meinem Script auch tun, nachdem er sie lokal gespeichert hat...

Solche umständliche Lösungen würde ich den Benutzern möglichst nicht zumuten. Im Idealfall müsste eine Kaskade von Links angeboten werden, um die gängigen Probleme von Frames umgehen zu können:

• Ein breadcrumb trail mit Frameset-URLs, falls Frames zur Verfügung stehen und gewünscht sind - die Notwendigkeit kann nicht überprüft werden.
• Ein breadcrumb trail mit direkten URLs zu den Verzeichnisdokumenten, welche meinst als Navigationen fungieren (logisch gesehen ein rel="up toc" o.ä.), falls Frames nicht zur Verfügung stehen oder unerwünscht sind - dies ist ansatzweise mit noframes lösbar, aber generell ist die Notwendigkeit nicht überprüfbar.
• Ein Link, um das aktuelle Dokument im Frameset anzuzeigen - ist immer nötig, wenn Frames zur Verfügung stehen und per JavaScript-Überprüfung kein Frameset nachweisbar ist, aber generell ist die Notwendigkeit nicht überprüfbar.
• Ein Link, um das aktuelle Dokument einzeln anzuzeigen - ist immer nötig, wenn Frames zur Verfügung stehen und per JavaSscript-Überprüfung das Frameset nachweisbar ist, aber generell ist auch hier nicht möglich, zuverlässig zu überprüfen, ob der Link angezeigt werden sollte oder nicht.

Das ist insgesamt Overkill und nicht praktikabel.
Einiges ließe sich bspw. so lösen:

<script type="text/javascript">
if (parent.navigation)
 document.write('<p id="footer"><a href="inhalt.html" target="_top">Dieses Dokument einzeln und außerhalb des Framesets zeigen (beispielweise zum Drucken)</a></p>');
else
 document.write('<p id="footer"><a href="frameset.html?'+escape(location.pathname)+'" target="_top">Dieses Dokument im Frameset mit Navigation anzeigen</a></p>');
</script>

Deckt aber nur einige wenige Fälle ab, ohne JavaScript läuft auch nichts. Das Herumdoktern an Symptomen bringt hier wenig.

Aber mich stört doch mehr, wenn zunächst die Standardseite des Sets geladen wird und danach erst die eigentliche Seite.

Ja, daher mein Rat, diesen Part serverseitig zu lösen.

Die Abfrage von navigator.appName ist letztlich sinnfrei

Das sehe ich nun in diesem Fall aber nicht so. Wenn sich z.B. ein Opera als IE ausgibt, bekommt er die IE-Routine, mit der er auch etwas anfangen kann.

Ärgerlich, damit nützt deine präferierte Lösung faktisch noch weniger Besuchern.

Es geht mir hierbei lediglich darum, dem IE nicht die Alternativroutine vorzusetzen, da sie bei ihm nicht funktioniert.
Und den IE kann man damit doch zuverlässig erkennen, oder irre ich mich hier?

Falls du fragst, ob du sicher sein kannst, dass jeder MSIE auch diese Kennung sendet: Du bist nicht von Proxies gefeit, welche nachträglich Scripte einbinden, um diese Objekte zu überschreiben, sodass sie unbrauchbar werden. Zuverlässigkeit ist somit Definitionssache.

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.

zugegeben... aber ich möchte mit meiner Routine ja auch fremde Framesets sprengen. Wenn hier Jemand eine Möglichkeit kennt, wie man die Anzeige im fremden Frameset zuverlässig ohne Fehler bei der Domainüberschreitung erkennen kann, wäre ich sehr froh.

Mir ist auch keine robuste Methode bekannt, außer auf Frames zu verzichten, sodass die standardmäßigen Abfragen à la top!=self funktionieren. Ich muss auch gestehen, dass ich es sowieso nicht für essentiell erachte, solche Scripte einzusetzen. Das Überprüfen der Referrer und das eventuelle Verschicken von freundlichen Hinweisen hilft in der Regel.

Grüße,
Mathias