21

自 1998 年以来我就没有使用框架。它们似乎是个坏主意，在我的所有开发过程中，我从未遇到过框架是正确解决方案，甚至是体面的解决方案的情况。

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

一方面，当 VPN 连接到我的网络时，我经常收到“找不到 website.com/frames.html”错误消息。当我在内部网络上时，不会发生这种情况。

其次，该应用程序具有内置的电子邮件/消息系统。未读消息的数量在左侧菜单框中显示为“消息 (3)”，但当我阅读消息时计数不会更新。开发人员告诉我，因为它在一个框架中，所以我需要右键单击菜单并“刷新”。严重地？？？？

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

4

8 回答 8

15

尽管它们在创建时解决了一个问题（更新“页面”的一部分，同时保留非更新部分），但框架集几乎从一开始就在可用性方面受到批评，因为它们破坏了浏览器，例如：

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

如果您使用任何服务器端语言来生成 HTML，即使它提供的只是“服务器端包含”，避免框架集（包括每个页面上的相同内容）的最重负担是微不足道的。与框架集不同，服务器端包含可以出现在页面的任何位置；使用服务器端脚本语言或模板系统构建站点还有其他明显的优势。

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

于 2013-04-10T23:54:10.620 回答
10

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

11.2 不合格特征

以下列表中的元素已完全过时，作者不得使用：

[...]

框架

框架集

无框

要么改用 iframe 和 CSS，要么使用服务器端包含来生成完整的页面，其中合并了各种不变的部分。

于 2014-05-13T12:20:09.273 回答
8

#1的原因？用户讨厌他们。

即使它们在其他领域（代码分离、应用程序设计、速度等）提供了优势，它们也是用户界面的一部分。如果用户不同意，请不要使用它们。

于 2009-07-29T21:22:31.493 回答
7

例如，当您有一个静态网站时，框架有点用处，可以避免在所有页面中重复导航菜单。它还减小了页面的整体大小。

这两个论点现在都已经过时了：网站会毫不犹豫地提供胖页，而且它们中的大多数都是动态构建的，因此包括此类导航部分（或状态等）没有问题。

“为什么”部分在上面得到了很好的回答，部分是由你自己的问题（你遇到了一个限制，尽管它可以被一些 JS 覆盖）。

于 2009-07-29T21:20:21.780 回答
6

我不使用框架的第 1 个原因是因为它们破坏了浏览器的书签（又名收藏夹）功能。

借助当今存在的技术，框架已经过时了。但是如果您的遗留项目仍然使用它们，您可以使用一些 ajax 更新消息。

于 2009-07-29T21:16:13.897 回答
5

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

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

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

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

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

话虽如此，我喜欢 iFrame 的单页吸引力，当它们实际上可以像现在标准框架一样轻松地为我的网站做所有相同的事情时，我就会迁移。与此同时，这种关于它们“过时”的胡说八道与他们多年来强加给我们的其他所谓“升级”一样令人厌烦，但却没有经过深思熟虑。

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

于 2013-04-10T22:48:19.617 回答
2

他们几乎总是让人生气。你还需要什么？

于 2009-07-29T21:16:30.433 回答
2

框架在某些场合非常有用。如果您正在创建一个仅用于阅读的本地网页，不涉及交互并且该网站不会在互联网上公开，则所有不使用框架的理由都将被删除。例如，仅使用 html 开发的应用程序的用户手册，框架对于以简单且易于编码的方式将目录保留在左侧非常有用。此外，如果您在网站内有正确的导航，则后退按钮的歧义将完全消除

于 2014-09-06T09:15:27.877 回答