> If you
>have a specific sequence of documents in mind, you would hard-code the name
>of the "previous" document into the [current] document (that's how I do it
>on my pages).
That is how nearly everyone does it, and it causes a certain non-intuitive
behavior in browsers. Browsers typically keep a history and permit
forward/backward jumping through the history list. Many pages have a "go
back" link, which suggests a function equivalent to the "back" function of
the browser. However, following the "go back" link *adds* an element to
the history list, while the "back" function of the browser does not alter
the history list but moves the current position "back" in the list.
A link can already contain a "relationship" attribute:
Used to describe the relationship of the linked object
specified with the HREF attribute. The set of relationship names
is not part of this specification, although "Path" and "Node"
are reserved for future use with hypertext paths or
guided tours. The REL attribute can be used to support search for
links serving particular relationships.
[From the HTML3 draft spec]
Proposed interpretation of REL=back by conforming browsers:
- if the URL specified in the HREF attributed is present on the history list,
following the link is equivalent to performing a number of "back" actions
until the specified URL is reached.
- if the URL specified in the HREF attribute is not present on the history
list, or if there is no HREF attribute, te REL=back attribute has no
In programming language terms, the proposed interpretation is closer to
"throw" than "return", but not quite identical to either (because the
return address must still be hard-coded.) A true "return"-like or
"catch/throw"-like facility might be useful. The advantages of the
REL=back interpretation is that it requires only a very small change to
browsers, and is backward compatible with both current pages and current
Software Engineering Research Center
Department of Computer Sciences
1398 Computer Science Building
West Lafayette, IN 47907-1398