Sind Iframes eine schreckliche Idee?

Ich baue ein Widget und verwende Iframes, um Inhalte darin darzustellen. Irgendwann könnte ich anfangen, HTML und JS von Drittanbietern zu bedienen, also dachte ich, dass Iframes eine gute Idee wären.

Es macht das Widget Javascript ein wenig komplizierter, und ich bin besorgt, dass dies nicht die beste Implementierung sein könnte.

Hast du irgendeinen Ratschlag? Es wäre eine große Hilfe zu hören, was andere über Iframes denken.

0

15 Antworten

Eine Sache, die ich kürzlich entdeckte, ist, dass ASPX-Seiten, die in Iframes eingebettet sind, manchmal Probleme mit dem Verlust von Cookies haben, was zu einem verlorenen Sitzungszustand in einer Anwendung führte, an der ich beteiligt war.

Für mich war es in einem Szenario, in dem ein anderer Entwicklungsladen eine meiner ASPX-Seiten auf einer eigenen Seite konsumierte. Dies bedeutet, dass wir auf separaten Servern waren, die möglicherweise nicht herausragend sind.

Anscheinend wurde dies durch die Elternseite verursacht, die Cookies für die untergeordnete Seite ablehnt ... Wie der Sitzungscookie geht, geht auch die Sitzung.

The specific mechanics of how this works are a little involved: More Details

Dieses Problem hatte keinen Einfluss auf FireFox, aber es tauchte in IE7 auf und es war ein echtes Mysterium für ein paar Stunden.

Außerdem muss ich dem Artikel, auf den ich oben Bezug nahm, in einem Punkt widersprechen. Der Artikel besagt, dass Sie dies nicht erhalten, wenn die enthaltene Seite auch eine ASPX-Datei ist. In diesem Fall war das nicht richtig, da beide Seiten ASPXS waren.

Das wirft Zweifel auf alles andere, was der Artikel über diese Situation sagt, aber es hat zu einer Lösung geführt, also ist das auch etwas.

Wie der Artikel vorgeschlagen hat, habe ich den folgenden Code eingefügt, der einen p3p-Header (Privacy Preferences Project - ich hatte noch nie davon gehört) in das Init-Ereignis der Seite injiziert hat:

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

... Und das hat das Problem behoben.

0
hinzugefügt

Persönlich würde ich es vermeiden wenn Sie ohne zu viel Aufwand können. Wenn Sie Javascript verwenden (oder AJAX, wenn Sie sie dynamisch laden müssen), können Sie ganz einfach einfach ein div verwenden und den Inhalt nach Bedarf ändern. In einigen Fällen wird Ihnen dies viel mehr Flexibilität und JS vereinfachen, besonders wenn es viel gibt der Interaktion zwischen Ihrem Widget und dem Rest der Seite.

Das heißt, ich würde beide Optionen untersuchen, und wenn der JS-Pfad zu kompliziert oder zu kompliziert erscheint, gehen Sie einfach mit iframes.

0
hinzugefügt

Eine gute Option ist die Verwendung der CSS-Überlaufeigenschaft. Der Standardwert ist sichtbar, Sie können ihn jedoch auf "Versteckt", "Bildlauf" oder "Automatisch" festlegen. Ich würde Auto in Ihrem Fall verwenden. Wenn dein Inhalt zu groß wird, sieht es so aus, als ob du einen iframe hast, aber er ist immer noch auf der Seite.

see: overflow property

0
hinzugefügt

Technisch gibt es mit iFrame nichts gegen Alternativen. Aber semantisch gibt es Böses.

Das Web basiert auf HTTP, einem Protokoll, das besagt, dass eine gegebene URL immer zu einer eindeutigen Ressource führt.

Mit iFrame können Sie mehrere Ressourcen, die in Webseiten hinter einer URL zusammengefasst sind, für alle bereitstellen. Wenn Sie Bedenken haben, wie das Web wachsen soll, ist das mühsam. Für die Suchmaschinenroboter ist es außerdem schwierig.

0
hinzugefügt

Hängt davon ab, was das Widget tut. Iframes haben ihren Platz, aber sie verursachen nur wenig Layout-Kopfweh (ganz zu schweigen davon, dass Ihre JS komplizierter werden), so dass die meisten Leute sie meiden, es sei denn, dies ist absolut notwendig.

0
hinzugefügt

Es gibt nur eine "wirklich schlechte" Sache mit ihnen, die mir bekannt ist.

Wenn Ihr Drittanbieter JavaScript ausführt, versucht das, sein DOM etwas zu früh zu modifizieren ... IE6 und IE7 werden das ach so wenig hilfreiche " Operation abgebrochen " Fehler, dann nicht nur die iframe, aber die gesamte umgebende Seite . (z. B. Ihre Website erscheint unten)

