Warum kein clientseitiges HTML-Include-Tag?

18

Ich hatte neulich eine Frage von einem anderen Programmierer. Ich erinnere mich, dass ich mich (vor langer Zeit) genau das selbe gefragt habe. Warum wurde ein browserseitiges Include-Tag nie berücksichtigt? Oder war es?

Insbesondere mit einem Tag, das den Browser anweist, zusätzliches HTML aus anderen Quellen einzuschließen. zB <include src="http://server/foo/bar.html">. Viele Leute werden Javascript-Aufrufe tätigen und füllen innerHTML, um das Gleiche zu erreichen, wenn das Gleiche außerhalb der Javascript-Engine vom Browser ausgeführt werden könnte.

Es wäre schmerzhaft gewesen, geschachtelte <HTML>s <BODY>s (dh) zu haben, aber wir müssen diesen Aspekt ohnehin überall berücksichtigen.

history html Jé Queue
quelle
Geben Ihnen externe Entitäten dies nicht bereits?
Peter Taylor
Die Transklusion wurde bereits seit ihrer Erfindung in den 60er Jahren als Kernmerkmal des Hypertexts angesehen. Ich bin mir sicher, dass es in Betracht gezogen wurde ...
Alex Feinman

Antworten:

12

Bin ich die letzte Person auf der Welt, die sich an die ( Netscape 4-only ) layerund ilayerTags erinnert?

Netscape 4 erlaubte es dem divTag auch, ein srcAttribut zu haben , das dasselbe erreichte.

Netscape übermittelte sie dem W3C, der sie nicht einbezog. Verwenden Sie iframestattdessen.

Dori
quelle
Ich erinnere mich zwar an NS4, erinnere mich aber nicht an diese Funktionen. Schade, ich bin immer noch zufrieden, es würde eine Menge browserübergreifender Javascript-BS sparen.
Jé Queue 28.09.10
Ich erinnere mich, dass ich NS4 so leidenschaftlich hasste, dass eine meiner ersten Nicht-ISP-E-Mail-Adressen ein kostenloses Konto bei ihatenetscape.com war. Ah, gute Zeiten: D
wildpeaks
Hinweis Ebenen waren nicht ganz clientseitig eingebunden, da sie noch ein separates documentObjekt hatten, das der Same Origin Policy unterliegt. Sie waren effektiv ein positionierbarer Iframe.
Bobince
14

Warum wurde ein browserseitiges Include-Tag nie berücksichtigt? Oder war es?

Es wurde sicherlich von jedem neuen Webautor angefragt, der Server Side Includes noch nicht ausgearbeitet hatte, damals auf der www-html-Liste. Aber damals war W3 froh, den Druck der Webautoren völlig zu ignorieren.

Wenn eine standortübergreifende Einbeziehung zulässig wäre, wäre dies eine Sicherheitslücke. Sie können eine Seite aus der Bank des Benutzers einlesen und Inhalte daraus lesen. (Ursprünglich war die DOM-Skripterstellung begrenzt, Sie konnten jedoch weiterhin aus Skripterstellungsfunktionen lesen document.links, document.imagesdie von der Zielseite usw. entfernt wurden. Seitdem können Sie mit importierten Inhalten das tun, was Sie möchten.)

Wenn Cross-Site-Inklusion nicht zulässig wäre, hätte die Funktion keinen Vorteil gegenüber serverseitigen Includes. Es wäre mehr und langsamer für den Client, als es der Server hätte tun können. Im Gegensatz <iframe>dazu müsste ein Include das Laden von Seiten blockieren. SSIs wären in jeder Hinsicht überlegen.

Bobince
quelle
5
Tatsächlich kann der Client (oder ein Proxy) effizienter zwischengespeichert werden, da Vorlagen (oder Kopf- / Fußzeileneinschlüsse) nicht dazu neigen, sich von Seite zu Seite zu ändern, was bedeutet, dass der Benutzer möglicherweise zumindest einen Teil der Seite sehen kann, während einige Die serverseitige Verarbeitung wird fortgesetzt.
Alan Pearce
1
Es würde deutlich mehr bewirken als der Server. Ich bin mir nicht sicher, warum das Laden von Seiten blockiert werden muss. Es hätte das vollständige Laden von Seiten mit asynchroner Inhaltsfüllung ermöglichen können. Natürlich könnte es von Browsern eingeschränkt werden, nur das Abrufen von Ursprungsservern zuzulassen oder ein domäniertes DOM zuzulassen.
Jé Queue
Ich verstehe nicht, wie es eine Sicherheitskatastrophe ist. Ich kann jetzt eine Bankseite auf dem Server lesen und auf eine andere Seite ausspucken - ist das eine Katastrophe? Vielleicht, aber sicher nicht sicherheitsrelevant. Eine Sicherheitskrise würde das Lesen von Cookies aus einer anderen Domäne bedeuten. Ohne dieses clientseitige Include wäre genau das gleiche wie serverseitig eins. Sehen Sie hier kein Problem.
Serg
Sie können versuchen, eine Bankseite auf der Serverseite abzurufen, aber Ihre Anforderung wird nicht authentifiziert, sodass Sie keine wichtigen Informationen herunterladen können. Eine Anfrage von der Client-Seite enthält Cookies und HTTP-Authentifizierungstoken. Wenn Sie die Antwort einer solchen Anfrage lesen können, können Sie sich als Benutzer ausgeben.
Bobince
@bobince: Gibt es einen Grund, warum die Anfrage auf der Clientseite Cookies und HTTP-Authentifizierungstoken enthalten müsste? Das primäre Verwendungsszenario, das ich für clientseitige Includes sehen würde, wäre die Verbesserung der Zwischenspeicherung von statischem Seiteninhalt. Wenn 16 Seiten alle dieselbe Kopf- und Fußzeile enthalten, würde die Verwendung eines clientseitigen Einschlusses die zum Laden der ersten Seite erforderliche Zeit verlängern, aber die Zeit zum Laden der verbleibenden 15 verkürzen. Die Anwendungsfälle, in denen das Include am hilfreichsten wäre, wären genau diejenigen, in denen die "
einzuschließenden
10

