iframe 是一个糟糕的主意吗？ [关闭]答案

【问题标题】：Are iframes a terrible idea? [closed]iframe 是一个糟糕的主意吗？ [关闭]
【发布时间】：2010-09-10 22:30:23
【问题描述】：

我正在构建一个小部件，并且一直在使用 iframe 来呈现其中的内容。在某个时候，我可能会开始提供第三方 HTML 和 JS，所以我认为 iframe 会是一个好主意。

它确实使小部件 javascript 稍微复杂了一点，我担心这可能不是最好的实现。

你有什么建议吗？了解其他人对 iframe 的看法会很有帮助。

【问题讨论】：

标签： javascript iframe widget

【解决方案1】：

iframe 存在一个重大问题，几乎没有人提及，但它让我大吃一惊。

我们的同事毕生致力于一个动态变化的数据库，我们已将其加载到 Google Docs 电子表格中，然后我们将其与大量支持材料一起显示在我们的网站上。

绝对没有什么可以阻止有人从我的页面源中抓取 iframe 代码并将其推送到他们的页面上。现在，他们正在获取我们所有的数据，这些数据在几分钟前刚刚刷新，完全免费提供给他们的页面。

如果一个 google iframe 可以绑定到一个特定的域，那将会停止它的轨道。

有什么想法，火花四溅？

【讨论】：

这已经很老了，但是如果您仍在寻找解决方案，那么我可以考虑使用 X-Frame-Option 标头来限制谁可以加载 iframe。现在，您显然不能将此标头应用到 google 文档 url，因为您无法控制它。但是你可以做的是，而不是直接使用 google docs url，而是想出你自己的 url，它将服务器端重定向到 google docs url。然后您可以将正确的X-Frame-Option 标头应用于您自己的网址

【解决方案2】：

我最近发现的一件事是，嵌入在 iframe 中的 .aspx 页面有时会出现丢失 cookie 的问题，这导致我参与的应用程序中的会话状态丢失。

对我来说，这是在不同的开发商店在他们自己的页面中使用我的一个 .aspx 页面的情况下发生的。这意味着我们在不同的服务器上，这些服务器可能很突出，也可能不突出。

显然这是由于父页面拒绝子页面的 cookie...会话 cookie 一样，会话也一样。

这个工作原理的具体机制有点涉及：More Details

这个问题并没有影响到 FireFox，但它确实出现在 IE7 中，并且在几个小时内一直是个谜。

另外，我必须在一点上与上面链接的文章相矛盾。文章说，如果包含页面也是 .aspx，则您不会得到这个......在这种情况下，这不是真的，因为两个页面都是 .aspxs。

这使人们对文章中关于这种情况的所有其他内容产生了怀疑，但它确实导致了解决方案，所以这也是。

正如文章所建议的，我输入了以下代码，该代码在页面的 Init 事件中注入了一个 p3p（隐私偏好项目 - 我从未听说过）标头：

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

...这就解决了问题。

【讨论】：

【解决方案3】：

Re：“HTTP 协议背后的全部理念；URL 将始终指向唯一的位置”

为了安全性和可扩展性，我从同一个 URL 提供整个 CMS（主要使用 POST 而不是 GET 参数）。我不希望安全内容在没有身份验证的情况下可见，并且调度系统使我的开发更容易，因为我不必担心每个新页面的身份验证。

此外，对于某些应用程序，SEO 不适用（例如基于 Web 的 ERP）。

我使用 iFrame 从 PHP 生成的程序集树中提供内容。每当用户想要查看零件/装配体的详细信息时，我不希望刷新树（和节点可见性）。

【讨论】：

很高兴我不是您的用户之一！（完全所有都无法为它添加书签！）

【解决方案4】：

有几个usability and accessability issues with iframes。某些浏览器和屏幕阅读器无法显示 iframe，因此您应该提供替代内容：

<iframe src="content.html">
    <p>
        This content will only be displayed by browsers that do not support
        iframes. You should provide a link to the content, or in your 
        case an alternative way to use your widget.
    </p>
</iframe>

如果您开始提供第三方内容，则应注意 iframe 在完成加载后抓取焦点。虽然对于普通用户来说是一个小麻烦，但对于使用屏幕阅读器浏览的用户来说可能会非常混乱。

【讨论】：

【解决方案5】：

iframe 并不邪恶，它们只是与其他任何工具一样的另一种工具，要确定它们的优点，您必须确定它们的使用环境。 Google 图片搜索和其他几个知名网站将 iframe 用于有限目的。

一般来说，我发现它们用于品牌推广或使用户能够返回将用户重定向到站点外的站点。

注意，如果您使用的是跨域 iframe，例如一个 iframe 引用了页面所在域之外的域，出于安全原因，您受到设计的限制，并且无法通过 javascript 访问与其关联的域之外的 DOM 的内部。

另外请注意，许多网站会阻止他们的网站被嵌入，并会删除 iframe（将顶部 url 重定向到他们的域）。

【讨论】：

【解决方案6】：

我不同意大多数人的观点，并说是的，iframe 是一个绝对糟糕的想法。任何在网页设计社区工作过一段时间的人都会同意 iframe 纯粹是邪恶的，应该避免使用，除非绝对必不可少。

