Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
框架在某些场合确实很有用。 如果您要创建一个仅用于阅读的本地网页，不涉及交互性，并且该网站不会在互联网上公开，那么所有不使用框架的理由都将被消除。 例如，仅以 html 开发的应用程序的用户手册，框架对于以简单且易于编码的方式将目录保留在左侧非常有用。 此外，如果您在网站内有正确的导航，则后退按钮的歧义将被完全消除
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely
发布评论
评论（8）
尽管他们在创建时解决了一个问题（更新“页面”的一部分，同时保留非更新部分），但框架集从一开始就在可用性方面受到批评，因为它们破坏了框架集的通用功能浏览器，例如：
如果您使用任何服务器端语言来生成 HTML，即使它提供的只是“服务器端包含”，避免框架集（包括每个页面上的相同内容）的最大负担是微不足道的。 与框架集不同，服务器端包含可以出现在页面的任何位置； 使用服务器端脚本语言或模板系统构建网站还有其他明显的优势。
能够更新页面的小区域而无需重新加载整个内容仍然有一个优点，这可以通过 AJAX 来实现。 有时，这会导致人们创建具有上述框架集所有问题的接口，但这很难成为支持框架集的论据。 同样，使用精心设计的 AJAX 功能构建的网站可以实现框架集甚至无法解决的问题。
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
今天避免使用框架的一个很好的理由是它们在 HTML 5 中已被弃用：第 11 章已过时特点
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
第一个原因是什么？ 用户讨厌他们。
即使它们在其他领域（代码分离、应用程序设计、速度等）提供了优势，它们也是用户界面的一部分。 如果用户不认可，就不要使用它们。
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
例如，当您拥有静态网站时，框架有点有用，可以避免在所有页面中重复导航菜单。 它还减小了页面的整体大小。
这两个论点现在都已经过时了：网站会毫不犹豫地提供胖页面，并且大多数页面都是动态构建的，因此包含此类导航部分（或状态等）没有问题。
“为什么”部分在上面得到了很好的回答，部分是由你自己的问题（你遇到了一个限制，尽管它可以用一些 JS 来覆盖）。
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
我不使用框架的第一个原因是它们破坏了浏览器的书签（也称为收藏夹）功能。
随着当今技术的发展，框架已经过时了。 但如果您的遗留项目仍然使用它们，您可以使用一些 ajax 来更新消息。
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
仅仅因为手机 iPad 的热潮并不意味着功能强大的全功能网站突然“过时”，那些决定让框架集过时的人似乎是那些从一开始就从未充分发挥其潜力的抱怨者，或者也许他们是大型企业手机和平板电脑制造商的说客，他们懒得为他们小小的屏幕制作一个像样的支持框架的浏览器。
诚然，iFrame 可以很好地处理简单的工作，例如滚动和/或在单个页面内显示独立的片段，我在自己的基于框架的网站中使用它们，但为了让它们工作以及网站本身的基础是一场噩梦。 相信我，我知道，因为我的网站是互联网上最复杂的基于框架集的网站之一，而且我一直在研究将其全部转换为 iFrame 的利弊。 噩梦是轻描淡写的。
我已经能听到抱怨者说：“那你为什么一开始就这么建造呢？” ...答案是A：因为我不懒。 B：因为基于框架的网站对于具有数百页内容且无需依赖服务器的基于信息的网站而言是最实用、最具视觉吸引力且用户友好的格式。 我的意思是，除了外部广告之外的所有内容都可以直接从闪存驱动器上观看。 不需要 MySQL 或 PHP。
以下是我遇到的一些问题：
话虽这么说，我喜欢 iFrame 的单页吸引力，当它们实际上可以像现在的标准框架一样轻松地为我的网站执行所有相同的操作时，我就会迁移。 与此同时，这种关于它们“过时”的废话就像多年来他们未经深思熟虑就强加给我们的其他所谓“升级”一样令人厌烦。
那么，对于是否使用框架集的问题，这一切归结为什么呢？ 答案是，这完全取决于您希望网站做什么以及主要在哪个平台上查看。 在某些时候，如果没有一些框架或 iFrame 集成，让多页面网站正常工作就变得不切实际。 但是，如果您只是创建一个在手机或平板电脑上显示良好的基本个人资料页面，则不必担心框架集。
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
他们几乎总是让人生气。 您还需要什么？
They almost always make people angry. What more do you need?
框架在某些场合确实很有用。 如果您要创建一个仅用于阅读的本地网页，不涉及交互性，并且该网站不会在互联网上公开，那么所有不使用框架的理由都将被消除。 例如，仅以 html 开发的应用程序的用户手册，框架对于以简单且易于编码的方式将目录保留在左侧非常有用。 此外，如果您在网站内有正确的导航，则后退按钮的歧义将被完全消除
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely