% strTitle = "Some Caveats with Using Frames" strMetaDescription = "While frames are not evil by default, there are many issues that must be considered before they are implemented on a site." strMetaKeywords = "" %> <% SUB Content %>
This article was originally posted on evolt.org, an online resource for web developers, maintained by web developers. I have granted evolt.org the right to use this article on their web site, and they are the only entity with the right to reproduce it.
July 27, 1999
While frames are not evil by default, there are many issues that must be considered before they are implemented on a site. Many sites on the internet appear to be unfamiliar with these issues, and use frames haphazardly, contributing to the overall inaccessibility of information online.
In current browsers, if a user bookmarks a page, the browser actually only bookmarks the parent frameset. When that user later calls up that bookmark, he/she will get the home page or equivalent. Until browsers can actually bookmark frame-state (bookmarks the page exactly as you see it, by bookmarking all the pages in all the frames), one of the most reliable methods of making a user come back to your site now works against your site. If that user had spent hours wandering through your site trying to find a specific page, that user will become very upset very quickly when he/she realizes that he/she has to retrace his/her path through the site when that user calls up the bookmark.
It should be noted that some browsers, like Navigator 3.0 on the Macintosh will bookmark the selected frame. What this means is that users can accidentally bookmark a navigation frame, since that might be where they last clicked, or they may bookmark a blank frame, or any other frame in your layout. If they bookmark a content frame, then you run in to the problems I cite below about users who come to a specific page from a search engine, as well as the interface design issues.
Linking to other sites within a frameset can pose some legal problems, even if you accidentally left out the target="_new" in the <href> tag. If your site is branding another site as its own, simply by placing it within one of your frames, that site may order you to stop. Precedents include brand dilution and lost revenue among their arguments. Some related articles:
Links to internal pages can be problematic if you do not specify a target frame in every link. There are too many sites on the internet where a click to 'Home' in the navigation frame reloads that same frame in a sub-frame, causing users to see double navigation frames and less real-estate for content. This is a glaringly obvious error to all users, and will definitely not earn points with them.
Some of you may remember problems with frame-spoofing (a web site inserting content into a frame that appears to be from another site), before the major browser vendors released patches. If you aren't absolutely sure your users have these patches, then you may be opening them and your site up to this issue. In brief, if I link to an e-commerce site from my page, say Amazon.com from some book links, it would be possible for me to insert my own content into a frameset that is branded as Amazon's, allowing me to post pages that request your credit card information and post directly back to my server instead of Amazon's.
Independent of this, if you plan to use secure keys (you had darn well better) for your e-commerce applications, then you should know that neither Navigator nor Internet Explorer will display a secure icon in their browser if one of the frames is not secure, nor should they. This means that you now have to reload a new document for each frame with an https (a secured version of the Hypertext Transfer Protocol that utilizes encrypted keys) connection.
In addition to the problems that can occur when linking within a site, keeping track of frame names and targets can be problematic should you ever change anything on your site. The more frames you have, the more complex the site becomes. If your site is designed to update all frames with every page, then you are now looking at an exponentially larger number of pages that need to be tracked then on a non-framed site, all with links that must be verified.
How many of you name your main frame '
main'? I have actually stumbled across sites that incorrectly load another site into a frame named '
main', while the new site also tries to load content into a frame called '
main.' Not a real issue, but a curious one at the very least.
Many search engine spiders can only index the parent frameset. As a result, your page may get poor ranking in search engines. If your
<noframes> tags contain meaningless text, or nothing at all, then most search engines stop there. For a more detailed overview of how to cope with frames with search engines, Search Engine Watch has a good section on what to expect.
Frames promote poor interface design. If you have all your navigation in its own frame, how do you account for users who come from other places? Keep in mind the example above, search engines can bring a user right into the guts of your site. It is easy to forget that people can make their way in to the HTML page of a frame, and when they do, how do you plan to allow them to get to your home page? Or how do you indicate to the user that it is your site? These are all questions that should be answered before the design is even begun since supporting them requires some trade-offs in the overall site layout.
As you might expect, Jakob Nielson has an article on frames, but it is from back in late 1996 when Navigator 2 was still in most site's logs, and Navigator still had the issue with the 'back' button taking a user completely out of a frameset. Either way, many of his points still stand today, 2 or 3 browser versions later. Some of these points include issues with the lack of value in the URL in the address/location bar as an indication of the user's location within a site, or the problems with trying to print a framed page. The Web Design Group has a similar but more focused article.
There are still browsers out there that do not use frames, browsers that are brand new and make a conscious decision to not offer that traditional support. Some of these are browsers for the blind, or other handicapped users. If your audience possibly includes any of these users, be prepared for them to have serious trouble traversing the site. As an example of how problematic this may be, if you are a user of Microsoft FrontPage 3.0, then you can see that the
<noframes> tag by default has the text, "This page uses frames, but your browser doesn't support them." This is not exactly polite, or user-friendly. It doesn't even offer a link to a main frame page, nor does it automatically include the contents of that main frame within the
The U.S. government has signed a law requiring all government web sites (as well as vendors of the government) to be completely accessible to all users by Aug. 7, 2000, including the blind. While this may seem unrelated, frames are now a prime target for such regulation. Currently, only U.S. government sites are affected, but there is reason to believe that the law may also apply to not-for-profits who receive government funding. Since there have been no cases involving this law, there is no precedent as of yet, but I am also not qualified to give legal advice so you should check on your own:
This is a little off the frames path, but to further understand how browsers intended for blind audiences work, see The Royal National Institute for the Blind's article Hints For Designing Accessible Websites.
Support in the current frames-capable browsers is generally good, but there are still extra issues you have to become familiar with, especially if precise frame alignment is important. Netscape Navigator and Microsoft Internet Explorer do not handle frames exactly like one another. If you have ever tried to line images up across frames, you have encountered one of these differences, namely that Navigator sometimes chokes on such precise alignment. That doesn't even take into account other browsers, versions, platforms, and their caveats. You can beat these issues, you just have to do that much more testing.
Your content is immediately restricted to a pixel size in at least one frame should you decide to force one frame to be a consistent size at any resolution. If you use percentages for all the frames, then the frames spread out on higher resolution monitors, or shrink to the point where nothing is visible if you haven't accounted for low-res users or those who don't surf full-screen (don't forget those browser toolbars and how much space they take up). If you are concerned about what resolution you should target, consider reading my article 640 x 480 Isn't Dead Yet.
Most of the advantages of a frame (updating one navigation bar, for instance, for the entire site) can be accomplished through even the most basic server-side include. If you have this kind of access on your server, then it is something you should seriously consider as an alternative.
Consider a strong search and replace function to allow you to quickly share HTML between many documents. Some applications even allow you to have 'virtual' include files that are added into your HTML when you are ready to move it to the server. At the very least, re-use your images across as many pages as possible instead of downloading new ones since they are already in the browser's cache at that point.
Read the Web Design Group's Frames FAQ and the Guide to frames usage to help ensure you are accounting for the caveats above by knowing how to code for them. If you want to go above and beyond that, consider reading the Web Content Accessibility Guidelines 1.0 from the W3C. It offers help on ensuring that your framed pages are still accessible to as many users as possible.
Absolute positioning with CSS is a great standards-based solution if you want to ditch frames altogether. However, be aware of your audience. Frames are currently more widely supported than CSS, and you may decide that you will not reach enough of your audience using CSS.<% END SUB %>