Sie taten. Es wurde zum <frameset>Tag. Nicht lange danach fügten sie den <iframe>Tag hinzu .

Die meisten der frühen Webserver unterstützten serverseitige Includes, sodass ein clientseitiges textuelles Include wahrscheinlich als unnötig angesehen wurde, da die gleiche Funktionalität auch für Frames verfügbar war.

greyfade
quelle
4
Nicht wirklich Rahmen dienen einem ganz anderen Zweck als die Aufnahme. Außerdem hätten die Einschränkungen für iframes, insbesondere in Bezug auf die Objektmenge, sicherlich nicht in Betracht gezogen, ihren Platz einzunehmen.
Jé Queue
5
Ich bin anderer Meinung - ich denke, genau das machen Frames. Wofür sind Frames noch gut, außer dass sie mehr HTML enthalten?
Jaco Pretorius
5
Frames enthalten HTML in Frames, nicht direkt - das ist der Unterschied.
mbq
4
@ Xepoch: ... mit einem <iframe>. Das ist , was es ist für . Es ist wirklich nicht viel anders als ein <div>mitoverflow:auto;
greyfade
3
Das <iframe> -Element besagt im Grunde "das angegebene HTML-Dokument laden und hier ablegen". Sie würden es anstelle von Ajax wählen, wenn Sie möchten, dass das Dokument sofort geladen wird, nicht bei einem JavaScript-Aufruf ... Frames sind KEIN Fensterlayout für HTML. Div, p, br - all diese Elemente werden für das Layout verwendet. Sie verwenden keine Rahmen für das Layout (oder Sie sollten es sowieso nicht tun).
Jaco Pretorius
3

Das Objekt wird weiterhin in einem Frame gerendert und Sie haben keinen DOM-Zugriff auf "Daten". Was Entwicklern vor Jahren hätte gegeben werden sollen, ist eine Möglichkeit, Snippets mit einem einfachen Tag zu versehen. Selbst wenn dieses Tag Domain-Sandbox-Einschränkungen hätte, wäre es ziemlich nützlich, Features zu unterteilen, die Wartung zu verbessern und das Browser-Caching zu nutzen.

Ich weiß, dass es viele gute JQuery-Plugins gibt, die dies tun, und viele serverseitige Skripte, aber es gibt keinen guten Grund, ein solches Tag nicht zu unterstützen. IMO ist eine gute Frage "Warum kein clientseitiges Include-Tag?"

Wenn Sie jQuery mögen, ist hier ein gutes clientseitiges Include-Skript: inc: Ein winziges clientseitiges Include-JavaScript-Plugin für jQuery

Jonas
quelle
Ihre Antwort ist die einzige, die den Nagel auf den Kopf getroffen zu haben scheint. Denken Sie an etwas wie #include in C? Genau dies bedeutet für mich "clientseitiges Include" - eine Möglichkeit, beliebige HTML-Snippets (und nicht ganze HTML-Dokumente) in ein HTML-Dokument als integralen Dokumentinhalt aufzunehmen. Obwohl es als integraler Bestandteil von HTML und nicht als Vorbereitungsphase für das Parsing konzipiert werden könnte, würde die vom Fragesteller vorgeschlagene Syntax <include src = "..."> genau dazu passen.
Stewart
Das Problem beim Hinzufügen wäre jetzt die Abwärtskompatibilität. Das erklärt natürlich nicht, warum es nicht im ursprünglichen HTML-Design enthalten war.
Stewart
Es könnte alternativ als eine Funktion von SGML / XML im Allgemeinen entworfen worden sein ....
Stewart
2

Hast du es versucht

<object  type="text/html" data="page.html" height="500" width="500">
What I see if that didn't work 
</object>

Ich denke, das ist in den meisten Browsern implementiert.

Peter Turner
quelle
Muss es versuchen.
Warteschlange
2

Varianten eines <include>Tags wurden zwar in der frühen Geschichte von HTML berücksichtigt , kamen aber nie weit.

TRiG
quelle
1
Die Semantik dieses <include> -Tags war jedoch ähnlich wie die des heutigen frame / iframe / object - es würde ein HTML- Dokument enthalten und nicht nur Text- / Code-Schnipsel oder zufällige Tags wie Cs # include.
Tomáš Pospíšek