W3C home > Mailing lists > Public > www-talk@w3.org > September to October 1996

Extended URL for frames

From: David Perrell <davidp@earthlink.net>
Date: Thu, 12 Sep 1996 17:18:54 -0700
Message-Id: <199609130020.RAA19949@spain.it.earthlink.net>
To: <www-talk@w3.org>
This is a proposal to extend the URL fragment specifier to reproduce
the state of frames for bookmarking or reference purposes. The benefits
of this extension are that it is compact, can be used for both
bookmarking and link references, requires no special HTML tags or tag
behavior, and makes no assumptions as to how a frame was initially
filled. Also, the extended URL is compatible with existing browsers.

FRAME STATE

In current UAs supporting frames, frame state is kept internally by
means of arrays. Each array is associated with a single document. Each
element of the array may contain a reference to another document which,
in turn, may have a frames array associated with it (nested frames).
Frame elements are added to the array in the order in which they are
declared in the document.

Whenever a document is loaded into an existing frame, any frames
already nested within that frame are effectively deleted. Therefore, to
reproduce a frame state in a window, the only information that is
required is (1) the URL of the primary document, and (2) the URLs of
any documents loaded into existing frames and the position of those
frames in the hierarchy. If the document associated with any frame has
changed, an external document specified at the creation of the frame
need not be loaded.

URL EXTENSION

The suggested form of this extended URL is to append the main URL with
a fragment specifier (#) followed by a fragment name (if applicable),
followed by another fragment specifier, followed by opening and closing
brackets ([]) for each frame in the array associated with the document.
If the document within a frame has changed, the brackets will enclose
the URL of the current document, otherwise they will be empty ([]).
Nested frames are nested hierarchically in the same fashion.

For an example, imagine a document main.html that specifies the
creation and content for three frames (whether filled by external
reference or inline content is not important). The user selects a link
that loads document 'doc3a.html' into the third frame. This document
divides the third frame into two nested frames which are filled as
specified in the document. The user then selects a link that loads
document 'doc3a-2a.html' into the second nested frame. The extended URL
for this document is now

   main.html##[][][doc3a.html##[][doc3a-2a.html]]

When presented with this URL, an enhanced UA will load main.html and
derive frame information. Since the first and second frames have not
changed ([][]), the UA fills these frames as specified in main.html.
The UA then loads doc3a.html into the third frame. As specified in
doc3a.html, two nested frames are created. The first is filled as
specified in doc3a.html and the second is loaded with doc3a-2a.html.

Note that the content specification for the two nested frames is nested
within the specification for frame three and appended to frame three's
URL using exactly the same notation whereby the main set of frames is
appended to main.html. Nesting levels are not limited by notation.

The reason for the double ## is to allow for fragment specifiers for
IDs and named references within a document's content. For example, if
doc3a.html had inline content with an ID="here" reference, and
doc3a-2a.html had an ID="there" reference, the above address would be

   main.html##[][][doc3a.html#here#[][doc3a-2a.html#there#]]

Current browsers I have tested ignore the second # and everything
after, so a fragment specifying an ID or named reference in main.html
would still be valid.

This proposal is the same as one posted to www-html and www-style
lists, except that I've edited for greater clarity. A reference
on www.w3.org indicates www-talk is a more appropriate list so I'm
posting it here as well. Any comments?

David Perrell
Received on Thursday, 12 September 1996 20:21:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT