Re: Summary: FRAMES tag references

William C. Cheng writes:
 > A cleaner way is probably putting all these FRAMES stuff in the HEAD (or
 > style sheets) of the first URL as a hint to the browser.  To remain
 > compatible, a new tag (something like PANES) should be used.  Is this done
 > somewhere?

There have been other suggestions for Frame/Pane - like things.
Netscape's is the first implementation I've seen.  This is a valuable,
powerful feature, and I rather like how Netscape did it, but there are
limits that could have been avoided with a cleaner, more flexible
design.  Perhaps we can migrate to nirvana in the end.

What I would like to do with frames is have them work with browsers
that don't support them as well as those that do.  As it is, you
cannot do so without essentially sending the document twice for those
that do support frames, once in the NOFRAMES content and once via each
FRAME's SRC attribute.  

Instead of the FRAME tag taking only a SRC attribute to specify the
content of the frame, each FRAME should allow a content.  This content
would be displayed instead of (or in addition to) the SRC document.
This way, a document that is divided into frames would be displayed in
frames by a browser that understands them; otherwise the content of
the frames would be displayed in the order given for a browser that
does not understand frames.  Even more general, the SRC attribute of
the FRAME tag should not be used at all, and instead a new EMBED tag
should be used to embed any document in the context of wherever it is
used.

The problem with this scheme is that URLs in the content of a frame
that are for documents targetted for particular frames may need to be
handled differently depending on whether the browser supports frames.
If it does not support frames, what the user should see is the same
full document sent the first time *including all the frames* with the
new frame content substituting for the targetted frame.  This problem
can be avoided with an explicit SRC with a rigged URL since the server
can provide a version of the frame content that has the correct URLs.
But even without an explicit SRC, we can depend on a browser that
understands frames to tell the server what frame was clicked in (thus
it must understand frames) so the server can respond with the correct
content.

This is my main objection to the current frame design.  I'm sure other
people have other problems, and Netscape should be interested in them
all.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Friday, 12 January 1996 14:00:00 UTC