Iframe（HTML）已过时吗？[关闭]

Question 1

收到与此矛盾的消息，希望它们不是。我无法想象它会停止支持，因为无数的网站都在使用它们。

关于此的一些其他问题：

他们为什么要逐步淘汰此标签？
还有其他选择吗？

Question 2

以我的观点，W3C在转储Strict HTML和XHTML文档类型的iframe时大开眼界。从理论上讲，您可以使用<object>元素将异物添加到文档中，但是对于许多开发人员来说，浏览器的差异和局限性使其毫无用处。使用更加实用的HTML 5（仍是草稿），iframe又回来了，甚至具有两个新属性：seamless和有趣的sandbox。

Question 3

<iframe>HTML 5仍然支持该功能，因此我认为这不会在不久的将来改变。

要回答您的其他问题：

<iframe>s（通常是框架）在大多数情况下都不友好：
- 它们不允许通过URL轻松访问框架中的内容（至少不会在框架外丢失内容）。
- 大多数“技术恐惧症”用户都会被框架感到烦恼。
- 据我所知，它们对于浏览器的渲染速度较慢
替代方法包括动态页面生成（SSI，PHP，Rails等），以及使用JavaScript / AJAX更改例如 <div>

需要明确的是：我正在谈论<iframe>作为接口元素。不是用于加载其他内容（例如Google Mail）的隐藏元素。

Question 4

iframe 对于页面布局而言已过时。切勿使用它们代替良好的CSS布局，即使基于表的布局也更好。

使用iframe的充分理由是：

ads：例如adwords使用这种技术，它非常适合封装-ad CSS不会破坏您的页面。
隐藏的iframe：它可用于数百种有用的东西，例如跟踪，Ajax替代等。

Question 5

IFrame并不是过时的，但是使用它们的原因很少。

使用IFrame来提供自己的内容会在访问该区域的内容周围形成一堵“墙”。
对于像Google这样的抓取工具，目前尚不清楚iframe中的内容排名是否会像内容只是页面的一部分一样高。对于许多人来说，这是足够的理由不使用它。
它使jQuery，prototype等工具无法访问iframe的DOM。

使用iframe的原因：

这对于隔离其他域中的其他人的内容非常有用，但它无法顺利集成。（样式表，JavaScript等...）
与使用embed标签相反，有时通过iframe可以更轻松地集成多媒体。
确实，非常专业的案例，例如gmail案例，他们将其用于声音和历史记录管理。

我还要回答的是，无需移除iframe，这是一个必需的标记，并且会保留一段时间。

Question 6

我见过很多论坛建议使用Object标记代替IFrame，在大多数情况下都可以使用。

例如，我在IFrame中显示了一个PDF（因为除了PDF之外，我们还需要在页面上显示其他内容），并且能够使用Object使其正常显示。

什么是：

<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>

成为：

<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
  <p>[Show this message if displaying the PDF did not work]</p>
</object>

但是Object并不是满足只能打印页面PDF部分的要求的合适替代品。

IFrame就像页面中自己的窗口（基本上是窗口中的窗口）一样，一旦获得window对象，就可以在其上调用.print（），例如：

jQuery("#confirmed_pdf").contentWindow.print();

IFrame具有contentWindow属性，这使得仅打印该部分成为可能。对象没有contentWindow属性，因此无法只打印页面的一部分。

因此，似乎如果您仅使用IFrame来显示内容，则可以使用其他标记（例如Object）来代替。但是，如果您需要以某些方式与IFrame的内容进行交互，则可能需要使用IFrame。

Question 7

IFrame与AJAX一起使用很多。以GMail为例，我相信使用了九个隐藏的IFrame。

Question 8

IFrame还没有死，但是Frameset / Frames快死了。

在IE的最新2个版本（IE7 / IE8）中，放大帧（不是IFrame）会带来灾难性的结果。

一定要使用IFrame，但是恕我直言，不要使用Framesets / Frames。

Question 9

在我以前的公司中，我们提供了一个托管应用程序，客户可以将其集成到自己的网站中。有时，他们会使用IFrame来做到这一点，从而将我们的托管页面适合其现有设计。有时，这甚至是无缝完成的（即，iframe没有边框或滚动条，只是看起来像页面的一部分）。我认为这是标记的很好的用法。

Question 10

在某些情况下，它们可能非常有用，但那是有限的。特别是在多个站点之间嵌入通用功能。

例如，我有一个客户，他经营着许多苏格兰商品电子商务网站。为此，我们开发了一些简单的应用程序，可以从您的姓氏或选择的格子呢中找到可能的氏族名称（如果愿意，可以咯咯笑，但格子呢对我们的经济每年价值7亿美元）。它背后的数据库非常大（核心名称和tartans表中有近一万行）并且定期更新。

因此，我们将应用程序设置为可以在一个网站上运行，然后使用iframe将其嵌入到我们的其他网站中，从而实现简单的javascript参数传递，因此我们可以将格子呢或氏族的选择与嵌入网站上的功能集成在一起。iframe设置为noborder，因此对于最终用户而言似乎是无缝的。

当然，还有其他方法可以执行此操作，但是使用iframe既简单又健壮。而且它当然不会过时。

Question 11

课程的马... <iframe>就像其他任何东西...出于正确的目的，它们是正确的工具；出于错误的目的，他们是丑陋的黑客，或更糟的是。

在Ajax中，<div>通常是更合适的容器。在某些地方，如<iframe>所支持的那样，冒充外部内容作为您自己的网站的一部分的活动是不合适的。

前几天，我们的团队使用<iframe>作为向用户访问其HTML电子邮件历史记录的理想方式-电子邮件是完整的<html>页面，我们希望将其轻松插入到Web模板中。<iframe>非常适合呈现该数据]'。

另一方面，<iframe>几乎应该总是在任何用户提交的内容中被删除或禁用，这些内容会输出回站点，因为在这种情况下，它们是主要的安全问题。

Question 12

Google小工具规范当前依赖于iframe：http : //code.google.com/apis/gadgets/docs/spec.html

当前，它们是为从多个域/提供者提取的javascript应用程序提供隔离的唯一简单方法。

人们从第三方嵌入到其网站上的许多小部件也使用iframe。

尽管它们确实有其缺点，但是iframe提供了实用的解决方案来解决网络上的常见问题。我不得不猜测它们会存在一段时间。

Question 13

我刚刚将网站从普通框架集更改为iframe，因为普通框架无法满足我的需求。其余代码库均未引起任何问题。

Question 14

合规性和安全性问题也可能促使您使用iframe；当您希望以可视方式将购物车作为某些网页的一部分合并而无需完全负责支付处理工作时，购物车是基于IFrame的流行实现。

我们通常会提供一个Iframe来集成我们的电子商务内容和客户，例如交钥匙方式。

Question 15

我在一家公司工作，该公司从下拉菜单，列表，内容块等使用框架来处理所有内容，只是为了掩盖.net Web表单的复杂性。该应用程序非常慢，只能在IE上运行。不要这样