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

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

我们有什么建议吗？听到其他人对iframe的看法将对我们有很大帮助。

解决方案

不，iframe没有错。如果我们要开始投放第三方内容，则iframe可能是一个更好的主意。

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

取决于小部件的功能。 iframe占有一席之地，但是它们确实不会造成布局上的麻烦(更不用说使js更加复杂了)，因此，除非绝对必要，否则大多数人会避免使用它们。

我最近发现的一件事是，嵌入到iframe中的.aspx页有时会丢失cookie，从而导致我所涉及的应用程序中的会话状态丢失。

对我来说，这是在另一家开发商店在自己的页面中使用我的.aspx页面之一的情况下。这意味着我们在不同的服务器上，这可能是显着的，也可能不是。

显然，这是由父页面拒绝子页面的cookie导致的。会话cookie也是如此。

这项工作原理的具体机制略有涉及：更多详细信息

这个问题并没有影响FireFox，但是确实出现在IE7中，这确实是一个神秘的现象，持续了几个小时。

另外，我不得不与我上面链接到的文章矛盾。这篇文章说，如果包含页面也是.aspx ...，我们将不会得到此消息。在这种情况下，这不是正确的，因为两个页面都是.aspxs。

这使该文章对这种情况所说的其他一切都产生了疑问，但这确实导致了解决方案，所以也是如此。

正如文章所建议的，我放入了以下代码，该代码在页面的Init事件中注入了一个p3p(我从未听说过的Privacy Preferences Project)标头：

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

...这解决了问题。

与框架一样，iframe只是用于手头任务的控件。因此，它本身既不是好事也不是坏事，但根据手头的任务和客户的要求可能是好事也可能是坏事。据我所知，所有现代浏览器(和非Linux用户)都将能够"看到并使用" iframe，而不会出现问题。

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

请参阅：溢出属性

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

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

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

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

document.domain = 'somedomain.com';

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

祝你好运！

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

就是说，我将研究这两个选项，如果JS路径似乎过于棘手或者过于复杂，则只需使用iframe。

我知道，与他们只有一件"非常糟糕"的事情。

如果第三方使用了一些JavaScript，则尝试过早修改其DOM ... IE6和IE7将抛出非常无用的"操作异常终止"错误，然后不仅将iframe，而且将整个周围的页面都清除掉。 (例如，网站显示为向下)

IE8中未解决该问题，但可以更好地处理崩溃。

以我的经验，iframe是骇客或者节省时间的工具，请确保如果我们使用它们，则出于这些原因它们是必需的。如果我们对内容有控制权(或者可以通过镜像或者抓取来控制)，则应考虑使用AJAX或者服务器端包含将外部数据拉入页面并将其推离页面，这样最终将变得更加灵活，更强大，并且最终更易于管理。

从技术上讲，iFrame没有其他选择会出错。但是从语义上讲，有邪恶。

Web基于HTTP，该协议说给定的URL将始终导致唯一的资源。

使用iFrame，我们只需要在一个URL后面的Web页面中提供所有资源，这些资源就全部融合在一起。如果我们对Web的增长方式有疑问，那就麻烦了。而且，对于搜索引擎机器人来说，这很棘手。

我不同意大多数人的看法，是的，iframe是一个绝对糟糕的主意。在Web设计社区中工作了一段时间的任何人都将同意，iframe是纯粹的邪恶，除非绝对必要，否则应避免使用。

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

如果我们要创建窗口小部件，那么使用iframe的紧迫问题就会消失(对搜索引擎不利，对书签不利等)，但是无论哪种方式，都可以更好地动态提供内容，甚至可以在新窗口中而不是iframe中提供内容。

iframe并不是邪恶的东西，它们只是其他工具一样的工具，要确定其优点，我们必须确定使用它们的环境。 Google Image Search和其他几个备受瞩目的网站都将iframe用于有限的目的。

通常，我发现它们用于品牌塑造或者使用户能够返回到将用户重定向到站点之外的站点。

请注意，如果我们使用的是跨网域iframe，例如一个iframe，它指向的是该页面所服务的外部域，出于安全原因，我们受到设计的限制，并且无法通过javascript访问与其关联的域之外的DOM内部。

另外请注意，许多网站会阻止其网站被嵌入，并会剥除iframe(将顶部网址重定向到其域)。

回复：" HTTP协议的整个思想； URL始终会导致唯一的位置"

为了安全性和可伸缩性，我从同一URL为整个CMS服务(主要使用POST而不是GET参数)。我不希望没有身份验证就可以看到安全的内容，并且调度系统使我的开发更加轻松，因为我不必担心每个新页面的身份验证。

另外，对于某些应用程序，SEO不适用(例如，基于Web的ERP)。

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

iframe存在一些可用性和可访问性问题。某些浏览器和屏幕阅读器无法显示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加载完成后，应格外小心。对于普通用户而言，这是一个小麻烦，但对于使用屏幕阅读器进行浏览的用户而言，却可能非常令人困惑。