Pourquoi aucune balise HTML côté client?

18

Une autre question m'a été posée l'autre jour par un autre programmeur. Je me souviens (il y a très longtemps) de me demander la même chose. Pourquoi une balise include côté navigateur n'a-t-elle jamais été prise en compte? Ou était-ce?

Plus précisément avec une balise qui a demandé au navigateur d'inclure du HTML supplémentaire provenant d'autres sources. par exemple <include src="http://server/foo/bar.html">. Beaucoup de gens feront des appels javascript et se rempliront innerHTMLpour accomplir la même chose, quand la même chose en dehors du moteur javascript pourrait être accomplie par le navigateur.

Il aurait été douloureux d'imbriquer des <HTML>s <BODY>(c.-à-d.), Mais nous devons quand même considérer cet aspect n'importe où.

history html Jé Queue
la source
Les entités externes ne vous le donnent-elles pas déjà?
Peter Taylor
La transclusion était considérée comme une caractéristique essentielle de l'hypertexte, même depuis son invention dans les années 60. Donc je suis sûr que cela a été considéré ...
Alex Feinman

Réponses:

12

Suis-je la dernière personne sur terre à se souvenir de ( Netscape 4 uniquement ) layeret des ilayertags?

Netscape 4 a également permis à la divbalise d'avoir un srcattribut, ce qui a accompli la même chose.

Netscape les a soumis au W3C, qui a choisi de ne pas les inclure - utilisez iframeplutôt.

Dori
la source
Je me souviens en effet de NS4 mais je ne me souviens pas de ces fonctionnalités. Dommage, je me contente encore d'économiser beaucoup de BS javascript inter-navigateurs.
Jé Queue
Je me souviens de détester NS4 avec une telle passion que l'une de mes premières adresses e-mail non FAI était un compte gratuit sur ihatenetscape.com. Ah, bons moments: D
wildpeaks
Les calques de notes n'étaient pas tout à fait un côté client, car ils avaient toujours un documentobjet séparé soumis à la même politique d'origine; ils étaient effectivement un iframe positionnable.
bobince
14

Pourquoi une balise include côté navigateur n'a-t-elle jamais été prise en compte? Ou était-ce?

Il a certainement été demandé par tous les auteurs de sites Web débutants qui n'avaient pas encore travaillé sur les inclusions côté serveur, au début de la liste www-html. Mais à cette époque, W3 était heureux d'ignorer complètement la pression des auteurs Web.