Es ist nicht in IE8 behoben, aber der Absturz wird besser behandelt.

0
hinzugefügt

iframes, wie Frames, sind nur Steuerelemente, die für die jeweilige Aufgabe verwendet werden. Als solches ist es weder gut noch schlecht an sich, sondern könnte je nach der Aufgabe und den Anforderungen des Kunden gut oder schlecht sein. Soweit ich weiß, können alle modernen Browser (und Nicht-Linux-Benutzer) Iframes problemlos "sehen und konsumieren".

0
hinzugefügt

Nein, mit iframes ist nichts falsch. Iframes sind wahrscheinlich eine bessere Idee, wenn Sie beginnen, Inhalte von Drittanbietern zu liefern.

Die kommende HTML5-Spezifikation plant auch, mehr Sicherheitsfunktionen in iFrames für solche Situationen zu erstellen, daher würde ich es als gute Praxis ansehen, sie jetzt auch zu verwenden.

0
hinzugefügt
I +1 hier - der einzige Vorbehalt ist natürlich, sicherzustellen, dass die Verwendung wirklich ideal ist (dh, anstatt einfach Ajax zu verwenden, um die benötigten Daten zu greifen - der Server kann immer den "Inhalt von Drittanbietern" packen und analysieren und sein über Out-of-Band-Aufrufe abgerufen werden).
hinzugefügt der Autor Jason Bunting, Quelle

Nicht unbedingt, solange der Inhalt im Iframe vorhersehbar ist.

0
hinzugefügt

Bevor XMLHTTPRequest weit verbreitet wurde, verwendeten die Benutzer eine Kombination aus JavaScript und Iframes, um Inhalte auf dynamische Art und Weise zu präsentieren, ohne vollständige Seitenaktualisierungen durchzuführen.

Es gibt viele Informationen über die Entwicklung von Websites auf diese Weise, so dass Sie eine relativ einfache Zeit haben sollte, um einen Workaround für viele der Fehler zu finden, die Sie wahrscheinlich treffen werden.

Die einzige Sache, die ich als Schmerz empfinde, ist die domänenübergreifende Verwendung von JavaScript in iframes. Wenn die Seite, die Sie in den iframe einbetten, aus einer anderen Domäne als der "übergeordneten" Seite stammt, haben Browser Sicherheitseinschränkungen, die es Ihnen erlauben, auf die eine Seite zuzugreifen. Der Trick besteht darin, beide Seiten zu deklarieren

document.domain = 'somedomain.com';

Im Web gibt es viele Möglichkeiten für diese Art von Problemumgehung.

Viel Glück!

0
hinzugefügt
Ich glaube, dass sie document.domain nur als Domäne höherer Ebene ändern können - d. H. Www.acme.com kann die Domain zu acme.com ändern, aber nicht zu google.com. Dies hilft nur Iframes über Unterdomänen einer einzelnen Domäne zu kommunizieren. (Ich könnte mich irren, aber daran erinnere ich mich)
hinzugefügt der Autor Josh, Quelle
@Josh - Sie haben recht, die document.domain funktioniert nur für Seiten in derselben übergeordneten Domain, aber in einer anderen Subdomain.
hinzugefügt der Autor Livingston Samuel, Quelle
@Josh Du hast recht, aber du kannst immer window.location.href verwenden.
hinzugefügt der Autor nyuszika7h, Quelle

Meiner Erfahrung nach sind Iframes entweder Hacks oder Zeitsparer - stellen Sie sicher, dass sie aus diesen Gründen notwendig sind, wenn Sie sie verwenden. Wenn Sie die Kontrolle über den Inhalt haben (oder Kontrolle durch Spiegelung oder Scraping erlangen), sollten Sie AJAX oder serverseitige Includes in Betracht ziehen, um externe Daten auf die Seite zu ziehen und sie von dort wegzuziehen - es wird flexibler, mehr robust und am Ende leichter zu verwalten.

0
hinzugefügt

Ich werde mit der Mehrheit nicht übereinstimmen und sagen, dass Ja, Iframes eine absolut schreckliche Idee sind. Jeder, der schon eine Weile in der Web Design Community gearbeitet hat, wird zustimmen, dass Iframes pure Bösheit sind und vermieden werden sollten, es sei denn ABSOLUT .

Ich vermute, dass sie schlecht sind, weil sie das Navigationsmuster einer Webseite brechen. Durch Verwendung eines Iframes können Sie die Vor- und Zurück-Schaltflächen in Browsern effektiv unterbrechen und Ihre Benutzer verwirren. Es bricht die gesamte Idee hinter dem HTTP-Protokoll; dass eine URL immer zu einem eindeutigen Ort führt. Wenn der Iframe ein Pferd wäre, hätte er sich längst zurückgezogen. Es gibt andere Möglichkeiten, Inhalte dynamisch bereitzustellen, und diese sollten stattdessen verwendet werden.

