Home > Articles > Don't Use Frames
Don't Use Frames
Written on Mar 11th, 2010 at 5:18pm
If you look up the HTML tutorial on this site, you will notice there are a number of common elements (such as <center>) which aren't listed. The reason for this is because they are deprecated, that is, while current browsers will support the elements, support for them will be removed in the future.
A number of these elements were deprecated because of style sheets, as these elements merely changed the style of the page content, and didn't offer any extra meaning to the content itself. However, there are some other tags - the frame tags - which became deprecated for an entirely different reason.
The frame tag was initially designed to make things easier for users (and developers) of large websites. A site would contain a separate frame for the header, footer, menu bar, and any other content that would get repeated over and over.
From the user's perspective, time would be saved as you wouldn't have to repeatedly download the same content (this is why we are encouraged to use external stylesheets and scripts). It may not seem alot now - but remember, back when the internet was getting really popular in the mid 90s, people were still on 14k modems - if you held 8kb of content in your repeating content (very easy to do with text, nevermind images), each page reload is slowed down by over half a second - if all of this content is placed in frames (which would only be loaded once), this isn't a problem.
From the developer's perspective, time is saved editing this repeating content. PHP and other server-side scripting languages weren't quite as popular yet, a website really did consist of strict HTML files (as opposed to a combination of HTML, CSS, various images and PHP or ASP files), and nothing more. Can you imagine editing the footer on over 100 pages? It would be a complete nightmare. Frames solved this problem by letting developer's change a repeating section once and no more.
Okay, so that's why frames are useful. Now it's time to talk about why we shouldn't use them. Imagine you are developing a site which contains 4 frames - a header, footer, main content, and sidebar header (used for ads, navigation, etc.)
First off, search engines index EVERYTHING. When google (or any other search engine) learns about your site, it will go to its main page, and see there are 4 frames. The actual HTML of your site will be rather short - mention the 4 frames, the source of each of those frames, and no more. Google is curious, so it goes on to index each of those 4 frames. Someone could then type in the name of your site on google, and instead of being directed to your homepage, they'd be directed to the single header frame for your site.
Secondly, a site with frames does not use any URLs other than the main one. Check out the API for the Java programming language. Click on the various links - you'll notice the URL in the address bar never changes. This makes things a royal pain when it comes to bookmarking for the user. In the case of the Java API, I can't simply bookmark the section on the String class - I have to load up the entire API and find the String class through the menu. It's like saving a book but not having a tab for the chapter you're interested in. This is actually one of the reasons why I am opposed to sites run entirely by Flash.
Next, when you use frames you are limiting the effectiveness of your ads. Unless you are dealing with an advertiser directly (as opposed to using an ad-placement service such as google adsense), the ad to be placed is determined by a script looking at the content around it. If placed in a frame, an ad will be determined solely by the other content in that frame, not the website as a whole. And if the frame doesn't have any content other than the ads? Have fun trying to figure out which ads will be placed (and good luck getting visitors to click on these ads).
Finally, there's the download speed issue. When frames were first made popular, we were downloading pages at an incredibly slow rate. This is no longer the case. While this is not an excuse to use incredibly inefficient code (see the article on using tables), we can afford to force the user into re-downloading 8kB or so in header and footer data without ruining their experience.
Comment on this page:
Comments
No one has commented on this article yet. You can be the first!