可能重复:
iframe被认为是"不良做法"吗？
在与Web开发人员合作时,我总是从他们那里听到使用iframe是我们必须尽可能避免的事情,并且有些人说这是坏事,烦人并且会产生很多问题.
另外,当我告诉我以前的老板"不是开发人员"有一天我会使用iframe时,他看着我作为一个糟糕的开发者:)
我想知道的是,iframe在网络开发方面的历史非常糟糕吗？
这是一场灾难吗？
在某些情况下,我发现使用iframe是必须的,这说明我是一个糟糕的开发者？
或者所有这些都是因为在开发过程中我们必须注意一些安全问题而难以处理？
如果你讨厌它,请列出你的分数,如果我的思路方式错误,请纠正我.
什么是可用性,可访问性,屏幕阅读器或任何其他开发,功能或跨浏览器问题<iframe>？
还有其他选择<iframe>吗？
是否有任何JavaScript/jQuery或服务器端技术可以降低可用性,可访问性或屏幕阅读器问题<iframe>？
为什么W3C不包含<iframe>在XHTML Strict中,而HTML 5支持<iframe>？
更新:
我在这里也发现了一些好的想法: http ://uxexchange.com/questions/1817/iframe-accessibility-and-usability-issues
我一直在研究内部网Web解决方案,这些解决方案将由系统的一组特定用户使用 - 例如供应链管理.没有搜索引擎优化或营销 - 只有易于使用和简单,吸引他们,使他们的任务简单.
我在ASP.Net上使用MVC2.我将用通用术语解释我的场景.我有一个页面,其中有一个标签视图.第一个选项卡从主表加载记录,其他选项卡加载某些详细信息表的数据.理想的例子是:
- 选项卡1:添加/编辑客户(主)记录
- 标签2:为客户添加/编辑订单
- 选项卡3:为订单添加/编辑项目(取决于选项卡2)
- 选项卡4:为该客户添加/编辑不同的地址
我正在使用jQuery ui tab.现在根据我对iframe的了解 - 如果我设计这个页面(View)将第一个标签及其内容包含在一个页面(View)中,其余的标签都有iframe,我在其中使用单独的页面(Views).简而言之 - 所有依赖选项卡都有各自的页面.
我看到的好处 -
- 该页面变为v.light并且快速,因为当用户正在使用选项卡1时,其他选项卡将加载其iframe.
- 从功能上讲,每个选项卡必须有自己的添加/编辑和列表独立.例如,如果我正在添加地址,那么只会刷新我的地址iframe,其余的标签/页面不需要回发并重新加载数据.
- 如果所有内容都在一个页面中(View),则具有通用保存/取消功能将需要对象层次结构的v.complex内存中缓存.我可以使用用户控件(即.ascx),但仍然可以在一个动作中处理所有内容,就像巨大而复杂.
- 我不用担心SEO或书签或动态尺寸.相反,我正在获得SOC(关注点分离),所有内容都正在分发v.well,主要的是它变得非常快,因为回发是分开的.
..所有这一切,如果我使用iframe :)但是,我没有看到很多人喜欢iframes: iframes是一个糟糕的主意吗？
如果是这样 - 是否有一个等效的jQuery替代品？我希望它具有iframe的优点,并且至少可以通过url和单独的回发来动态加载内容.我不想创建一个凌乱的AJAX blob,它可以处理事情,但使后端同样复杂.
请让我知道你的想法 - 我不想知道iframe有多好/坏,我只是想知道什么符合我的要求,以及iframes有更好的替代方案..对于我的场景.
编辑#1:我得到了支持浏览器的iframe列表 -
http://www.webmaster-resources101.com/articles/view/417/
编辑#2:我得到的东西可能是一个更好的选择,而不是iframe的垫脚石 -
它是两个jQuery插件的组合,是着名的jQuery选项卡插件,另一个是adhoc插件,可以控制容器的回发.
jQuery ui tab:http: //jqueryui.com/demos/tabs/
jquery-hijack:http: //code.google.com/p/jquery-hijack/
这可以吗？还有其他更好的选择吗？