Si l'inclusion intersite était autorisée, ce serait un désastre de sécurité. Vous pouvez extraire une page de la banque de l'utilisateur et en lire le contenu. (À l'origine, les scripts DOM étaient limités, mais vous pouviez toujours lire document.links, les document.imagesfonctions de script abandonnées par la page cible, etc. Depuis, vous pouvez faire ce que vous voulez avec le contenu importé.)

Si l'inclusion intersite n'était pas autorisée ... eh bien, la fonctionnalité n'aurait aucun avantage sur les inclusions côté serveur. Ce serait un travail plus long et plus lent pour le client que le serveur aurait pu mieux gérer. Contrairement à <iframe>, une inclusion devrait bloquer le chargement de la page. Les SSI seraient à tous égards supérieurs.

bobince
la source
5
En fait, le client (ou un proxy) pourrait mettre en cache plus efficacement, car les modèles (ou les en-têtes / pieds de page incluent) n'ont pas tendance à changer de page en page, ce qui signifie que l'utilisateur pourrait au moins voir une partie de la page tandis que certains le traitement côté serveur est en cours.
Alan Pearce du
1
Cela ferait beaucoup plus que le serveur. Je ne sais pas pourquoi il faudrait bloquer le chargement de la page, cela aurait pu permettre le chargement complet de la page avec le remplissage de contenu asynchrone. Bien sûr, il pourrait être limité par les navigateurs pour autoriser uniquement l'extraction à partir des serveurs d'origine ou pour autoriser un DOM dominé.
Jé Queue
Je ne comprends pas comment c'est un désastre de sécurité. Je peux lire une page de banque côté serveur en ce moment et la recracher sur une autre page - est-ce un désastre? Peut-être, mais certainement pas lié à la sécurité. Un désastre de sécurité serait de lire des cookies d'un domaine différent. Sans ce côté client, l'inclusion serait exactement la même que celle côté serveur. Je ne vois aucun problème ici.
serg
Vous pouvez essayer de récupérer une page bancaire côté serveur, mais votre demande ne sera pas authentifiée, vous ne pourrez donc pas télécharger d'informations juteuses. Une demande du côté client comprend des cookies et des jetons d'authentification HTTP; si vous pouvez lire la réponse d'une telle demande, vous pouvez usurper l'identité de l'utilisateur.
bobince
@bobince: Y a-t-il une raison pour laquelle la demande côté client devrait inclure des cookies et des jetons d'authentification HTTP? Le scénario d'utilisation principal que je verrais pour les inclusions côté client serait d'améliorer la mise en cache du contenu de page statique. Si seize pages contiennent toutes le même en-tête et pied de page, l'utilisation d'une inclusion côté client augmenterait le temps nécessaire pour charger la première, mais réduirait le temps pour charger les quinze restantes. Les cas d'utilisation où l'inclusion serait le plus utile seraient précisément ceux où les données à "inclure" seraient statiques et n'auraient donc pas besoin ...
supercat
10

Ils l'ont fait. C'est devenu le <frameset>tag. Peu de temps après, ils ont ajouté la <iframe>balise.

La plupart des premiers serveurs Web pris en charge incluent les inclusions côté serveur, donc une inclusion textuelle côté client était probablement considérée comme inutile, étant donné que la même fonctionnalité était également disponible avec les cadres.

gris-fondu
la source
4
Les cadres n'ont pas vraiment un objectif très différent de l'inclusion. De plus, les restrictions sur les iframes, en particulier dans la taille de l'ensemble d'objets, n'auraient certainement pas pu penser à prendre sa place.
Jé Queue
5
Je ne suis pas d'accord - je pense que c'est exactement ce que font les cadres. À quoi servent les cadres, à l'exception de l'inclusion de plus de code HTML?
Jaco Pretorius
5
Les cadres incluent du HTML dans les cadres, pas directement - c'est la différence.
mbq
4
@Xepoch: ... Avec un <iframe>. C'est ce qu'il est pour . Ce n'est vraiment pas très différent d'un <div>avecoverflow:auto;
greyfade
3
L'élément <iframe> dit essentiellement "chargez le document html spécifié et collez-le ici". Vous le choisiriez au lieu d'ajax si vous voulez que le document soit chargé immédiatement, pas sur un appel javascript ... Les cadres ne sont PAS une présentation fenêtrée de HTML. Div, p, br - ce sont tous des éléments utilisés pour la mise en page. Vous n'utilisez pas de cadres pour la mise en page (ou vous ne devriez pas de toute façon).
Jaco Pretorius
3

L'objet s'affiche toujours dans un cadre et vous n'avez aucun accès DOM aux "données". Ce que les développeurs auraient dû recevoir il y a des années est un moyen d'inclure des extraits avec une simple balise. Même si cette balise avait des restrictions de sandbox de domaine, il serait très utile de compartimenter les fonctionnalités, d'améliorer la maintenance et de profiter de la mise en cache du navigateur.

Je sais qu'il existe de nombreux bons plugins jquery qui font cela et beaucoup de scripts côté serveur, mais il n'y a aucune bonne raison de ne pas prendre en charge une telle balise. L'OMI est une bonne question "Pourquoi aucune étiquette d'inclusion côté client?"

Si vous aimez jquery, voici un bon script d'inclusion côté client: inc: Un super-petit côté client inclut le plugin JavaScript jQuery

Jonas
la source
Votre réponse est la seule qui semble avoir mis le doigt sur la tête. Envisagez-vous quelque chose comme #include in C? C'est exactement le genre de chose que «l'inclusion côté client» signifie pour moi - une facilité pour inclure des extraits HTML arbitraires (plutôt que des documents HTML entiers) dans un document HTML en tant que contenu de document intégral. Bien qu'il puisse être conçu comme une caractéristique intégrale du HTML plutôt que comme une étape de pré-analyse - la syntaxe <include src = "..."> suggérée par le demandeur cadrerait parfaitement avec cela.
Stewart
Le problème avec l'ajout maintenant serait la compatibilité descendante. Bien sûr, cela n'explique pas pourquoi il n'a pas été inclus dans la conception originale de HTML.
Stewart
Il aurait également pu être conçu comme une caractéristique de SGML / XML plus généralement ....
Stewart
2

As-tu essayé

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

Je pense que c'est implémenté dans la plupart des navigateurs.

Peter Turner
la source
Faudra essayer.
Jé Queue
2

Les variantes d'une <include>balise ont certes été envisagées au début de l'histoire du HTML , mais elles ne sont jamais allées très loin.

Trigonométrie
la source
1
Cependant, la sémantique de cette balise <include> était similaire à celle du cadre / iframe / objet d'aujourd'hui - elle inclurait un document html , et pas seulement des extraits de texte / code ou des balises aléatoires comme le ferait le #include de C.
Tomáš Pospíšek