Question

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

它确实使小部件javascript变得更复杂，我担心这可能不是最好的实现。

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

Answer 1

不，iframe没什么问题。如果你要开始提供第三方内容，那么iframe可能是更好的主意。

即将推出的HTML5规范还计划在这种情况下为iframe构建更多安全功能，因此我认为现在也可以使用它们。

Answer 2

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

有很多关于以这种方式开发网站的信息，所以你应该有一个相对容易的时间来找到你可能遇到的很多障碍的解决方法。

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

document.domain = 'somedomain.com';

网上有很多关于这种解决方法的内容。

祝你好运！

Answer 3

我最近发现的一件事是嵌入在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\""")

......这解决了这个问题。

Answer 4

我将不同意大多数人并且说是的，iframe是一个绝对可怕的主意。任何在网页设计社区工作一段时间的人都同意iframe是纯粹的邪恶，除非绝对必不可少，否则应该避免。

我相信他们不好的理由是因为他们打破了网页的导航模式。通过使用iframe，您可以有效地破坏浏览器上的后退和前进按钮，并使您的用户感到困惑。它打破了HTTP协议背后的整个想法; URL始终会导致唯一的位置。如果iframe是一匹马，它很久以前就会退役。还有其他方式可以动态地提供内容，而应该使用这些方法。

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

Answer 5

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

如果你的第三方做了一些JavaScript，试图过早地修改他们的DOM ...... IE6和IE7会抛出这么无助的“ Operation Aborted ”错误，然后不仅会删除iframe，还会覆盖整个周边页面。（例如，您的网站显示下来）

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

请参阅：overflow property

Answer 11

iframe不是邪恶的，它们只是其他任何工具，为了确定它们的优点，你必须确定它们的使用环境。谷歌图片搜索和其他几个高调网站使用iframe用于有限的目的。

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

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

另请注意，许多网站会阻止其网站嵌入，并会关闭iframe（将顶部网址重定向到其域名）。

Answer 12

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

Answer 13

从技术上讲，iFrame与替代品没什么关系。但在语义上，有邪恶。

Web基于HTTP，这是一种协议，表示给定的URL总是会导致唯一的资源。

使用iFrame，您只需在一个网址后面的网页中为所有这些资源提供多个资源。如果您对Web应该如何增长感到担忧，那就太麻烦了。更重要的是，对于搜索引擎机器人来说，这很棘手。

Answer 14

Re：“HTTP协议背后的整个想法; URL总是会导致一个独特的位置”

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

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

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

Answer 15

有几个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抓取焦点。虽然对于普通用户来说是一个小小的烦恼，但对于使用屏幕阅读器浏览的用户来说可能会非常困惑。

Answer 16

iframes存在一个很大的问题，很难提及，但是这会让我感到厌烦。

我们的同事在动态变化的数据库中投入了大量的工作，我们已将这些数据库加载到Google Docs电子表格中，然后我们会在我们的网站上显示许多支持材料。

绝对没有什么可以阻止某人从我的页面源抓取iframe代码并将其推送到他们的页面上。现在，他们正在获取我们所有的数据，在几分钟之前刷新，在他们的页面上完全没有任何内容。

如果谷歌iframe可以绑定到特定域，那将阻止它的轨道。

任何想法，明亮的火花？

iframe是一个糟糕的主意吗？

16 个答案: