nicht angemeldet
Karl Heinz
Der Martin
Gunnar Bittersmann
JürgenB
Auge
Der Martin
Karl Heinz
Auge
Der Martin
Hallo,
meine Erfahrung bezogen auf HTML hält sich in Grenzen.
Bezogen auf nachfolgende Webseite hätte ich deshalb eine Frage:
Schaut man in den Quellcode der Webseite so sieht man, dass ein iFrame vorhanden ist:
<iframe src="buchen.cgi?request&display=new&ip=217.86.185.58&target=frame&&request=&
hotel_id=bierhaeuslefreiburg&spr=d&where=D9O56OB9O3A&come_from=booking.cgi" width="100%" height="600" frameborder="0" marginwidth="10" marginheight="10"></iframe>
Über das iFrame scheint wohl die eigentliche Buchungsmaske (die Hotelunspezifisch ist) in das Layout des jeweiligen Hotels (welches Hotelspezifisch ist) integriert zu werden. Liege ich da richtig?
Nun frage ich mich ob der Anbieter „Caeser-Data“ diese Lösung nicht auch ohne iFrame hätte realisieren können?
iFrames sind doch veraltet und sollten nichtmehr verwendet werden oder liege ich da falsch?
Moin,
Schaut man in den Quellcode der Webseite so sieht man, dass ein iFrame vorhanden ist:
<iframe src="buchen.cgi?request&display=new&ip=217.86.185.58&target=frame&&request=&hotel_id=bierhaeuslefreiburg&spr=d&where=D9O56OB9O3A&come_from=booking.cgi" width="100%" height="600" frameborder="0" marginwidth="10" marginheight="10"></iframe>Über das iFrame scheint wohl die eigentliche Buchungsmaske (die Hotelunspezifisch ist) in das Layout des jeweiligen Hotels (welches Hotelspezifisch ist) integriert zu werden. Liege ich da richtig?
vermutlich ja, sieht so aus. Und wie man an den URL-Parametern schon ahnen kann, findet da wohl ein wüster Hin- und Rück- und Weiterleitungsmechanismus statt.
Nun frage ich mich ob der Anbieter „Caeser-Data“ diese Lösung nicht auch ohne iFrame hätte realisieren können?
Hätte mit Sicherheit. Offensichtlich rufen sie im iframe ja nicht direkt Fremdinhalte auf, sondern eigene cgi-Programme - eigene im Sinne von: vom eigenen Server. Das unterliegt also alles deren eigener Kontrolle, man hätte diese Anwendungen folglich auch direkt in die Hauptseite integrieren können.
Aber vielleicht hat irgendein Rotstiftquäler beschlossen, dass das zu viel Aufwand wäre, und "das muss auch einfacher gehen". Vielleicht sind die CGIs auch universelle Bausteine aus einen zugekauften Buchungssystem.
iFrames sind doch veraltet und sollten nichtmehr verwendet werden oder liege ich da falsch?
Kommt drauf an. Wenn ich Dinge in meine Webseite einbinden möchte, die eine fremde Quelle als fertiges, komplettes HTML-Dokument liefert, ist ein iframe vielleicht die einzige Möglichkeit. Das sind gerade solche Dinge wie ein Online-Gästebuch oder ein Kontaktformular, die man irgendwo als fertiges Modul bekommt. Oder denk an Wetterdaten zum Anzeigen auf der eigenen Webseite, die von den Wetterdiensten manchmal auch als komplettes HTML-Dokument geliefert werden.
Wenn man allerdings selbst die Hoheit über die Inhalte und deren Form hat, würde ich von der Verwendung von iframes abraten.
So long,
Martin
@@Der Martin
Kommt drauf an. Wenn ich Dinge in meine Webseite einbinden möchte, die eine fremde Quelle als fertiges, komplettes HTML-Dokument liefert, ist ein iframe vielleicht die einzige Möglichkeit. Das sind gerade solche Dinge wie ein Online-Gästebuch oder ein Kontaktformular, die man irgendwo als fertiges Modul bekommt.
Oder das Einbetten von Videos von Vimeo oder YouTube, was auch per Iframe realisiert wird, worin dann z.B. auch die Erkennung läuft, ob der Client mit HTML5-video was anfangen kann oder noch Flash zur Anzeige benötigt.
Frage: Kann man YouTube-Videos auch anders einbinden, sodass die Seitenbesucher nicht von Google ausgeschnüffelt werden?
LLAP 🖖
sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
Hallo Gunnar,
Frage: Kann man YouTube-Videos auch anders einbinden, sodass die Seitenbesucher nicht von Google ausgeschnüffelt werden?
spontane Idee: Link setzen, evtl. mit Target auf Platzhalter-Iframe, evtl. mit Autoplay on.
Gruß
Jürgen
Hallo
Frage: Kann man YouTube-Videos auch anders einbinden, sodass die Seitenbesucher nicht von Google ausgeschnüffelt werden?
Da Google auf der Youtube-Site die URL der Mediadateien nicht herausrückt, geht das wohl nur, indem man die Datei z.B. mit einem Browserplugin herunterlädt, an geeigneter Stelle wieder hochlädt und dort in (ein) Dokument(e) einbindet, also selbst anbietet. Ob das lizenzrechtlich i.O. ist, steht auf einem anderen Blatt. Diese Frage muss man wohl von Fall zu Fall entscheiden. Ein Youtube-Video ist das dann strenggenommen auch nicht mehr.
Tschö, Auge
Hallo,
@@Der Martin Frage: Kann man YouTube-Videos auch anders einbinden, sodass die Seitenbesucher nicht von Google ausgeschnüffelt werden?
theoretisch ja. Ich schau mir youtube-Videos beispielsweise nie direkt online bei youtube an, sondern nutze einen Online-Dienst, der nach Eingabe des youtube-Links erst nachschaut, in welchen Auflösungen und Formaten das Video verfügbar ist, mich eine davon auswählen lässt und mir das Video dann zum Download anbietet. Mit Google oder youtube komme ich dabei nicht direkt in Berührung.
Vermutlich läuft dort im Hintergrund genau das, was Auge auch schon beschreibt, nur dass das Video nicht irgendwo permanent gespeichert, sondern direkt an den Client durchgereicht wird.
Ich habe aber selbst keine Ahnung, wie das im Detail abläuft.
So long,
Martin
Oder das Einbetten von Videos von Vimeo oder YouTube, was auch per Iframe realisiert wird, worin dann z.B. auch die Erkennung läuft, ob der Client mit HTML5-
videowas anfangen kann oder noch Flash zur Anzeige benötigt.Frage: Kann man YouTube-Videos auch anders einbinden, sodass die Seitenbesucher nicht von Google ausgeschnüffelt werden?
Glaub nicht das das möglich ist. Bindet man einen iframe von Youtube ein kann Youtube auch den User tracken. Es gibt zwar sandbox, referrerpolicy usw. Aber damit zerstört man wahrsch. die genannte Erkennung auf der eingebetteten Youtubeseite.
Bindet man einen iframe von einem Proxy Dienst ein, der das Video irgendwie von Youtube holt, kann zwar nicht Google aber dieser Dienst den User tracken...
Über das iFrame scheint wohl die eigentliche Buchungsmaske (die Hotelunspezifisch ist) in das Layout des jeweiligen Hotels (welches Hotelspezifisch ist) integriert zu werden. Liege ich da richtig?
vermutlich ja, sieht so aus. Und wie man an den URL-Parametern schon ahnen kann, findet da wohl ein wüster Hin- und Rück- und Weiterleitungsmechanismus statt.
Ich will mal mein Problem etwas deaillierter erläutern:
Ich frage mich wie ich diese Problematik lösen kann, sprich habt Ihr eine Idee was ich tun könnte damit die Buchungen der richtigen Quelle/Medium Kombination zugeordnet werden?
Wenn man allerdings selbst die Hoheit über die Inhalte und deren Form hat, würde ich von der Verwendung von iframes abraten.
Okay, wie würdest du diesen Fall lösen:
Ich habe einen Veranstaltungskalender auf Domain A, der per iframe in andere Seiten einzubetten ist. Natürlich mit Parametern, die die Termine aus der Datenbank bestimmen.
Ich habe einen Dachverband auf Domain B, der die Veranstaltungen "seiner" Mitglieder auf seiner Seite zeigen möchte. Doch die Datenbank dazu ist auf Domain A.
Klar kann ich die Datenbank A von B aus erreichen. Aber soll ich bei B nochmals die notwendigen Programme installieren? Und bei deren Weiterentwicklung nicht vergessen, wo ich sie überall hinkopieren muss? Ich plädiere für den iframe.
Ein weiterer Fall: Ich habe eine spezielle Fan-Seite auf Domain C. Da kann man seinen nächsten Verein auf Basis der Postleitzahl suchen. Ein Programm, das nur auf C liegt. In diesem Fall ist der Zugriff auf Datenbank bei A sinnvoll, nutzt die gespeicherten Vereine und die Geo-Koordinaten zu deren Heimatort. Also ohne iframe.
Linuchs
Klar kann ich die Datenbank A von B aus erreichen. Aber soll ich bei B nochmals die notwendigen Programme installieren? Und bei deren Weiterentwicklung nicht vergessen, wo ich sie überall hinkopieren muss? Ich plädiere für den iframe.
Das hat zunächst nichts mit der Frage "iFrame oder nicht iFrame" zu tun. Dein Script "example.org/events.js" könnte ja auch direkt ins "fremde DOM" schreiben, bzw. einen definierten Container füllen. Was neben Vorteilen wiederum auch seine Nachteile hat.
Hallo
Wenn man allerdings selbst die Hoheit über die Inhalte und deren Form hat, würde ich von der Verwendung von iframes abraten.
Okay, wie würdest du diesen Fall lösen:
Ich habe einen Veranstaltungskalender auf Domain A, der per iframe in andere Seiten einzubetten ist. Natürlich mit Parametern, die die Termine aus der Datenbank bestimmen.
Ich habe einen Dachverband auf Domain B, der die Veranstaltungen "seiner" Mitglieder auf seiner Seite zeigen möchte. Doch die Datenbank dazu ist auf Domain A.
Verstehe ich dich richtig? Der Betreiber der Domain B will einen Ausschnitt der Datenbank von A, nämlich ausschließlich die Konzerte seiner Mitglieder, anzeigen.
Klar kann ich die Datenbank A von B aus erreichen. Aber soll ich bei B nochmals die notwendigen Programme installieren? Und bei deren Weiterentwicklung nicht vergessen, wo ich sie überall hinkopieren muss? Ich plädiere für den iframe.
Ich plädiere gegen den Iframe und für eine API, mit der der Betreiber von B den von ihm gewünschten Ausschnitt von A erfragen und die Ergebnisse der Abfrage auf B selbst ausgeben kann. Und ja, das ist nicht mal schnell nebenbei gemacht.
Ein weiterer Fall: Ich habe eine spezielle Fan-Seite auf Domain C. Da kann man seinen nächsten Verein auf Basis der Postleitzahl suchen. Ein Programm, das nur auf C liegt. In diesem Fall ist der Zugriff auf Datenbank bei A sinnvoll, nutzt die gespeicherten Vereine und die Geo-Koordinaten zu deren Heimatort. Also ohne iframe.
Das geht irgendwie in Richtung API, oder?
Mit der von Martin postulierten Bedingung, man solle „selbst die Hoheit über die Inhalte und deren Form“ haben, haben beide von dir vorgestellten Fälle allerdings nichts zu tun.
Tschö, Auge
Ich plädiere gegen den Iframe und für eine API, mit der der Betreiber von B den von ihm gewünschten Ausschnitt von A erfragen und die Ergebnisse der Abfrage auf B selbst ausgeben kann. Und ja, das ist nicht mal schnell nebenbei gemacht.
Mir fällt da eine Lösung ein:
Ich könnte die eigentliche Darstellung - wie bisher - als eigenständiges Dokument ausliefern, setze darin eine Start- und eine Ende- Marke des "nackten" Inhalts und muss dazu natürlich noch ein abgespecktes CSS anbieten.
Doch dann entfällt z.B. die Möglichkeit, den Zeitraum zu wählen, zu blättern, die Sprache zu ändern, ...
Das müsste die Mantel-Seite dann nachstellen. Wozu das nochmal machen? Also doch iframe. http://shanty-fsd.de/termine.php
Linuchs
Hallo
Ich plädiere gegen den Iframe und für eine API, mit der der Betreiber von B den von ihm gewünschten Ausschnitt von A erfragen und die Ergebnisse der Abfrage auf B selbst ausgeben kann. Und ja, das ist nicht mal schnell nebenbei gemacht.
Mir fällt da eine Lösung ein:
Ich könnte die eigentliche Darstellung - wie bisher - als eigenständiges Dokument ausliefern, setze darin eine Start- und eine Ende- Marke des "nackten" Inhalts und muss dazu natürlich noch ein abgespecktes CSS anbieten.
Doch dann entfällt z.B. die Möglichkeit, den Zeitraum zu wählen, zu blättern, die Sprache zu ändern, ...
Also fiel dir keine Lösung ein.
Das müsste die Mantel-Seite dann nachstellen. Wozu das nochmal machen? Also doch iframe. http://shanty-fsd.de/termine.php
Du hast Lösung A, dir wird Alternativlösung B vorgeschlagen und weil C nicht funktioniert, bleibst du bei A. Verschwendete Energie.
Tschö, Auge
Hallo
iFrames sind doch veraltet und sollten nichtmehr verwendet werden oder liege ich da falsch?
So radikal liegst du falsch.
iFrames sind nicht veraltet. Sie sollten nicht mit Frames verwechselt werden.
Sie sollten aber nur für die Aufgaben verwendet werden, für die sie gedacht sind.
Wenn die von dir verlinkte Seite auch ohne iFrames funktioniert sollte auf das iFrame verzichtet werden.
Gruss
MrMurphy
iFrames sind doch veraltet und sollten nichtmehr verwendet werden oder liege ich da falsch?
Der große Vorteil, solche "Widgets" über iFrames zu realisieren, ist die Immunität gegenüber den Zuständen im einbindenden Dokument. Kein CSS / JavaScript kann hier das iFrame-Dokument beinträchten (einzige Ausnahme: die iFrame-Definition selbst). Das bringt eine ganze Menge Stabilität.
Kein CSS / JavaScript kann hier das iFrame-Dokument beinträchten (einzige Ausnahme: die iFrame-Definition selbst).
Hast du bitte ein Beispiel, wie das Dokument im iframe die Höhe des eigenen iframe anpassen kann?
Weil das angeblich nicht ging, habe ich vor Jahren ein kompliziertes Prozedere entwickelt:
Soweit, so kompliziert. Doch wenn im iframe ein neues Dokument geladen wird, merkt das parent-Dokument nichts davon, der iframe ist nun unnötig hoch oder bekommt Scrollbalken.
Linuchs
[...] Soweit, so kompliziert. Doch wenn im iframe ein neues Dokument geladen wird, merkt das parent-Dokument nichts davon, der iframe ist nun unnötig hoch oder bekommt Scrollbalken.
Wie Du richtig erkannt hast, hat die Lösung via iFrame nicht nur Vorteile. Der Königsweg wäre der von Auge propagierte, mittels einer dezidierten API. Nur dar man mehr als skeptisch sein, ob die ein Verein implementieren wird. Das "Script SRC" in die Seite zu knallen, geht halt irgendwie einfacher und schneller.
Die von Dir skizzierten Probleme lassen sich jedoch lösen, auch deutlich einfacher / eleganter, als von Dir beschrieben:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Ob sich das dann am Ende so richtig gut anfühlen wird? Da darf man skeptisch sein. Die Seiteninhalte springen dann ja willkürlich hin und her.
Hallo
Wie Du richtig erkannt hast, hat die Lösung via iFrame nicht nur Vorteile. Der Königsweg wäre der von Auge propagierte, mittels einer dezidierten API. Nur dar man mehr als skeptisch sein, ob die ein Verein implementieren wird.
Wenn das von vorn bis hinten durchdacht wird, muss man einem Kunden die Programmierung nicht einmal aufbürden. Was spricht dagegen, eine Beispielimplementierung, z.B. in Form eines PHP-Skripts, anzubieten, was „nur“ in die Seite eingebaut werden muss [1] und Interessierten immernoch die Möglichkeit des Programmierens auf Basis einer gut verständlichen (weil wir ja „nebenan“ gerade beim Thema waren) API-Doku offen zu lassen? Ob das zu Linuchs' Zielpublikum von Shanty-Chören passt, sei mal dahingestellt.
Tschö, Auge
Ich weiß, ich weiß, selbst das überfordert nicht Wenige. Im Zweifelsfall sollte das mit weitergehenden Angeboten unterfüttert werden. ↩︎
Hallo,
Hast du bitte ein Beispiel, wie das Dokument im iframe die Höhe des eigenen iframe anpassen kann?
genau das würde ich normalerweise nicht wollen. Es ist doch gerade einer der Vorteile von iframes, dass beliebige Inhalte in einem "Fenster" dargestellt werden, dessen Größe ich genau festlegen kann, so dass sie zum Gesamtlayout passt und selbiges nicht "stört".
So long,
Martin
Hast du bitte ein Beispiel, wie das Dokument im iframe die Höhe des eigenen iframe anpassen kann?
Weil das angeblich nicht ging, habe ich vor Jahren ein kompliziertes Prozedere entwickelt:
Seit Jahren gibt es schon Cross-Window-Kommunikation zwischen Domains:
- Iframe-Dokument meldet nach dem Laden seine Höhe per Ajax an seinen Vater-Server (dieselbe Domain).
- der erstellt ein img mit genau dieser Höhe.
- Parent-Dokument bekommt mit, dass der iframe Inhalt geladen ist, wartet noch einen Moment und holt sich das Bild vom Fremd-Server.
- Überträgt die Höhe des Bildes auf die Höhe des Iframe.
Das ist wirklich übermäßig kompliziert… postMessage wird doch schon seit IE 8 unterstützt.
Ob iFrames noch sinnig sind? Ja natürlich sind die sinnvoll.
Überlege mal wieviele Inhalte man erst durch Inlineframing, ohne Rechtsverletzungen Dritter auf seiner Seite darstellen kann.
2014 haben die Richter vom Europäischen Gerichtshof entschieden, dass es zulässig ist fremde Inhalte bei sich einzubinden, wenn man diese nicht vervielfältigt. Wer sich dafür interessiert, kennt die genauen Punkte. Und der Rest sollte sich nicht wundern, wenn er Probleme dank dem Urheberrechtsverstoß hat.