W3C home > Mailing lists > Public > www-style@w3.org > September 1996

Extended URL for frames

From: David Perrell <davidp@earthlink.net>
Date: Wed, 11 Sep 1996 18:50:35 -0700
Message-Id: <199609120154.SAA02538@cyprus.it.earthlink.net>
To: <www-html@w3.org>, <www-style@w3.org>
I propose an extension of the URL fragment specifier that will
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 will not break existing browsers.


Frame state is kept internally in a UA by means of arrays (ordered
lists). 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 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 the 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


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
in the first frame that loads document 'doc3a.html' into the third
frame. doc3a.html then divides the third frame into two nested frames
and fills them as specified. The user then selects a link in the first
nested frame that loads document 'doc3a-2a.html' into the second nested
frame. The extended URL for this document is


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 and creates the two
nested frames, loading the first as specified ([]) and the second with

Note that the 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 idea for the double ## is to allow for legitimate fragment
specifiers. 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


Current browsers I have tested ignore all after the second #, so a
legitimate fragment following main.html would still be valid.

In the example, two documents may need to be accessed that would not be
accessed if bookmarks were saved as framesets: main.html and
doc3a.html. If either of these documents had inline content they would
need to be accessed in any case.

There is some question as to whether URLs are 'intended' to reproduce
state. Executables and server-side scripts can reproduce particular
states via arguments appended to their URLs, and I've heard no
complaint that this is bad behavior.

David Perrell
Received on Wednesday, 11 September 1996 21:54:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:41 UTC