Wenn Sie ein Widget erstellen, verschwinden die unmittelbaren Bedenken bei der Verwendung von iframes (schlecht für Suchmaschinen, schlecht für Bookmarking usw.), aber so oder so würde Content besser dynamisch oder sogar in einem neuen Fenster bedient werden anstatt in einem iframe.

0
hinzugefügt
-1 wie in einer anderen Antwort gesagt: "Es ist weder gut noch schlecht an sich, aber könnte gut oder schlecht sein, basierend auf der vorliegenden Aufgabe". Außerdem ist das Problem mit der Vor- und Zurück-Taste nicht spezifisch für Iframes, es tritt auch bei anderen dynamischen Inhalten auf.
hinzugefügt der Autor Christophe, Quelle

Betreff: "die gesamte Idee hinter dem HTTP-Protokoll; dass eine URL immer zu einem eindeutigen Ort führt"

Ich unterstütze mein gesamtes CMS von derselben URL aus für Sicherheit und Skalierbarkeit (hauptsächlich POST statt GET-Parameter). Ich möchte keinen sicheren Inhalt ohne Authentifizierung sehen, und ein Versandsystem erleichtert mir die Entwicklung, da ich mich nicht um die Authentifizierung für jede neue Seite kümmern muss.

Auch für einige Anwendungen ist SEO nicht anwendbar (z. B. für webbasiertes ERP).

Ich benutze einen iFrame, um Inhalte von einer PHP-generierten Assembly-Struktur bereitzustellen. Ich möchte nicht, dass der Baum (und die Knotensichtbarkeiten) aktualisiert werden, wenn der Benutzer Details für ein Teil/eine Baugruppe anzeigen möchte.

0
hinzugefügt
Ich bin froh, dass ich keiner deiner User bin! (Das kann nicht bei all gespeichert werden!)
hinzugefügt der Autor SamB, Quelle

Es gibt einige Probleme mit der Benutzerfreundlichkeit und Zugänglichkeit bei iframes . Einige Browser und Screenreader können keine Iframes anzeigen. Daher sollten Sie alternativen Inhalt bereitstellen:

<iframe src="content.html">
    
This content will only be displayed by browsers that do not support iframes. You should provide a link to the content, or in your case an alternative way to use your widget.

</iframe>

Wenn Sie damit beginnen, Inhalte von Drittanbietern zu liefern, sollten Sie nach dem Ladevorgang auf den iframe-Fokus achten. Während es für normale Benutzer eine kleine Belästigung ist, kann es für Benutzer, die mit Screenreadern surfen, sehr verwirrend sein.

0
hinzugefügt

Es gibt ein signifikantes Problem mit Iframes, das kaum Erwähnung findet, aber das Stopfen von mir behebt.

Unser Kollege hat sein ganzes Leben lang in eine sich dynamisch verändernde Datenbank investiert, die wir in Google Docs-Tabellen geladen haben, die wir dann auf unserer Seite zusammen mit vielen unterstützenden Materialien anzeigen.

Es gibt absolut nichts, was jemanden daran hindert, den iframe-Code aus meiner Seitenquelle zu holen und ihn auf ihre Seite zu schieben. Jetzt bekommen sie alle unsere Daten, die bis vor ein paar Minuten aufgefrischt wurden, für absolut nichts auf ihrer Seite.

Wenn ein Google Iframe an eine bestimmte Domain gebunden wäre, würde das in seinen Spuren stoppen.

Irgendwelche Ideen, helle Funken?

0
hinzugefügt
Das ist ziemlich alt, aber wenn Sie immer noch nach einer Lösung suchen, dann kann ich daran denken, X-Frame-Option Header zu verwenden, um einzuschränken, wer den iframe laden kann. Jetzt können Sie diese Kopfzeile offensichtlich nicht in einer Google Docs-URL anwenden, da Sie sie nicht steuern. Aber was Sie tun können, ist, anstatt eine Google Docs-URL direkt zu verwenden, mit Ihrer eigenen URL, die eine Server-Seite Redirect auf Google Docs URL ausführt. Und dann können Sie die richtige X-Frame-Option Kopfzeile auf Ihre eigene URL anwenden
hinzugefügt der Autor Suhas, Quelle
JavaScript - Deutsche Gemeinschaft
JavaScript - Deutsche Gemeinschaft
3 der Teilnehmer

In dieser Gruppe sprechen wir über JavaScript.