iframe被认为是"不良做法"吗？

沿着这条线的某个地方,我发现使用iframe是'糟糕的做法'.

这是真的？使用它们的优点/缺点是什么？

1> adzm..：

---

与所有技术一样,它有起伏不定.如果您使用iframe来绕过正确开发的网站,那么当然这是不好的做法.但有时候iframe是可以接受的.

iframe的主要问题之一与书签和导航有关.如果您使用它只是在您的内容中嵌入一个页面,我认为这很好.这就是iframe的用途.

但是我看到iframe也被滥用了.它绝不应该用作您网站的组成部分,而应该用作网站内的一部分内容.

通常,如果你可以在没有iframe的情况下做到这一点,那么这是一个更好的选择.我相信这里的其他人可能有更多的信息或更具体的例子,这一切都归结为你想要解决的问题.

话虽如此,如果您仅限于HTML并且无法访问PHP或ASP.NET等后端,有时iframe是您唯一的选择.

---

@ developer747 - 如果由于[相同的原始政策](http://en.wikipedia.org/wiki/Same_origin_policy),外部内容在另一个网站上,那将无效.在一些不起眼的案例中,远程站点可能支持[JSONP](http://en.wikipedia.org/wiki/JSONP); 但可能不是.

---

"如果你只限于HTML并且无法访问像PHP或ASP.NET等后端,有时候iframe是你唯一的选择"......那不是真的.您可以通过jquery ajax获取数据,然后使用该数据填充div,从而在页面中嵌入外部内容.

---

应该提到的是,iframe是目前定义嵌套CSS范围的唯一方法.它们将外部文档中的内部标记,布局,样式和Javascript*隔离开来,这在许多用例和应用程序中很有用.*如果内部文档与外部文档共享原点,则Javascript不会被隔离; 另一方面,来自不同来源的文档仍然可以使用`window.postMessage()`进行通信,例如实现协作iframe自动调整大小.

---

我觉得iframe的效果远不如前框架集,因为用户无法调整iframe的大小 - 但我不会将框架集用于手册,因为它不再存在于html5中.示例:[游戏制作者手册](http://docs.yoyogames.com/)

2> Tom..：

---

它们并非坏习惯,它们只是另一种工具,它们增加了灵活性.

用作标准页面元素......它们很好,因为它们是将内容分成几个页面的简单而可靠的方法.特别是对于用户生成的内容,将内部页面"沙箱化"为iframe如此差的标记可能会有用,这不会影响主页面.缺点是如果你引入多层滚动(一个用于浏览器,一个用于浏览器iframe),你的用户会感到沮丧.就像adzm所说的那样,你不想使用iframe主导航,而是将它们视为与视频或其他媒体文件嵌入方式等效的文本/标记.

对于脚本背景事件,选择通常在当前页面的隐藏iframe和XmlHttpRequest加载内容之间.不同之处在于iframe生成页面加载,因此您可以使用大多数浏览器在浏览器缓存中前后移动.请注意,在某些XmlHttpRequest地方使用的Google 也会iframe在某些情况下使用s来允许用户在浏览器历史记录中前后移动.

---

我认为重要的是要提到iframe可以用于将域中的页面嵌入到另一个域的页面中.如果嵌入式页面希望跟踪带有cookie的用户并将该信息保留在主机域中,那么您唯一的选择是使用iframe,因为JS位于主机域的控制之下.

3> Chris Van Op..：

---

在不了解它们的缺点的情况下使用它们是"不好的做法".Adzm的帖子总结得很好.

另一方面,gmail在后台大量使用iFrame,以获得一些更酷的功能(如自动文件上传).如果您了解iFrames的局限性,我认为您不应该对使用它们感到任何疑虑.

4> user261975..：

---

在很多情况下与他们合作过,我真的开始认为iframe是与goto语句相当的Web编程.也就是说,通常可以避免某些事情.在网站中,它们可能有点用处.然而,跨站点,除了最简单的内容之外,它们几乎总是一个坏主意.

考虑可能性......如果用于参数化内容,他们就创建了一个界面.在专业网站中,该界面需要SLA和版本管理 - 在急于上线时几乎总是被忽略.

如果用于活动内容 - 托管脚本的框架 - 则存在(不同的)跨域脚本限制.有些可能被黑客攻击,但很少持续.如果您的框架内容需要具有交互性,那么超出框架就会很难实现.

如果与许可内容一起使用,则需要在主机之间移出授权信息,从而使参与站点负担沉重.

因此,尽管在某个站点中偶尔有用,但它们却不适合mashup.您可以更好地查看真正的门户和portlet.更糟糕的是,他们是每个网络业余爱好者的宠儿 - 许多技术经理已经将他们作为许多问题的解决方案.事实上,他们创造了更多.

5> mel3kings..：

---

根据我的经验,iframe在调用第三方代码时是积极的一面,这可能涉及调用一个调用一个Document.write();命令的javascript .您可能知道,由于它的解析方式(DOM Parser等),不能异步调用这些命令.这方面的一个例子是http://sourceforge.net/projects/phpadsnew/我已经利用iframe来帮助加快我们的网站,因为有多次调用phpadsnews并且网站在等待响应然后继续呈现不同的页面的一部分.使用iframe,我能够允许网站呈现页面的其他部分,并仍然Document.write()异步调用phpads 的命令.防止和js锁定.

6> 小智..：

---

iframes肯定会有用户.你还怎么把天气网络小部件放在你的页面上？唯一的另一种方法是获取他们的XML并解析它,但当然你需要条件来抛出相关的天气图形......不是真的值得,但如果你有时间的话会更清洁.

7> JacquesB..：

---

从可用性的角度来看,原始框架集模型(框架集和框架元素)非常糟糕.IFrame是一种后来的发明,它没有原始框架集模型那么多的问题,但确实有它的缺点.

如果您允许用户在IFrame内导航,则链接和书签将无法按预期工作(因为您将外部页面的URL添加为书签,而不是iframe的URL).

8> Jeffz..：

---

当您的主页加载HTTP协议并且页面的某些部分需要使用HTTPS协议时,iFrame可以击败jsonp.

特别是,如果你的dataType不是本机json,需要在服务器上翻译成json并在客户端上翻译成例如复杂的html.

所以nope - iFrame并不邪恶.

9> Vlad..：

---

他们不错，但实际上很有帮助。前段时间我遇到了一个很大的问题，我必须嵌入我的Twitter提要，但它不允许md在同一页面上完成，因此我将其设置在另一个页面上，并将其作为iframe放入。

它们也很好，因为所有浏览器（和电话浏览器）都支持它们。只要您正确使用它们，就不能认为它们是不良做法。