- From: W. Jeffrey Rankin <jrankin@jeffr.net>
- Date: Thu, 1 Feb 2001 15:43:42 -0500 (EST)
- To: Bertilo Wennergren <bertilow@chello.se>
- cc: www-html@w3.org
On Thu, 1 Feb 2001, Bertilo Wennergren wrote: > W. Jeffrey Rankin: > > > > For example, use JS to document.write a navigational header only IF the > > > doc is loaded in a top level window. Have the same header in a NOSCRIPT > > > tag for no-JS browsers. The JS header does not appear when the doc is > > > loaded into a frameset, but appears outside of it or woth JS off. > > > Or, dispense with javascript entirely and use any number of > > server-side tools to write out a navigational header based-upon the > > hierarchial structure of the document(s) or some other dataset. > > I'm no friend of frames, quite the opposite, but it is > illogical and a waste of resources to load the same stuff > again and again. If just a certain part of a page is to change, > it is reasonable to keep all other parts on the screen, instead of > throwing them out and then reload and redisplay them in exactly > the same way. It's been my experience that the navigational elements that are typically "framed" are minimal in terms of bytes, so I'll usually have elements like these in some sort of include file that in parsed into the HTML when the page is served. Usually the content part, whatever that is, is the most demanding in terms of bytes/resources etc. so it's not much of an additional load to put the navigation in every page. The problems inherent in frames, for the developer and the end-user, far outweigh any benefits they may offer. I've found this to be true for small static sites up to database-driven sites containing 20,000+ potential 'pages' of data. - Jeff
Received on Thursday, 1 February 2001 15:48:29 UTC