Re: HTML Frames (enhancement request and SGML declarations)

> But surely the whole point of frames is the ability to display and present
> separate documents within an single browser window.

Nope.  The point of frames is to display and present separate
*content* within an single browser window.

> Even by your own definition you imply the need for separate documents by
> suggesting that one of the frames contain navigation links which one would
> assume you intend to load into the message data area.

I do not imply separate documents.  I imply separate content, which
may come from separate documents or within the same document.
Frames describe a relationship among content.  This does not have
to imply separate documents are required.


> With the proper use of /NOFRAMES there is no browser that does not perform 
> properly in a FRAMES based environment. 

The noframes element is only for the use of frame-aware browsers.
Remember, non-frame aware browsers just ignore the frame markup since
they do not recognize it; noframes has no meaning.


> In addition, this concept of a single document somehow becoming magically
> useful to non frame users simply because all the text is on the same page
> is based on the same flawed thinking that sees tables often degrade to an
> unreadable mess on browsers that dont understand the concept of tables.

But that's how frame markup works.  Noframes element only clues
to frame-aware browsers what to ignore.  The benefit of having
content of frame defined within the frame definition goes beyond
backwards capitability (but it is a nice side-effect for maintainers
of web documents).  Embedded content provides me more flexibility on
how I choose to represent my data, without inhibiting the use
of referencing external documents as frame content.  I propose
a choice.  You do not have to use that choice.

> >   Many documents that utilize frames would benefit if frame content could
> >   be defined in the frame definition document. So if anyone from Netscape,
> >   or other client suppliers, is listening, please consider adding the
> >   functionality into your products.
> 
> There is another problem left begging with the concept of embedding document
> source within the frame definition itself.  This relates to the difficulties
> of page or frame refreshing.  If the base document contains all the
> text for a block of frames, but the navigator has since called a link that
> loads new text into a given frame, what should be displayed by the browser
> if it needs to refresh the page.

That is an application issue, and is beyond the scope of the markup.
But to address the issue, the embedded frame content has no
effect.  Netscape automatically tracks the last loaded content
into a frame.  Hence when I reload, it does not reload the original
document defined by the SRC attribute, but the last document loaded
into the frame(s).  The same principle can apply to embedded
information.  If the frame has been loaded with new content since
the initial creation of the frame, a "reload" will reload the
the last loaded content.  If you will notice, this is an issue
of applicational behavior.  There is nothing prohibiting a browser
to reload original source documents when a "reload" is requested.

	--ewh

----
    Earl Hood                  |   ISOGEN INTERNATIONAL CORP
    ehood@isogen.com           |   dba Highland Consulting
    Phone: 214-953-0004 x127   |   2200 North Lamar #230
    FAX: 214-953-3152          |   Dallas, TX  75202

Received on Friday, 30 August 1996 15:06:46 UTC