什么时候应该使用 HTML 框架？
我听过无数关于为什么不使用 HTML 框架的理由，从它们缺乏可访问性、普遍缺乏用户体验、它们完全低效/不可维护，或者它们只是过时了。
这一切让我想到两个问题：
- 这种普遍的仇恨共识是否也适用于 iframe？
- 在什么情况下可以在代码中使用框架/iframe？
I have heard countless reasons on why not to use HTML frames, from their lack of accessibility, the general lacking in UX, their being completely inefficient/unmaintainable, or them just being outdated.
This all brings me to two questions:
- Does this general consensus of hate apply to iframes as well?
- In what scenario(s) is it acceptable to use frames/iframes in your code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
(1) 不。iframe 有合法的用途，但现在没有理由在现代浏览器中使用框架。
(2) 切勿使用框架；还有其他更好更简单的解决方案可以产生相同的效果。
仅当嵌入整个站点是最合理的选择时才使用 iframe。尽管很少见，但有时这是有意义的。
简而言之，frame/frameset/noframe 标签被从 HTML5 中删除是有原因的，但 iframe 会保留下来。
（示例）如果站点 A 必须包含站点 B 的页面（代理显示来自站点 A），则站点 B 的 css 和 javascript 可以并且通常会完全控制站点 A。这是一个合法的原因。
(1) No. There are legitimate uses for iframes, where there's no reason to use frames today with modern browsers.
(2) Never use frames; there's other better easier solutions available to produce the same effect.
Use iframes only when embedding the whole site is the most logical option. Although rare, there are occasions when this makes sense.
In short, there's a reason why the frame/frameset/noframe tags are taken out of HTML5, but the iframe will carry over.
(example) If site A is obliged to include a page from site B (proxied to appear to come from site A) then site B css and javascript can and usually will completely hose site A. This is a legitimate reason.
如果由于某种原因你有“嵌套形式”。
假设您有一个产品编辑表单，在该表单内有一个包含另一个表单的区域，可以让您输入客户列表以发送该产品的新闻通讯。
客户与产品完全无关，并且与产品没有数据库关系。它们是与产品合规地分离的实体。
在本例中，我创建一个 IFrame，其中包含客户添加表单和提交按钮，用于在 IFrame 内提交表单。
我没有找到比使用 IFrame 更好的方法来实现所描述的场景。
是的，我要求将两个表单放在同一页面上，并且新闻通讯表单应放置在产品编辑表单内。业务需求由老板决定。
If for some reason you have "nested form".
Say you have a product edit form and inside this form you have an area with another form that let's say allows you to enter a list of the customers to send a newsletter for this product.
Customers are not related to the product at all and has no database relation to a product. They are compliantly separate entities from product.
In this case I crate an IFrame with a customer adding form and submit button that submits the form inside IFrame.
I didn't find any better way to implement the described scenario than using IFrame.
And yes, I have a requirement to have both forms on the same page, and newsletter form should be placed inside product editing form. Business need dictated by bosses.
您可以使用 iframe 授予对网站中第三方广告的访问权限，而无需向第三方提供任何额外的控制权或向包含 iframe 的父文档发送消息。
这样，您就可以访问网站中的广告，同时防止来自未知资源的攻击
mozilla 开发页面对此有更好的解释：
You can use an iframe to give access to ads from third parties in your website without giving them any additional control or messaging to the parent document that contains the iframe.
That way you give access to ads in your site but at the same time protect from attacks from unknown resources
The mozilla dev pages explains it better:
(1) 不是天生的。 iframe 有许多用例，这些用例不会遇到框架的问题。每当您想要混合来自另一个安全上下文的文档或没有父页面正在使用的脚本和样式时，它们都很有用。
然而，“像框架一样使用 iframe”是可能的：将页面分割成单独的 iframe 区域，跨框架链接会造成导航混乱，无法与书签很好地配合、在新选项卡中打开等。
(2) 我今天不会使用框架来做任何事情。他们保留大量您不希望在每次导航时重新加载的页面内容的用例有限。但现在我们只使用
XMLHttpRequest来更新部分页面。即便如此，如果不注意使页面更改链接可访问（使用哈希历史记录并为每个哈希链接提供静态链接类似物，与响应中间的真实
链接） -click 等），使用XMLHttpRequest更新/导航自身的页面将重新产生框架的许多导航问题，对可用性、可访问性和 SEO 产生强烈的负面影响。我觉得有点可悲的是，许多作者正在创建华而不实、时髦的“现代”动画网站，这些网站天真地使用 jQuery 的
load()或类似的方法，表现出古代所有最糟糕的行为，讨厌的框架。(1) Not inherently. iframes have many use cases that do not suffer from the problems of frames. They're useful any time you want to mix in a document from another security context, or without the scripting and styles that the parent page is using.
However, it is possible to ‘use an iframe like a frame’: to split the page up into separate iframe areas, with cross-frame-links making a navigational mess that doesn't play well with bookmarks, open-in-new-tab etc.
(2) I would not use frames for anything today. There was a limited use case for them keeping hold of large amounts of page content that you don't want to reload on each navigation. But these days we would just use
XMLHttpRequestto update part of the page instead.Even so, without care taken to make page-changing links accessible (using hash-history and having a static-link analogue for each hash-link, linked with real
<a>s that response to middle-click et al), a page that updates/navigates itself usingXMLHttpRequestwill recreate many of the navigational problems of frames, with strongly negative usability, accessibility and SEO implications.I find it a bit sad that many authors are creating flashy, swooshy, “modern” animated web sites that, by naïvely using jQuery's
load()or similar on its own, exhibit all the worst behaviours of ancient, hated frames.