为什么没有客户端HTML包含标记？

18

前几天，另一个程序员向我提出了一个问题。我记得（很久以前）想知道同样的事情。 为什么从不考虑浏览器端的include标签？还是吗？

特别是带有指示浏览器包含其他来源的HTML的标记。例如<include src="http://server/foo/bar.html">。innerHTML当浏览器可以完成javascript引擎外部的调用时，许多人会进行javascript调用并填充以完成相同的操作。

嵌套<HTML>s 会很痛苦，<BODY>但是无论如何我们都必须考虑这个方面。

history html

— JéQueue
source

外部实体还没有给您这个吗？

— 彼得·泰勒

即使在60年代发明超文本之后，仍将其视为超文本的核心特征。所以我确定它被认为是 ……

— Alex Feinman 2014年

12

我是地球上最后一位记得（仅Netscape 4）layer和ilayer标签的人吗？

Netscape 4浏览器还允许在div标签有一个src属性，它完成了同样的事情。

Netscape将它们提交给W3C，后者选择不包括它们，iframe而是使用。

— 多里
source

我确实记得NS4，但不记得那些功能。太糟糕了，我仍然很满意，它将节省很多跨浏览器的javascript BS。

— JE队列

我记得我非常讨厌NS4，以至于我第一个非ISP电子邮件地址之一是ihatenetscape.com上的免费帐户。啊，美好的时光：D

— 高峰

注意层并不是客户端，因为它们仍然有一个document受“相同来源策略”约束的单独对象。它们实际上是可定位的iframe。

— bobince 2014年

14

为什么从不考虑浏览器端的include标签？还是吗？

早在www-html列表上的早期，每位尚未制定Server Side Includes的新手Web作者肯定都会提出要求。但是在那些日子里，W3乐于完全忽略网络作者的压力。

如果允许跨站点包容，将是安全灾难。您可以从用户的银行提取页面并从中读取内容。（最初，DOM脚本是受限制的，但是您仍然可以从document.links，，document.images目标页面等放置的脚本功能中进行读取。从那时起，您就可以对导入的内容进行操作。）

如果不允许跨站点包含...那么，该功能将不会比服务器端包含有任何优势。客户端要做的工作更多，更慢，而服务器本来可以更好地应对。与相比<iframe>，include必须阻止页面加载。SSI在各个方面都将是优越的。

— 博宾斯
source

5

实际上，客户端（或代理）可以更有效地缓存，因为模板（或包含页眉/页脚）不倾向于在页面之间变化，这意味着用户可能至少能够看到页面的一部分，而某些服务器端处理正在进行中。

— 艾伦·皮尔斯

1

它会比服务器做得多。我不确定为什么需要阻止页面加载，它可能已经允许通过异步内容填充来加载整个页面。当然，它可能会受到浏览器的限制，以仅允许从原始服务器中拉出或允许域DOM。

— JE队列

我不知道这是一场安全灾难。我现在可以在服务器端阅读银行页面，然后将其吐出另一页-这是一场灾难吗？也许可以，但肯定与安全无关。安全灾难将是从其他域读取cookie。没有此客户端，include将与服务器端完全相同。在这里看不到任何问题。

— 塞格2010年

您可以尝试在服务器端获取银行页面，但您的请求将未经身份验证，因此您无法下载任何多汁的信息。来自客户端的请求包括cookie和HTTP身份验证令牌；如果您可以读取此类请求的响应，则可以完全模拟用户。

— bobince

@bobince：是否有任何理由要求客户端的请求必须包含cookie和HTTP身份验证令牌？我会在客户端看到的主要使用场景是改善静态页面内容的缓存。如果全部16个页面都包含相同的页眉和页脚，则使用客户端包含将增加加载第一个页面所需的时间，但会减少加载其余十五个页面的时间。包含将最有帮助的使用情况恰好是那些要“包含”的数据将是静态的，因此不需要...

— supercat 2014年

10

他们做到了。它成为<frameset>标签。不久之后，他们添加了<iframe>标签。

大多数早期的Web服务器都支持服务器端包含，因此考虑到框架也可以使用相同的功能，因此可能不需要客户端文本包含。

— 灰褪色
source

4

实际上，框架的作用与包含的目的不同。再加上对iframe的限制，尤其是在对象集大小方面，肯定无法想到取代它。

— JE队列

5

我不同意-我认为那正是帧的作用。除了包括更多HTML之外，框架还有什么用？

— 哈科·普雷托里乌斯

5

框架在框架中包含HTML，而不是直接包含HTML –这是区别。

— mb10

4

@Xepoch：...带有<iframe>。这就是它的用途。它<div>与使用overflow:auto;

— greyfade

3

— Jaco Pretorius

3

对象仍然呈现在框架中，并且您没有对“数据”的DOM访问。几年前应该给开发人员的是一种包含带有简单标签的代码片段的方法。即使此标记具有域沙箱限制，对功能进行分隔，改善维护并利用浏览器缓存也将非常有用。

我知道有很多不错的jquery插件可以做到这一点，还有很多服务器端脚本，但是没有充分的理由不支持这种标签。IMO是一个很好的问题，“为什么没有客户端包含标签？”

如果您喜欢jquery，这里是一个很好的客户端include脚本：inc：一个超小的客户端include JavaScript jQuery插件

— 乔纳斯
source

您的回覆是唯一一个似乎触手可及的回覆。您是否在考虑类似C中的#include？这正是“客户端包含”对我而言的意思-一种在HTML文档中包含任意HTML代码段（而不是整个HTML文档）作为整体文档内容的功能。尽管可以将其设计为HTML的一个整体功能，而不是将其作为预先准备的阶段，但问问者建议的<include src =“ ...”>语法恰恰适合于此。

— 斯图尔特

现在添加它的问题将是向后兼容。当然，这并不能解释为什么它不包含在HTML的原始设计中。

— 斯图尔特

它可能或者已经被设计为SGML / XML的功能更普遍....

— 斯图尔特

2

你有没有尝试过

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

我认为这已在大多数浏览器中实现。

— 彼得·特纳
source

将需要尝试。

— JE队列

2

在HTML的早期历史<include>中确实考虑过标签上的变体，但是它们从未走得太远。

— TRiG
source

1

但是，该<include>标记的语义类似于当今的frame / iframe / object的语义-它将包含html 文档，而不仅仅是C /＃include的文本/代码片段或随机标记。

— 托马什Pospíšek