Are iframes a terrible idea?我正在构建一个小部件，并且一直在使用 iframe 来呈现其中的内容。在某个时候，我可能会开始提供第三方 HTML 和 JS，所以我认为 iframe 会是一个好主意。 它确实使小部件 javascript 有点复杂，我担心这可能不是最好的实现。 你有什么建议吗？听听其他人对 iframe 的看法会很有帮助。 不，iframe 没有任何问题。如果您要开始提供第三方内容，iframe 可能是一个更好的主意。 即将发布的 HTML5 规范还计划在 iframe 中针对此类情况构建更多安全功能，因此我认为现在也使用它们是一种好习惯。 在 XMLHTTPRequest 被广泛使用之前，人们使用 JavaScript 和 iframe 的组合以动态方式提供内容，而无需刷新整个页面。 有很多关于以这种方式开发网站的信息，因此您应该可以相对轻松地找到解决许多您可能遇到的问题的解决方法。 我发现让我头疼的一件事是在 iframe 中跨域使用 JavaScript。如果您在 iframe 中嵌入的页面来自与"父"页面不同的域，则浏览器具有不允许您从另一个访问其中一个的安全限制。诀窍是两个页面都声明
网上有很多关于这种解决方法的资料。 祝你好运！ 我最近发现的一件事是，嵌入在 iframe 中的 .aspx 页面有时会出现丢失 cookie 的问题，这导致我参与的应用程序中的会话状态丢失。 对我来说，这是在不同的开发商店在他们自己的页面中使用我的一个 .aspx 页面的情况下发生的。这意味着我们在不同的服务器上，这些服务器可能很突出，也可能不突出。 显然这是由父页面拒绝子页面的 cookie 引起的……会话 cookie 也是如此，会话也是如此。 它的工作原理有点复杂：更多细节 这个问题并没有影响到 FireFox，但它确实出现在 IE7 中，并且在几个小时内一直是个谜。 另外，我必须在一点上与上面链接的文章相矛盾。文章说，如果包含页面也是 .aspx，则您不会得到这个......在这种情况下，这不是真的，因为两个页面都是 .aspxs。 这让人对文章中关于这种情况的所有其他内容产生怀疑，但它确实导致了解决方案，所以这也是。 正如文章所建议的，我输入了以下代码，该代码在页面的 Init 事件中注入了一个 p3p(隐私偏好项目 - 我从未听说过)标头：
...这就解决了问题。 我将不同意大多数人的观点，并说是的，iframe 是一个绝对糟糕的主意。任何在网页设计社区工作过一段时间的人都会同意 iframe 是纯粹的邪恶，除非绝对必要，否则应该避免使用。 我认为它们不好的原因是因为它们破坏了网页的导航模式。通过使用 iframe，您可以有效地破坏浏览器上的后退和前进按钮并迷惑用户。它打破了 HTTP 协议背后的整个想法；一个 URL 将始终指向一个唯一的位置。如果 iframe 是一匹马，它早就退役了。还有其他动态提供内容的方法，应改为使用这些方法。 如果您正在创建一个小部件，那么使用 iframe 的直接担忧就会消失(对搜索引擎不利，对书签不利等)，但无论哪种方式，内容都会更好地动态提供，甚至在新窗口中而不是在iframe. 我知道他们只有一件"非常糟糕"的事情。 如果您的第 3 方执行了一些 JavaScript，那么尝试修改他们的 DOM 有点过早... IE6 和 IE7 会抛出如此无用的"操作中止"错误，然后不仅会清空 iframe，而且会清空整个周边页面。 (例如，您的网站出现故障) 在 IE8 中没有修复，但崩溃处理得更好。 根据我的经验，iframe 要么是 hack，要么是节省时间 - 确保如果您使用它们，出于这些原因，它们是必要的。如果您可以控制内容(或者可以通过镜像或抓取来获得控制)，您应该考虑使用 AJAX 或服务器端包含将外部数据拉到页面上并将其推送到页面上 - 它最终会变得更加灵活，更多健壮，最终更易于管理。 就我个人而言，如果你可以避免太多麻烦，我会避免它。使用 Javascript(或 AJAX，如果您需要动态加载它们)，您可以很容易地使用 div 并根据需要更改内容 - 在某些情况下，这将为您提供更大的灵活性并简化您的 JS，特别是如果有很多您的小部件与页面其余部分之间的交互。 也就是说，我会调查这两个选项，如果 JS 路径看起来太棘手或太复杂，那就使用 iframe。 iframe 和框架一样，只是用于手头任务的控件。因此，它本身既不好也不坏，但根据手头的任务和客户的要求可能是好是坏。据我所知，所有现代浏览器(以及非 Linux 用户)都可以毫无问题地"查看和使用"iframe。 取决于小部件的功能。 iframe 有它们的位置，但它们确实很少引起布局问题(更不用说让你的 js 更复杂了)，所以大多数人倾向于避免它们，除非绝对必要.. iframe 并不邪恶，它们只是与其他任何工具一样的另一种工具，要确定它们的优点，您必须确定它们的使用环境。 Google 图片搜索和其他几个知名网站将 iframe 用于有限目的。 总的来说，我发现它们用于品牌推广或使用户能够返回将用户重定向到站点之外的站点。 注意，如果您使用的是跨域 iframe，例如一个 iframe 引用了页面所在域之外的域，出于安全原因，您受到设计的限制，并且无法通过 javascript 访问与其关联的域之外的 DOM 的内部。 另外请注意，许多网站会阻止他们的网站被嵌入，并会删除 iframe(将顶部 url 重定向到他们的域)。 一个不错的选择是使用溢出 CSS 属性。默认值是可见的，但您可以将其设置为隐藏、滚动或自动。我会在你的情况下使用 auto 。如果您的内容太大，它看起来就像您有一个 iframe，但它仍然在页面上。 参见：溢出属性 从技术上讲，iFrame 与替代品相比并没有什么问题。但从语义上讲，有恶。 Web 基于 HTTP，该协议规定给定的 URL 将始终指向唯一的资源。 使用 iFrame，您只需为所有资源提供一个 URL 后面的网页中融合的多个资源。如果您担心 Web 应该如何发展，那就麻烦了。更重要的是，对于搜索引擎机器人来说，这很棘手。 iframe 存在一个重大问题，几乎没有人提及，但它让我感到厌烦。 我们的同事毕生致力于一个动态变化的数据库，我们已将其加载到 Google Docs 电子表格中，然后我们将其与大量支持材料一起显示在我们的网站上。 绝对没有什么可以阻止有人从我的页面源中抓取 iframe 代码并将其推送到他们的页面上。现在他们正在获取我们所有的数据，这些数据在几分钟前刚刚刷新，完全免费提供到他们的页面。 如果一个 google iframe 可以绑定到一个特定的域，那将停止它的Rails。 有什么想法，有火花吗？ 回复："HTTP 协议背后的全部理念；URL 将始终指向唯一的位置" 为了安全性和可扩展性，我从同一个 URL 为我的整个 CMS 提供服务(主要使用 POST 而不是 GET 参数)。我不希望安全内容在没有身份验证的情况下可见，并且调度系统使我的开发更容易，因为我不必担心每个新页面的身份验证。 此外，对于某些应用程序，SEO 不适用(例如基于 Web 的 ERP)。 我使用 iFrame 从 PHP 生成的程序集树中提供内容。每当用户想要查看零件/装配体的详细信息时，我都不想刷新树(和节点可见性)。 不一定，只要 iframe 中的内容是可预测的。 iframe 存在几个可用性和可访问性问题。某些浏览器和屏幕阅读器无法显示 iframe，因此您应该提供替代内容：
如果您开始提供第三方内容，则应注意 iframe 在完成加载后抓取焦点。虽然对于普通用户来说是一个小烦恼，但对于使用屏幕阅读器浏览的用户来说可能会非常混乱。 |
