UncleMortis,
Restoring some rationality to the frames debate: (in my dreams)
First of all what is a frameset? Let us look at an example:
NAME THIS frame1.htm
<html><head><title>Frame 1</title>
<style>body {color:black; background:blue}</style>
</head><body><div align="center">Frame 1</div></body></html>
NAME THIS frame2.htm
<html><head><title>Frame 2</title>
<style>body {color:black; background:yellow}</style>
</head><body><div align="center">Frame 2</div></body></html>
NAME THIS frame0.htm
<html><head><title>Frame 0</title>
<style>body {color:black; background:green}</style>
</head><body><div align="center">MENU<br /><br />
<br /><a target="TEXT" href="frame1.htm">Frame 1</a>
<br /><a target="TEXT" href="frame2.htm">Frame 2</a>
</div></body></html>
NAME THIS frameset.htm
<html><head><title>Frameset</title></head>
<frameset cols="30%,*" frameborder=0 border=0>
<frame src="frame0.htm" name="MENU" >
<frame src="frame1.htm" name="TEXT" >
</frameset></html>
frame1.htm, frame2.htm and frame0.htm DO NOT even know they are frames and can work quite happily without being part of a frameset. For example: Click on frame0.htm and it will give you access to frame1,htm or frame2.htm.
So without even using a frameset you could provide a situation where your main page is always active even if the user closes subsequent screens, and where your navigation system is very maintainable.
One question to ask yourself when deciding whether or not to use a frameset is: "For my particular application, would it be helpful to show one or more of my screens, at the same time, within the same browser window (frameset)?"
Ease of navigation is one of the reasons, but not the only reason, why you might choose to use a frameset. As has been pointed out, the same maintenance benefits could be derived using server-side includes. However, server-side includes require the HTML to be resident on a server. Perhaps you may want your HTML to be used locally and then server-side includes would not be appropriate.
Another reason to use frames is that they can be very fast. This is especially helpful for users with slow connections and older machines. Suppose the menu frame has a picture in it, the picture or the frame itself never needs reloading. Even loading from cache takes time and is futile and klutzy from a data-processing elegance standpoint.
The most compelling reason to use frames however, is when your application requires programming techniques such as; communication between screens; reuse of screens (keeping most of the code but changing certain variables); maintaining state; etc. etc.. Query Strings can be passed between screens and be invisible to the user because the address display never changes.
It is my opinion that the arguments against ever using frames fall into 4 categories.
1. Simple prejudice
example: Frames are crap, awful, useless etc.
2. Misinformation:
example: Frames confuse search engines
3. Specious
example: Some browsers do not recognise framesets
4. Valid
example: A casual user might not know how to bookmark a particular page that is part of a frameset.
In my opinion framesets should be thought of as a valuable tool which may or may not be useful depending on the particular application.
Clive
![[soapbox]](/data/assets/smilies/soapbox.gif "[soapbox] [soapbox]")
)