我认为它们不好的原因是因为它们破坏了网页的导航模式。通过使用 iframe，您可以有效地破坏浏览器上的后退和前进按钮并迷惑用户。它打破了 HTTP 协议背后的整个想法；一个 URL 将始终指向一个唯一的位置。如果 iframe 是一匹马，它早就退役了。还有其他方法可以动态提供内容，应该使用这些方法。

如果您正在创建一个 widget，那么使用 iframe 的直接担忧就会消失（对搜索引擎不利，对书签不利等），但无论哪种方式，内容都会更好地动态提供，甚至在一个新窗口而不是 iframe。

【讨论】：

-1 正如另一个答案中所说：“它本身既不好也不坏，但根据手头的任务可能是好是坏”。此外，后退和前进按钮的问题并非特定于 iframe，其他动态内容也会出现。

【解决方案7】：

从技术上讲，iFrame 与替代品相比并没有什么问题。但从语义上讲，有恶。

Web 基于 HTTP，该协议规定给定的 URL 将始终指向唯一的资源。

使用 iFrame，您只需为所有资源提供一个 URL 后面的网页中融合的多个资源。如果您担心 Web 应该如何发展，那就麻烦了。而且，对于搜索引擎机器人来说，这很棘手。

【讨论】：

【解决方案8】：

根据我的经验，iframe 要么是黑客，要么是节省时间 - 确保如果您使用它们，出于这些原因，它们是必要的。如果您可以控制内容（或者可以通过镜像或抓取来获得控制），您应该考虑使用 AJAX 或服务器端包含将外部数据拉到页面上并将其推送到页面上 - 它最终会更加灵活，更多功能强大，最终更易于管理。

【讨论】：

【解决方案9】：

我知道他们只有一件“非常糟糕”的事情。

如果您的第 3 方执行了一些 JavaScript，则尝试修改其 DOM 有点过早...IE6 和 IE7 将抛出如此无用的“Operation Aborted”错误，然后 不仅要清除 iframe，还要清除整个周围页面。（例如，您的网站出现故障）

在 IE8 中没有修复，但崩溃处理得更好。

【讨论】：

【解决方案10】：

就个人而言，我会避免它如果可以的话没有太多麻烦。使用 Javascript（或 AJAX，如果您需要动态加载它们），您可以很容易地使用 div 并根据需要更改内容 - 在某些情况下，这将为您提供更大的灵活性并简化您的 JS，特别是如果有很多您的小部件与页面其余部分之间的交互。

也就是说，我会调查这两个选项，如果 JS 路径看起来太棘手或太复杂，请使用 iframe。

【讨论】：

【解决方案11】：

在 XMLHTTPRequest 被广泛使用之前，人们使用 JavaScript 和 iframe 的组合来以动态方式提供内容，而无需刷新整个页面。

有很多关于以这种方式开发网站的信息，因此您应该可以相对轻松地找到解决许多您可能遇到的障碍的解决方法。

我发现让我感到痛苦的一件事是在 iframe 中跨域使用 JavaScript。如果您在 iframe 中嵌入的页面来自与“父”页面不同的域，则浏览器具有不允许您从另一个访问其中一个的安全限制。诀窍是两个页面都声明

document.domain = 'somedomain.com';

网上有很多关于这种解决方法的资料。

祝你好运！

【讨论】：

我相信他们只能将 document.domain 更改为更高级别的域 - 即 www.acme.com 可以将域更改为 acme.com，但不能更改为 google.com。因此，这只有助于 iframe 跨单个域的子域进行通信。（我可能是错的，但这就是我记得的）
@Josh - 你是对的，document.domain 仅适用于同一父域但不同子域的页面。
@Josh 你是对的，但你总是可以使用window.location.href。

【解决方案12】：

不一定，只要 iframe 中的内容是可预测的。

【讨论】：

【解决方案13】：

一个不错的选择是使用溢出 CSS 属性。默认值是可见的，但您可以将其设置为隐藏、滚动或自动。我会在你的情况下使用 auto 。如果您的内容太大，看起来您有一个 iframe，但它仍然在页面上。

见：overflow property

【讨论】：

【解决方案14】：

iframe 与框架一样，只是用于手头任务的控件。因此，它本身没有好坏之分，但根据手头的任务和客户的要求可能是好是坏。据我所知，所有现代浏览器（以及非 Linux 用户）都可以毫无问题地“查看和使用”iframe。

【讨论】：

【解决方案15】：

取决于小部件的功能。 iframe 有它们的位置，但它们确实很少引起布局问题（更不用说让你的 js 更复杂了），所以大多数人倾向于避免它们，除非绝对必要。..

【讨论】：

【解决方案16】：

不，iframe 没有任何问题。如果您要开始提供第三方内容，iframe 可能是一个更好的主意。

即将发布的 HTML5 规范还计划在 iframe 中针对此类情况构建更多安全功能，因此我认为现在也使用它们是一种好习惯。

【讨论】：

我在这里 +1 - 当然，唯一需要注意的是确保使用非常理想（即，而不是简单地使用 Ajax 来获取所需的数据 - 服务器总是可以获取和解析“第三方内容”并通过带外调用检索）。