onload-Handler für iframe per JS setzen

Hallo liebe NetzGemeinde,

ich habe diese Frage vor Monaten schon einmal mit anderen Worten für ein
ähnlich gelagertes Problem gestellt und damals auch schon eine Lösung von
Euch bekommen. Da ich es damals letztlich aber doch anders gelöst hatte,
fiel mir erst jetzt auf, dass die Lösung, die ich hier bekommen hatte, nur
im Firefox, nicht dagegen im IE 6 funktioniert.

Ich habe also ein Hauptdokument, in dem ein (unsichtbarer) iframe definiert
ist, der als Zwischenspeicher für an das Hauptdokument dynamisch
anzuhängende Inhalte dient: Ein im Hauptdokument angeklicktes Dokument wird
zunächst in den iframe geladen. Wenn es dort vollständig angekommen ist
(also onload), soll automatisch ein ebenfalls im Hauptdokument notierter
div-Bereich mit dem body.innerHTML des iframe.Inhaltes befüllt werden.

Martin, Du hattest mir damals geraten, dem iframe-Element ein id-Attribut zu
geben und dann den onload-Handler wie folgt daran zu binden:

<iframe name="Unterframe" id="Unterframe" src="#"></iframe>
<div id="detail">Hier soll der Inhalt des iframes ausgegeben werden.</div>
<script>
document.getElementById("Unterframe").onload = function(evt) {
document.getElementById("detail").innerHTML =
frames.Unterframe.document.body.innerHTML; }
</script>

Wie gesagt - im Firefox funktioniert das auch ganz hervorragend: Bei jedem
Dokumentaufruf innerhalb der Seite wird der iframe befüllt und anschließend
sein Inhalt im div "detail" ausgegeben. Aber zumindest der IE 6 feuert den
onload-Handler schon beim Laden des Hauptdokuments und dann nie wieder. Und
das, obwohl der iframe sehr wohl immer wieder neu beladen wird. Anscheinend
wird hier doch das falsche onload-Ereignis abgefragt, nämlich das des
Hauptdokuments? Wie lässt sich das in den Griff bekommen?

Danke und beste Grüße,
Frank

Hmm, niemand eine Idee? Naja, habs nun doch erstmal wieder mit dem nicht
standardkonformen iframe-Atrribut onload gelöst. Falls aber noch jemand eine
Idee hat - ich bin ganz Ohr!

In dem Zusammenhang noch eine andere Frage (wenn auch etwas off-topic): Muss
ich bei dem beschriebenen Mechanismus befürchten, dass Google & Co dies als
unzulässiges Cloaking ansehen und die Seite deswegen nicht crawlen?
Immherhin habe ich für den iframe width und height auf 0 sowie zusätzlich
style="visibility: hidden;" gesetzt. Wäre es besser, statt der
HTML-Attribute width und height die CSS-Eigenschaften zu verwenden, oder
werden diese durch Google (ebenfalls) ausgewertet? Wo finde ich evtl. gute
Infos zur Thematik?

Danke und Grüße,
Frank

Frank Glück schrieb:

In dem Zusammenhang noch eine andere Frage (wenn auch etwas off-topic): Muss
ich bei dem beschriebenen Mechanismus befürchten, dass Google & Co dies als
unzulässiges Cloaking ansehen und die Seite deswegen nicht crawlen?
Immherhin habe ich für den iframe width und height auf 0 sowie zusätzlich
style="visibility: hidden;" gesetzt.

Wenn du den Inhalt des iFrame per JS lädst bekommt google davon nichts
mit. Wenn der Link der das iFrame lädt, als Link erkennbar ist, dann
wird der googleroboter ihm folgen.

Struppi.

Hallo Struppi,

""J. Strübig"" <struebig (AT) uni-mainz (DOT) de> schrieb im Newsbeitrag

Frank Glück schrieb:
In dem Zusammenhang noch eine andere Frage (wenn auch etwas off-topic):
Muss ich bei dem beschriebenen Mechanismus befürchten, dass Google & Co
dies als unzulässiges Cloaking ansehen und die Seite deswegen nicht
crawlen? Immherhin habe ich für den iframe width und height auf 0 sowie
zusätzlich style="visibility: hidden;" gesetzt.

Wenn du den Inhalt des iFrame per JS lädst bekommt google davon nichts
mit. Wenn der Link der das iFrame lädt, als Link erkennbar ist, dann wird
der googleroboter ihm folgen.

Ok, das leuchtet mir ein, und der iframe wird ja auch mit normalen
HTML-Links beladen. Meine Frage bezog sich aber darauf, ob Google nicht auch
mit verschiedenen Routinen überprüft, ob die HTML-Elemente für Menschen
überhaupt sichtbar sind. Ich denke da neben den 0-Werten für Länge und
Breite sowie der invisible-Schaltung per CSS beispielweise auch an
entsprechend kontrastarme bzw. kontrastlose Farbwahl für Text und
Hintergrund. Das sind ja alles Parameter, die sich für einen entsprechenden
Parser noch recht unkompliziert ermitteln ließen ...

Danke und Grüße,
Frank