我正在构建一个小部件,并且一直在使用 iframe 在其中呈现内容。在某个时候,我可能会开始提供第三方 HTML 和 JS,所以我认为 iframe 会是一个好主意。
它确实使小部件 javascript 更复杂一些,我担心这可能不是最好的实现。
你有什么建议吗?听听其他人对 iframe 的看法会很有帮助。
我正在构建一个小部件,并且一直在使用 iframe 在其中呈现内容。在某个时候,我可能会开始提供第三方 HTML 和 JS,所以我认为 iframe 会是一个好主意。
它确实使小部件 javascript 更复杂一些,我担心这可能不是最好的实现。
你有什么建议吗?听听其他人对 iframe 的看法会很有帮助。
不,iframe 没有任何问题。如果您要开始提供第三方内容,iframe 可能是一个更好的主意。
即将发布的 HTML5 规范还计划在 iframe 中为此类情况构建更多安全功能,因此我认为现在也使用它们是一种好习惯。
在 XMLHTTPRequest 被广泛使用之前,人们使用 JavaScript 和 iframe 的组合以动态方式提供内容,而无需刷新整个页面。
有很多关于以这种方式开发网站的信息,因此您应该有一个相对容易的时间来找到解决您可能遇到的许多障碍的解决方法。
我发现让我感到痛苦的一件事是在 iframe 中跨域使用 JavaScript。如果您在 iframe 中嵌入的页面来自与“父”页面不同的域,则浏览器具有不允许您从另一个访问其中一个的安全限制。诀窍是两个页面都声明
document.domain = 'somedomain.com';
网上有很多关于这种解决方法的资料。
祝你好运!
我最近发现的一件事是,嵌入在 iframe 中的 .aspx 页面有时会出现丢失 cookie 的问题,这会导致我参与的应用程序中的会话状态丢失。
对我来说,这是在一个不同的开发商店在他们自己的页面中使用我的一个 .aspx 页面的场景中。这意味着我们在不同的服务器上,这些服务器可能很突出,也可能不突出。
显然,这是由父页面拒绝子页面的 cookie 引起的……会话 cookie 也是如此,会话也是如此。
这个工作原理的具体机制有点涉及:更多细节
这个问题并没有影响到 FireFox,但它确实出现在 IE7 中,并且在几个小时内一直是个谜。
另外,我必须在一点上与上面链接的文章相矛盾。文章说,如果包含页面也是 .aspx,则您不会得到这个......在这种情况下,这不是真的,因为两个页面都是 .aspxs。
这对文章中关于这种情况的所有其他内容提出了一些疑问,但它确实导致了解决方案,所以这也是。
正如文章建议的那样,我输入了以下代码,该代码在页面的 Init 事件中注入了一个 p3p(隐私偏好项目 - 我从未听说过)标题:
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
...这就解决了问题。
我将不同意大多数人的观点,并说是的,iframe 是一个绝对糟糕的主意。任何在网页设计社区工作过一段时间的人都会同意 iframe 是纯粹的邪恶,除非绝对必要,否则应该避免使用。
我认为它们不好的原因是因为它们破坏了网页的导航模式。通过使用 iframe,您可以有效地破坏浏览器上的后退和前进按钮并迷惑用户。它打破了 HTTP 协议背后的整个想法;一个 URL 将始终指向一个唯一的位置。如果 iframe 是一匹马,它早就退役了。还有其他方法可以动态提供内容,应该使用这些方法。
如果您正在创建一个小部件,那么使用 iframe 的直接担忧就会消失(对搜索引擎不利,对书签不利等),但无论哪种方式,内容都会更好地动态提供,甚至在新窗口中而不是在 iframe 中提供。
我知道他们只有一件“非常糟糕”的事情。
如果您的第 3 方执行了一些 JavaScript,那么尝试修改他们的 DOM 有点太早了...... IE6 和 IE7 会抛出如此无用的“操作中止”错误,然后不仅会清空 iframe,还会清空整个周围的页面。(例如,您的网站出现故障)
它在 IE8 中没有修复,但崩溃处理得更好。
根据我的经验,iframe 要么是黑客,要么是节省时间的工具——确保如果你使用它们,出于这些原因,它们是必要的。如果您可以控制内容(或者可以通过镜像或抓取来获得控制),您应该考虑使用 AJAX 或服务器端包含将外部数据拉到页面上并将其推送到页面上 - 它最终会更加灵活,更多健壮,最终更易于管理。
就个人而言,如果你可以避免太多麻烦,我会避免它。使用 Javascript(或 AJAX,如果您需要动态加载它们),您可以很容易地使用 div 并根据需要更改内容 - 在某些情况下,这将为您提供更大的灵活性并简化您的 JS,特别是如果有很多您的小部件与页面其余部分之间的交互。
也就是说,我会调查这两个选项,如果 JS 路径看起来太棘手或复杂,只需使用 iframe。
取决于小部件的作用。iframe 有它们的位置,但它们确实很少引起布局问题(更不用说让你的 js 更复杂了),所以大多数人倾向于避免它们,除非绝对必要。
iframe 与框架一样,只是用于手头任务的控件。因此,它本身既不好也不坏,但根据手头的任务和客户的要求可能是好是坏。据我所知,所有现代浏览器(和非 Linux 用户)都可以毫无问题地“查看和使用”iframe。
iframe 并不邪恶,它们只是与其他任何工具一样的另一种工具,要确定它们的优点,您必须确定它们将被使用的上下文。Google 图片搜索和其他一些知名网站将 iframe 用于有限目的。
一般来说,我发现它们用于品牌推广或使用户能够返回将用户重定向到站点外的站点。
请注意,如果您使用跨域 iframe,例如指向页面所在域之外的域的 iframe,出于安全原因,您会受到设计的限制,并且无法通过 javascript 访问与其关联的域之外的 DOM 的内部结构。
另请注意,许多网站会阻止他们的网站被嵌入,并将 iframe 条带化(将顶部 url 重定向到他们的域)。
一个不错的选择是使用溢出 CSS 属性。默认值是可见的,但您可以将其设置为隐藏、滚动或自动。我会在你的情况下使用 auto 。如果你的内容变得太大,它看起来就像你有一个 iframe,但它仍然在页面上。
参见:溢出属性
从技术上讲,iFrame 与替代品相比没有什么错。但从语义上讲,有恶。
Web 基于 HTTP,该协议表示给定的 URL 将始终指向唯一的资源。
使用 iFrame,您只需为所有资源提供一个 URL 后面的网页中融合的多个资源。如果您担心 Web 应该如何发展,那就麻烦了。更重要的是,对于搜索引擎机器人来说,这很棘手。
iframe 有一个重要的问题,几乎没有人提到,但它让我感到厌烦。
我们的同事将毕生精力投入到一个动态变化的数据库中,我们已将其加载到 Google Docs 电子表格中,然后我们将其与大量支持材料一起显示在我们的网站上。
绝对没有什么可以阻止有人从我的页面源中抓取 iframe 代码并将其推到他们的页面上。现在,他们正在获取我们所有的数据,这些数据在几分钟前刚刚刷新,完全免费提供给他们的页面。
如果一个谷歌 iframe 可以绑定到一个特定的域,那将会停止它的轨道。
任何想法,明亮的火花?
不一定,只要 iframe 中的内容是可预测的。
iframe存在几个可用性和可访问性问题。某些浏览器和屏幕阅读器无法显示 iframe,因此您应该提供替代内容:
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
如果您开始提供第三方内容,则应注意 iframe 在完成加载后抓取焦点。虽然对于普通用户来说是一个小烦恼,但对于使用屏幕阅读器浏览的用户来说可能会非常混乱。
回复:“HTTP 协议背后的整个想法;一个 URL 将始终指向一个唯一的位置”
我从同一个 URL 为我的整个 CMS 提供安全性和可扩展性(主要使用 POST 而不是 GET 参数)。我不希望在没有身份验证的情况下看到安全内容,并且调度系统使我的开发更容易,因为我不必担心每个新页面的身份验证。
此外,对于某些应用程序,SEO 不适用(例如基于 Web 的 ERP)。
我使用 iFrame 从 PHP 生成的程序集树中提供内容。每当用户想要查看零件/装配的详细信息时,我不希望刷新树(和节点可见性)。