Frames: Good or Bad?
Ever since frames were introduced into HTML, web designers have been wondering whether their benefits outweigh their problems. Do the benefits of having a static navigation bar really justify the usability and accessibility problems they create? Does going against the philosophy of the web really matter? Does anyone actually like frames? Hmm...
This page was last updated on 2012-08-21
Issues with the concept
You just know I’m not going to be fighting both sides of the argument when my first paragraph is about the whole idea being a bad one. Frames disrupt the entire fundamental concept for the web: a large collection of individual pages, linked together with hypertext. Each page would have an individual address (the URL), and could be used as a stand-alone entity, with navigation integrated into it. This simplicity of concept and implementation was what made the early web both easy to use and incredibly popular.
Frames mess with all these established rules by giving readers views of pages from a different navigational viewpoint. Instead of being on the main “content” page, they are actually in a frameset. If they try to bookmark the page, their bookmark will open the frameset with its original pages loaded, not the one you had loaded inside when you created the bookmark. Furthermore, the URL that appears in the address bar does not correspond with the content page, but again to the frameset. This makes sending the address of a useful page to friends or creating a link to the page from your site useless. Think of the readers lost by these problems!
Search Engine Problems
It used to be the case that search engine robots that visited your page would not be able to read the pages that make up the frameset, and would be forced to read only the <noframes> “content”. This would mean that only one page of your site would be in the search engine’s index. Thankfully this isn’t a problem anymore, and almost all search engines are able to index all pages that make up a framed page.
Browser Problems
Luckily, the browser situation is now in a state where implementation of frames is not really a problem. For years there were a considerable amount of browsers in use that could not access framed pages, and were restricted to viewing whatever the author had placed in the <noframes> section of their code. That’s not a problem anymore due to the fact that the browsers that didn’t support frames (the version 2s) basically aren’t available anymore.
However, the modern web is accessed with many other devices besides a computer with a web browser. Think smartphones, PDAs and iPhones. These viewers usually have low-resolution screens, which make frames barely usable. Unlike tables, which will do their best to resize according to the user’s setup, frames are much less helpful and their usage will often result in the dreaded horizontal scrollbar.
Printing Problems
Browsers have had a long-standing problem with printing framed pages. Often you would get only one of the component pages printed off, or have everything scrunched together in a mess. The most recent browsers have given you options on whether you want the full frameset printed or an individual page, but that doesn’t escape the fact that printing framed pages is unnecessarily tricky and problematic.
Viewing the source code of a page is also made redundant since the frameset code appears where many inexperienced users would expect a large amount of useful code. You can click inside a frame and extract the code from it, but the fact remains, it goes against user’s expectations.
Coding Problems
Frames are a huge lure for beginner coders, for some odd reason. I remember I made my first site using frames, and used them for months before I realised there were better ways.
The benefits of frames, such as only having to update one navigation frame to modify your whole site, seem to be great. Of course, when you’re starting out, you rarely give a thought for your site’s accessibility. This leads coders to make many errors, such as using the scrolling="no" attribute to evade scrolling of their navigation frame, and other such usability disasters. Even more prominent a problem of course, is that frameset pages are simply hard to write if you’re a novice coder. They work in different ways to the rules you had learned before, and when you’re checking your pages, all manner of problems could pop up. Our frames tutorial is undeniably great, but even that’s not enough.
What of Inline Frames?
Inline, or I-Frames seem to be a better implementation of the ’opening multiple pages in one parent page’ idea. Thus far, they do not present any major usability problems, although until the browsers have fully integrated HTML 4 we won’t know the full scope of their benefits and difficulties.
So, in conclusion, framed pages do not behave the same as normal HTML pages, and as such lead to confusion and awkwardness. A well-designed navigation structure using tables or layers is infinitely preferable.
Too many people use frames as a way to change their navigation bars by only modifying one page. This is much better accomplished through includes.
A well-designed framed page can still be produced, but it happens so rarely that I would advise all coders to stay away from the thought. Tests have also shown that users do not like framed navigation. It might seem sexy to the coder, but if the users don’t like it then you’re doing a bad job.
Frames confuse and irritate people. Avoid them.
