IFrame（HTML）是否过时？
得到矛盾的信息，希望他们不是。 我无法想象支持它会停止，因为一个gazillion网站使用它们。
还有一些问题：
- 他们为什么要淘汰这个标签？
- 任何替代它？
在我看来 ，W3C跳过了从严格的HTML和XHTML文档types转储iframe的枪。 从理论上说，您可以使用<object>元素将外部对象添加到您的文档中，但是浏览器的差异和局限性使得这对许多开发人员来说是不起眼的。 随着更实用的HTML 5（仍然是一个草案），iframes回来，甚至有两个新的属性： seamless ，和有趣的sandbox 。
在HTML 5中仍然存在对<iframe>支持，所以我不认为这会在不久的将来改变。
回答你的其他问题：
- 一般来说，
<iframe>大部分时间都不是用户友好的：- 它们不允许通过URL轻松访问框架中的内容（至less不会丢失框架以外的内容）。
- 大多数“技术恐惧”用户都被框架激怒了。
- 据我所知，他们浏览器渲染速度较慢
- 替代scheme包括dynamic页面生成（SSI，PHP，Rails等）和使用JavaScript / AJAX来改变例如一个
<div>
要清楚：我正在谈论<iframe>作为一个界面元素。 加载其他内容（例如Google Mail）并不是一个隐藏的元素。
iframe对于页面布局已经过时了。 切勿使用它们代替良好的CSS布局，即使基于表格的布局也更好。
使用iframe的好理由是：
- 广告 ：adwords例如使用这种技术，这是封装好 – 广告的CSS不会破坏你的网页。
- 隐藏的iframe ：它可以用于数百种可用的东西，如跟踪，ajax替代等。
IFrames不是过时的，但使用它们的原因是很less见的。
- 使用IFrame来为自己的内容提供服务，会在访问该区域的内容时创build一道“墙”。
- 对于像Google这样的抓取工具来说，目前还不清楚iframe中的有效内容会如同内容仅仅是页面的一部分一样高度排名。 对于很多人来说，这是不够用的原因。
- 它使得IFrame的DOM不易被类似jQuery，prototype等工具所访问。
使用iframe的原因：
- 将其他人的东西从其他领域中分离出来是很好的，但是并没有顺利地融合。 （样式表，JavaScript等…）
- 与使用embedded标签相比，集成多媒体有时可以通过iframe更容易完成。
- 真的，真正专业的情况下，如Gmail的情况下，他们正在使用它的声音和历史pipe理。
我也会回答说，没有必要删除iframe，这是一个需要的标签，将在一段时间。
我见过很多论坛，build议将Object标签作为IFrame的替代品，这在大多数情况下可能适用。
例如，我有一个PDF显示在IFrame中（因为除了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就像它自己的页面（基本上是一个窗口内的一个窗口），一旦你得到窗口对象，就可以调用.print（），如：
jQuery("#confirmed_pdf").contentWindow.print();
IFrame具有contentWindow属性，这使得只打印该部分成为可能。 对象没有contentWindow属性，所以没有办法只打印页面的部分。
所以，看起来如果你只是使用IFrame来显示一些东西，还有其他的标签，比如Object，可以用来代替。 但是，如果您需要以某种方式与IFrame的内容交互，那么IFrame可能是必需的。
IFrames与AJAX使用很多。 例如，GMail使用了我相信的九个隐藏的IFrame。
IFrames没有死，但Frameset / Frames正在死亡。
在IE （IE7 / IE8）的最后两个版本中，缩放帧（而不是IFrame）造成了灾难性的结果。
通过一切手段使用IFrames，但恕我直言，保持清除Framesets / Frames。
在我以前的公司，我们提供了一个托pipe的应用程序，客户将整合到自己的网站。 有时候，他们会使用IFrame来做到这一点，使我们的托pipe页面适合他们现有的devise。 有时甚至可以无缝地完成（即IFrame没有边框或滚动条，它看起来就像是页面的一部分）。 我认为这是一个很好的使用标签。
在某些情况下，它们可能非常有用，但这些都是有限的。 特别是跨多个站点embedded通用function。
例如，我有一个经营多个苏格兰商品电子商务网站的客户。 作为其中的一部分，我们已经开发了一些简单的应用程序，从您的姓氏或您select的格子呢（可能是傻笑，但是格子花呢每年价值7亿美元）中find可能的氏族名称。 背后的数据库是惊人的大（核心名称和格子呢表中近一万行），并定期更新。
因此，我们将应用程序设置为在一个网站上运行，然后使用iframe将这些应用程序embedded到其他网站中，从而实现简单的JavaScriptparameter passing，从而可以在embedded网站上集成select格子呢或家族的function。 iframe被设置为noborder，因此它对于最终用户来说显得完全无缝。
当然，还有其他方法可以做到这一点，但是iframe的使用简单而强大。 这当然不是过时的。
马匹的课程… <iframe>就像其他任何东西…为正确的目的，他们是正确的工具; 为了错误的目的，他们是一个丑陋的黑客，或更糟糕的。
在Ajax中，<div>通常是更合适的容器。 在某些地方，由<iframe>支持的将外部内容作为自己站点的一部分进行传播的行为是不合适的。
我的团队有一天使用了一个<iframe>作为让用户访问他们的HTML电子邮件历史的理想方式 – 电子邮件是完整的<html>页面，我们想要很容易地将其插入到我们的网页模板中。 <iframe>对于呈现数据来说绝对是完美的]。
另一方面，在任何用户提交的内容输出回站点的情况下，几乎总是应该删除或禁用<iframe>，因为在这种情况下，它们是一个主要的安全问题。
Google小工具规范目前依赖于iframe： http : //code.google.com/apis/gadgets/docs/spec.html
目前，它们是为从多个域/提供者提取的javascript应用提供隔离的唯一简单方法。
人们在第三方网站上embedded的许多小部件也使用iframe。
虽然他们有缺点，但内联框架为networking上的常见问题提供了实用的解决scheme。 我不得不猜测他们会在一段时间后面。
我刚刚改变了一个网站从一个正常的Frameset到Iframes正常帧不能做我所需要的。 它没有引起其他代码库的问题。
合规性和安全性问题也可能促使您使用Iframe; 购物车是stream行的基于IFrame的实现，当您想要将购物车作为某些网页的一部分进行可视化时，无需对付款处理方面承担全部责任。
我们通常提供一个Iframe来整合我们的电子商务内容和客户端，比如它可以成为一个交钥匙。
我为一家从下拉菜单，列表，内容块等等中使用框架的公司工作，只是为了覆盖.NET Web表单的复杂性。 该应用程序非常慢，只能在IE上运行。 不要这样做。
