The framset element replaces the body element in pages as a means to include a different document model for web pages: they're bad for usability and accessibility, and what they intended to accomplish have been completely replaced by CSS and ubiquitous server-side development.
The iframe element, on the other hand, does not replace the body of a page. It acts as a means to include a new browsing context embedded within a block of content. It does not suffer from the same usability or accessibility problems as the frameset model and is used almost anywhere one needs to include an embedded browsing context (widgets being the most prolific example)
The iframe in HTML5 also takes on additional features in that it can be sandboxed, allowing the parent document to decide what gets executed within it. This allows for some measure of security for the parent document (and visitors to the parent document) when embedding untrusted content.
The object element somewhat overlaps with the <iframe> element, but it has a different content model (which is intended mainly for plugins), has its own set of caveats, and doesn't have the sandboxing attributes the iframe element has.
The frameset constructs a page out of multiple documents all with with the same priority: this causes challenges for screen readers that do not know which document to focus on at any specific time. <Iframe> elements, on the other hand, are simply embedded into a single page: it's no different than having an embedded image.
Challenges for screen readers: The blind people I have spoken to have all said that they prefer navigation to be stuck in a separate frame (not iFrame) because they can ignore it and only have it read to them when they want. The real culprit for screen readers is Javascript and AJAX which makes pages completely unusable with current screen readers (well, my info is about 10 months old). My personal experience with screen readers supports this
Frames (frameset) acts as document. It's removed because it breaks HTML documents structure and navigation. Eg. you have links in one frame, content in the other, you can't open link from the page in in a new window, you can't link to specific sub-page, etc.
On the other hand iframes won't break anything if used correctly because they're meant to sandbox content (eg. ads).
Framesets are often used in a way where they break the fundamental principle of the Web - that each document has a single URL. This leads to problems with linking, bookmarks, search engines etc.
The typical use of a frameset would be a frame at the top with a logo or header, a frame at the side with a menu, and a content frame. But search engines index individual pages, so when you find some page in Google, it would link directly to the content page without the frameset, so you lose the navigation. The problem with links and bookmarks is you would typically want to link or bookmark a particular content page inside the frameset, without losing the frameset itself. The is no easy way to do that.
The reason framesets became popular in the first place was because they allowed a statically positioned header and menu with a scrolling content area. But that can be achieved much easier with CSS today. Furthermore frames allowed you to use common elements like logos and menus on multiple pages without using any server-side coding. This was an advantage at a time where server-side coding was tedious and error prone (i.e. CGI scripts), and many hosts didn't allow server-side scripting at all. Today with Content Management Systems (CMS) and better server-side platforms, this is much better handled on the server side.
So basically there are no advantages to using a frameset, just lots of problems.
IFrames can be used the same way that framesets were used, and in that case they also lead to the same problems. But there are also many legitimate uses of iframes which do not lead to the same problems.
0
comments, (670 reads) All Articles by, GabbyGirl