Frames (was Re: Body start tag.)

At 2:31p +0300 07/20/97, Stephanos Piperoglou wrote:
 > On Wed, 16 Jul 1997, Paul Prescod wrote:
 >
 > > That was my idea when I first saw frames. They are really a very
 > > different "document type" than your typical HTML document. This is why
 > > we are running into these implied start tag problems. Any "real" HTML
 > > document has a single required BODY, so it is convenient to leave off
 > > the tags. I have no precise definition for what is a "real" document but
 > > any document class that requires radical changes to the HTML DTD and
 > > where instances of the class use a radically different mix of elements
 > > and attributes should probably be a "different" document type with its
 > > own different, but related DTD. We might find that letting the two
 > > evolve separately will allow some innovations in FRAMES that would have
 > > been difficult as part of HTML.
 >
 > Oh yes indeed! This is a beautiful suggestion, but it might need some
 > thought:

Yes, I also found this a very intriguing thought! But there must still be
specified what <BODY> stuff can exist in a framedoc for use by non-frame
browsers...

 > Personally, all I'd need is an implementation akin to HTML 3.0's BANNER
 > element.

Other people sometimes need more than that.

 > The only thing frames are useful for is providing navigational
 > tools and company logos.

Not true. Granted those are the first things we all think of, and those
would indeed be ideal candidates for BANNER, but BANNER would not help for
applications such as web-based chat: you do not want to re-download items
which have not changed, as that would be a waste of time and bandwidth.
BANNER is best for only very static pages, and for images which can be
cached by the browser; not all applications lend themselves to that. As
things currently are, browsers cache images, sounds, and entire pages;
they do not cache partial pages. HTML is not byte-served like some PDFs
can be. You wanna design a new system, where instead of HTML pages we
have object databases, and servers can pull object records out of each
database file, and UAs can _cache_ any and all of those objects?
Hmm... maybe I'm on to something here...

 > I think multiple documents on screen is something for the user to do
 > with multiple browser windows, NOT for the author to decide.

It depends how interdependent the documents are. If the content of one
depends upon the content of another, then a frameset is the only answer
(out of what we've seen so far... who knows what tomorrow holds...).

 > Making an HTML document that does not make sense if it's not shown
 > together with other documents is bad practise and doesn't make sense.

Then I suggest that HTML is insufficient.

 > HTML
 > documents should be complete. One of the most important drawbacks of the
 > FRAMESET implementation is that it is impossible to reference a specific
 > state of the frameset using a resource + fragment identifier URL; only the
 > initial state can be referenced, making the implementation unsuitable for
 > large documents.

We could probably spend a lot of time defining what a "large document" is,
and then spend even more time debating whether such should be avoided. The
style guide at www.w3.org recommended that documents be 1/2 to 5 pages in
length (that probably means 1K-10K); personally, I dislike 100K documents...

 > Specific advantages:
 >
 > - You don'y have to worry about targets; all of what you see on screen is
 > ONE document.

That is not appropriate for all applications.

 > - You can't get the "mixed-up frames from hell" phenomenon simply because
 > the author forgot a TARGET attribute.

There will always be author-induced problems of one sort or another. 98%
of everything is crap (who coined that?), and web pages are no exception.

 > - Frames are a clearly presenatational issue; you can seperate them from
 > your HTML

In talk about structure vs. presentation, people forget other factors, such
as usability and efficiency. And why are we hamstrung by VT100 anyway? I've
seen better technology in character mode (look at FoxPro for DOS and Xenix),
so why aren't we seeing any improvements there?

__________________________________________________________________________
  Walter Ian Kaye <boo_at_best*com>    Programmer - Excel, AppleScript,
          Mountain View, CA                         ProTERM, FoxPro, HTML
 http://www.natural-innovations.com/     Musician - Guitarist, Songwriter

Received on Sunday, 20 July 1997 16:53:29 UTC