我为什么不使用HTML框架?

rva*_*her 21 html frames frameset frame

自1998年以来我没有使用过框架.它们看起来是个坏主意,在我的所有开发中,我从未遇到过框架是正确的解决方案,甚至是一个不错的解决方案.

但是,我现在正在使用由另一个组编写的内部Web应用程序,整个站点都是在 - 标题,左侧菜单,右侧内容 - 框架集中构建的.

首先,当VPN到我的网络时,我不断找到"website.com/frames.html"找不到."错误信息.当我在内部网络上时,这不会发生.

其次,该应用程序具有内置的电子邮件/消息系统.未读消息的数量在左侧菜单框中显示为"消息(3)",但在读取消息时计数不会更新.开发人员告诉我,因为它在一个框架中我需要右键单击菜单并"刷新".认真????

所以,我的编程相关问题是,你有什么理由不在网站中使用框架?

IMS*_*SoP 15

虽然他们在创建时解决了一个问题(更新了"页面"的一部分,同时保留了非更新部分),但框架集在可用性方面却从一开始就被批评,因为它们打破了通用功能.浏览器,例如:

  • 书签,复制和粘贴要共享的URL
  • 打印屏幕上显示的页面
  • 重新加载页面:由于URL一般没有更改,您将经常被带回网站的主页或默认框架集; 手动重新加载一些帧是可能的,但对用户来说并不明显
  • 后退和前进按钮是不明确的:撤消/重做最后一帧更改,或带您到最后一次更改URL栏?

如果您使用任何服务器端语言生成HTML,即使它提供的所有内容都是"服务器端包含",那么避免使用框架集(包括每页上相同内容)的最沉重负担也是微不足道的.与框架集不同,服务器端包含可能出现在页面的任何位置; 使用服务器端脚本语言或模板系统构建站点也有其他明显的优势.

能够在不重新加载整个内容的情况下更新页面的小区域仍然是有利的,这可以通过AJAX实现.这有时会导致人们创建与上面概述的框架集的所有问题的接口,但这不是支持框架集的论据.同样,使用精心设计的AJAX功能构建的站点可以实现框架集甚至无法解决的问题.


Sim*_*ier 10

今天避免使用框架的一个很好的理由是它们已经在HTML 5中被弃用:第11章过时的功能

11.2不符合要求的特征

以下列表中的元素完全过时,作者不得使用:

[...]

框架

无框架

要么使用iframe和CSS,要么使用服务器端包含来生成包含各种不变部分的完整页面.


Spe*_*ort 8

#1的原因?用户讨厌他们.

即使它们在其他领域(代码分离,应用程序设计,速度等)提供了优势,它们也是用户界面的一部分.如果用户不批准,请不要使用它们.


Phi*_*Lho 7

例如,当您拥有静态网站时,框架非常有用,以避免在所有页面中重复导航菜单.它还减少了页面的整体大小.

这两个论点现在已经过时了:网站毫不犹豫地为胖页面提供服务,而且大多数都是动态构建的,所以包括这些导航部分(或状态等)都没有问题.

"为什么"部分在上面得到了很好的回答,部分是由你自己的问题(你遇到了一个限制,虽然它可以被一些JS覆盖).


Pet*_*cco 6

我不使用框架的第一个原因是因为它们破坏了浏览器的书签(也就是最喜欢的)功能.

凭借当今存在的技术,框架已经过时.但是,如果您的旧项目仍然使用它们,您可以使用某些ajax更新消息.

  • 有趣的是,这是一个新的应用程序.我不知道他们在想什么. (4认同)

Ico*_*rix 5

仅仅因为手机 iPad 的热潮并不意味着功能强大的全功能网站突然“过时”,而那些决定让框架集过时的人似乎也是那些从一开始就没有充分发挥潜力的抱怨者,或者他们可能是大型手机和平板电脑制造商的说客,他们懒得为自己的小屏幕制作一个像样的框架浏览器。

诚然,iFrames 可以很好地处理简单的工作,比如在单个页面内滚动和/或显示独立的段,我在我自己的基于框架的网站中使用它们,但为了让它们工作以及网站本身的基础是一场噩梦。相信我,我知道,因为我的网站是 Internet 上最复杂的基于框架集的网站之一,我一直在研究将其全部转换为 iFrame 的利弊。梦魇是轻描淡写。

我已经可以听到抱怨者说:“那你当初为什么要这样建造呢?” ...答案是A:因为我不懒惰。和 B:因为基于框架的网站是功能最强大、视觉上最吸引人且用户友好的格式,适用于具有数百页内容且不必依赖服务器的信息网站。我的意思是除了外部广告之外的所有内容都可以直接从闪存驱动器上查看。不需要 MySQL 或 PHP。

以下是我遇到的一些问题:

  • 使用 JavaScript 可以轻松处理对孤立页面的反对。
  • 除非您不使用任何框架,否则关于书签的反对意见是无关紧要的。
  • 可以使用“添加书签”JavaScript 函数处理特定于内容的书签
  • XML 站点地图和 JavaScript 可以轻松处理有关 SEO 的反对意见。
  • 使用标准框架集布置动态大小的框架要容易得多,也更可靠。
  • 使用标准框架集可以更轻松地从外部框架定位和替换嵌套框架集。
  • 内部脚本(如 JavaScript 搜索和非服务器依赖的购物车对于 cookie 来说过于复杂)似乎无法使用 iFrame,或者即使是这样,让它们工作也比使用标准框架要麻烦得多。

话虽如此,我喜欢 iFrame 的单页吸引力,当它们实际上可以像现在的标准框架一样轻松地为我的网站执行所有相同的操作时,我就会迁移。与此同时,这种关于它们“过时”的废话与它们多年来强加给我们的其他所谓的“升级”一样令人厌烦,而没有完全考虑清楚。

那么这一切归结为是否使用框架集的问题?答案是,这完全取决于您希望您的网站做什么以及主要在哪个平台上查看。在某些时候,在没有一些框架或 iFrame 集成的情况下使多页面站点运行良好变得不切实际。但是,如果您只是创建一个在手机或平板电脑上显示良好的基本个人资料页面,请不要理会框架集。

  • 埋藏在该咆哮中的一个体面的一点是,对于离线网站,框架集为服务器端处理提供了一种简单的替代方案。但是,对于任何基于 Internet 的网站,您不断提及 iframe 表明您已经完全误解了框架集为何过时的原因,这有利于 a) 服务器端包含公共内容和 b) 内的 AJAX 驱动的动态内容单页。 (3认同)
  • 好吧,我从没听过那句话,但它可以解释你的误解。如果有的话,iframe 与框架集具有所有相同的*问题*,并且肯定不是灵丹妙药。您帖子中的另一个重大误解是,这与移动浏览器有关;多年来,框架集一直被认为是一个坏主意,从 HTML5 标准中删除它们实际上只是一种整理行为。 (3认同)