> Is anyone else interested in having the server have some control over
> a clients history list?
> ... In these cases, you probably do not want to see these nodes put
> on the history list.
I have been worrying about this too. For instance if you follow a thread
from a main document, you will often be offered the chance to click an icon
to return to the main document. This is clearly an alternative to
backtracking through the history. It seems to me that clicking the icon
should be clean up the history so that it is directly equivalent to
backtracking to the main document. This would avoid the possibility of
confusion in the user's mind as to the effects of either course of action.
For this to work we need a hint to the browser to pop the history back to
the point just before the linked document *last* appeared. This could be
done via an attribute on the <A> element.
Another common case occurs with fill-out forms. Keeping a history of
the successive stages of filling out a form, and the updates to that
form by the server is of dubious value (it would only make sense in the
context of a multi-level UNDO mechanism). So it makes sense to flag
intermediate steps as not to be placed on the history stack. This could
be done by an element in the document's head or an HTTP header (the two
are formally equivalent).
So how about:
a) adding an attribute to the <A> element to rollback the
history stack to the node before the *last* occurrence of
the linked node, e.g.
<A HREF="main_doc.html" ROLLBACK>Return to Home page</A>
b) Defining a new HTTP header for history hints which servers
can generate based on META elements in document heads, e.g.
<META NAME="History" VALUE="discard">
For (b) clients would get the HTTP header
History: discard
Other values such as "rollback" may be useful. This seems preferable
to adding yet another element to HTML+. Let me know what you think,
and I will ammend the HTML+ spec.
Dave Raggett