什么时候应该使用 HTML 框架？答案

【问题标题】：When should I use HTML frames?什么时候应该使用 HTML 框架？
【发布时间】：2023-03-15 07:35:01
【问题描述】：

我听过无数关于为什么不使用 HTML 框架的理由，包括它们缺乏可访问性、普遍缺乏 UX、它们完全低效/不可维护，或者它们已经过时了。

这一切都让我想到了两个问题：

【问题讨论】：

【解决方案1】：

您可以使用 iframe 来访问您网站中来自第三方的广告，而无需向包含 iframe 的父文档提供任何额外的控制或消息传递。

这样您就可以访问您网站中的广告，但同时可以防止来自未知资源的攻击

HTML 元素表示嵌套的浏览上下文，有效地将另一个 HTML 页面嵌入到当前页面中。

【讨论】：

【解决方案2】：

(1) 不可以。iframe 有合法用途，现在没有理由在现代浏览器中使用框架。

(2) 永远不要使用框架；还有其他更好更简单的解决方案可以产生相同的效果。

仅当嵌入整个网站是最合乎逻辑的选择时才使用 iframe。虽然很少见，但在某些情况下这是有道理的。

简而言之，frame/frameset/noframe 标签从 HTML5 中移除是有原因的，但 iframe 会继续使用。

（示例）如果站点 A 必须包含站点 B 的页面（代理似乎来自站点 A），那么站点 B 的 css 和 javascript 可以并且通常会完全控制站点 A。这是一个正当的理由。

【讨论】：

考虑到您的第二点。当您尝试在另一个站点（例如 CMS）中显示整个站点时，您会使用 iframe 吗？站点 A 是允许管理内容的后台，站点 B 是包含可管理内容的门户。因此，为了预览它的外观，请在站点 A 上提供一个 iframe？
是的，这听起来像是 iframe 的合法用例。这是一个受控环境，您需要在第一个环境中显示一个单独的站点。

【解决方案3】：

如果由于某种原因你有“嵌套形式”。

假设您有一个产品编辑表单，并且在此表单内您有一个带有另一个表单的区域，假设您可以输入客户列表以发送该产品的新闻通讯。

客户与产品完全无关，也与产品没有数据库关系。它们是合规地与产品分开的实体。

在这种情况下，我用客户添加表单和提交按钮创建了一个 IFrame，该按钮在 IFrame 中提交表单。

我没有找到比使用 IFrame 更好的方法来实现所描述的场景。是的，我要求将两个表单放在同一页面上，并且通讯表单应该放在产品编辑表单中。老板决定的业务需求。

【讨论】：

+1 为简单起见，不要使用异步 HTTP 请求，只需允许来自单个帧的简单表单 POST，然后只允许在该帧内同步页面刷新，因此不会干扰任何其他内容其他框架。在我看来，这正是存在的原因之一。

【解决方案4】：

(1) 不是天生的。 iframe 有许多不受框架问题困扰的用例。当您想要混合来自另一个安全上下文的文档，或者没有父页面正在使用的脚本和样式时，它们非常有用。

但是，可以“像框架一样使用 iframe”：将页面拆分为单独的 iframe 区域，使用跨框架链接会造成无法播放的导航混乱书签，在新标签页中打开等。

(2) 我今天不会使用任何框架。他们保留大量页面内容的用例有限，您不想在每次导航时重新加载这些内容。但是现在我们只使用XMLHttpRequest 来更新页面的一部分。

即便如此，没有注意使页面更改链接可访问（使用哈希历史并为每个哈希链接提供静态链接模拟，与响应中键等的真实<a>s 链接），使用XMLHttpRequest 进行自我更新/导航的页面将重现框架的许多导航问题，对可用性、可访问性和 SEO 影响很大。

我觉得有点可悲的是，许多作者正在创建华丽、时髦、“现代”的动画网站，这些网站通过天真地使用 jQuery 的load() 或类似的东西来展示古老、讨厌的框架的所有最糟糕的行为。

【讨论】：

“...你想混合来自另一个安全上下文的文档...” - 当我读到它时，我忍不住笑了。可惜这么多人认为这是个好主意。网络钓鱼和点击劫持是赢家？
@noloader：嗯，是的；在父页面具有高信任度而子框架内容低信任度的情况下这样做是有意义的，因为从子级到父级的可能攻击更加有限（模态弹出窗口/下载/等和隐形导航，而不是网络钓鱼/点击劫持）。将高信任度项目（如登录表单）放在信任度较低的网站的框架中确实是一个真正的错误。