W3C home > Mailing lists > Public > www-html@w3.org > February 2001

Re: FRAMEBORDER attribute?

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
Message-ID: <Pine.GSO.4.21.0102011523210.9713-100000@ultra>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:56 UTC