在某个地方，我发现使用 iframe 是“不好的做法”。
这是真的？使用它们的优点/缺点是什么？
htxt
问问题
190142 次
11 回答
235
与所有技术一样，它有起有落。如果您使用 iframe 绕过一个适当开发的站点，那么这当然是不好的做法。但是有时 iframe 是可以接受的。
iframe 的主要问题之一与书签和导航有关。如果您使用它只是在您的内容中嵌入一个页面，我认为这很好。这就是 iframe 的用途。
但是，我也看到过 iframe 被滥用。它永远不应用作您网站的组成部分，而应作为网站中的一部分内容。
通常，如果您可以在没有 iframe 的情况下执行此操作，那是一个更好的选择。我相信这里的其他人可能有更多信息或更具体的示例，这一切都归结为您要解决的问题。
话虽如此，如果您仅限于 HTML 并且无法访问 PHP 或 ASP.NET 等后端，有时 iframe 是您唯一的选择。
于 2008-12-12T13:36:58.513 回答
81
它们不是坏习惯，它们只是另一种工具，它们增加了灵活性。
用作标准页面元素......它们很好，因为它们是一种将内容分离到多个页面的简单可靠的方法。iframe尤其是对于用户生成的内容，将内部页面“沙箱化”到一个不影响主页的糟糕标记中可能很有用。不利的一面是，如果您引入多层滚动（一层用于浏览器，一层用于iframe），您的用户会感到沮丧。就像 adzm 所说，您不想使用iframe主要导航，而是将它们视为等同于嵌入视频或其他媒体文件的方式的文本/标记。
对于脚本背景事件，通常在隐藏iframe和XmlHttpRequest加载当前页面内容之间进行选择。不同之处在于iframe生成页面加载，因此您可以在大多数浏览器的浏览器缓存中前后移动。请注意，到处使用的 Google在某些情况下XmlHttpRequest也使用iframes 来允许用户在浏览器历史记录中前后移动。
于 2008-12-12T13:41:26.757 回答
31
在不了解它们的缺点的情况下使用它们是“不好的做法”。Adzm 的帖子很好地总结了它们。
另一方面，gmail 在后台大量使用 iFrame 来实现一些更酷的功能（例如自动文件上传）。如果您知道 iFrame 的局限性，我认为您不会对使用它们感到内疚。
于 2008-12-12T13:47:11.130 回答
19
在许多情况下与他们合作后，我真的开始认为 iframe 是 goto 语句的 Web 编程等价物。也就是说，通常要避免的事情。在站点内，它们可能会有些用处。然而，跨站点，除了最简单的内容之外，它们几乎总是一个坏主意。
考虑可能性......如果用于参数化内容，他们已经创建了一个界面。而在专业站点中，该界面需要 SLA 和版本管理——在急于上网时几乎总是被忽略。
如果用于活动内容 - 承载脚本的框架 - 则存在（不同的）跨域脚本限制。有些可能会被黑客入侵，但很少会始终如一。如果您的框架内容需要交互，那么超出框架将难以做到这一点。
如果与许可内容一起使用，则参与站点需要在主机之间将权利信息移出带外。
因此，尽管它们在站点中偶尔有用，但它们相当不适合混搭。您可以更好地查看真正的门户和 portlet。更糟糕的是，它们是每个网络爱好者的宠儿——许多技术经理都将它们视为解决许多问题的方法。事实上，他们创造了更多。
于 2010-01-29T16:41:31.487 回答
10
根据我的经验，iframe 的积极方面是在调用第三方代码时，这可能涉及调用调用 a 的 javascript 具有Document.write();命令。您可能知道，由于解析方式（DOM Parser 等），这些命令不能被异步调用。这方面的一个例子是http://sourceforge.net/projects/phpadsnew/我已经使用 iframe 来帮助加快我们的网站，因为有多个对 phpadsnews 的调用，并且该网站在继续渲染之前等待响应页面的一部分。使用 iframe，我能够允许网站呈现页面的其他部分，并且仍然Document.write()异步调用 ppads 的命令。防止和js锁定。
于 2013-06-17T06:16:05.430 回答
8
肯定有 iframe 人的用途。您还会如何将天气网络小部件放在您的页面上？唯一的另一种方法是获取他们的 XML 并解析它，但是当然你需要条件来抛出相关的天气图形……这并不值得，但如果你有时间的话，它会更干净。
于 2010-03-03T15:40:23.947 回答
6
从可用性的角度来看，最初的框架集模型（框架集和框架元素）非常糟糕。IFrame 是后来的发明，它没有原始框架集模型那么多问题，但它确实有其缺点。
如果您允许用户在 IFrame 内导航，则链接和书签将无法按预期工作（因为您为外部页面的 URL 添加了书签，而不是 iframe 的 URL）。
于 2008-12-13T14:31:13.413 回答
5
值得注意的是，无论用户的互联网连接速度或 iframe 的内容如何，iframe 都会导致页面下载速度出现小幅（0.3 秒左右）但明显减慢。这不是您在本地测试时会看到的。实际上，对于添加到页面的任何元素都是如此，但 iframe 似乎更糟。
于 2008-12-12T13:54:52.363 回答
5
当您的主页以 HTTP 协议加载并且您的部分页面需要以 HTTPS 协议工作时，iFrame 可以轻松击败 jsonp。
特别是，如果您的 dataType 不是原生 json 并且需要在服务器上翻译成 json 并在客户端翻译回例如复杂的 html。
所以不 - iFrame 并不邪恶。
于 2013-08-05T10:19:14.860 回答
5
它们还不错，但实际上很有帮助。前段时间我遇到了一个大问题，我必须嵌入我的 twitter 提要，它只是不允许 md 在同一页面上执行此操作，所以我将它设置在不同的页面上，并将其作为 iframe 放入。
它们也很好，因为所有浏览器（和手机浏览器）都支持它们。只要您正确使用它们，它们就不能被认为是一种不好的做法。
于 2013-08-05T10:29:40.400 回答
4
我已经看到 IFRAME 作为一种制作动态上下文菜单的简单方法非常成功地应用，但该 Web 应用程序的目标受众只是 Internet Explorer 用户。
我会说这完全取决于您的要求。如果您希望确保您的页面在每个浏览器上都能正常运行，请避免使用 IFRAME。如果您的目标受众是狭窄且知名的受众（例如，在本地 Intranet 上）并且您看到使用 IFRAME 的好处，那么我会说这样做是可以的。
于 2008-12-12T13:43:21.420 回答