> >Dirk Herr-Hoyman <hoymand@gate.net> wrote:
> >>I would like to propose a new HTML tag that addresses a user interface
> >>problem I am seeing. I would like to see <BACKUP> (or the moral
> >>equivalent) be used to display a link that causes a Web browser to backup
> >>to the last visited page.
Rather than a new tag for this specific characteristic, I think it would be
better to work out a more general approach and one which fits, if possible,
in the existing architecture. To that end, I would suggest:
a) Navigation links are already understood by all to be based on anchors
so I believe this specialized navigation should as well.
b) If BACKUP is useful, beyond the browser notion of backup, is FORWARD
also useful? Having backed up, what does BACKUP mean? The term UNDO
means different things to different editors, does BACKUP mean
something different than the current flat history walked backward?
Would BACKUP after having backed up mean return to the screen backed
up from or to the file viewed before the one backed up from? What about
browsers which retain a tree or graph history? All this is to suggest
that IF the information provider feels that a specific click spot/button
is desireable, whatever we design should encourage/require/enable the
information provider to define the expected action and should support the
actions we expect the information provider to need.
c) With those concerns, I would propose either a new tag or new use of
<input> outside for forms. This tag, say <button value="help"> would
render a button as an <input type=submit value="help">
button on a form would be rendered. This new tag would be used inside
of an anchor and would activate the anchor when clicked. This tag would
really define a local graphic (or appropriate substitution on a character
browser) with no penalty for network transfer, lack of a graphical
interface (OR image disabled by the user on a slow connection). The
rendered label would be the information provider's choice, etc.
d) So now that I've defined how a button labeled "backup" could be placed
anywhere the provider desires, let me re-iterate the prior suggestion
that the backup function be handled via the anchor. Some possiblities:
1) A new URL method, I would favor something like 'uacmd:' (User Agent
Command) or 'uareq:' (UA request) or 'uadir:' (directive) followed
by a specific request like:
backup
forward -- to mean exactly what the browser's BACK and FWD buttons
etc mean
return -- return to the file from which this file was viewed AND
remove this file from the history tree. Like a GUI
pop-up.
... others like up, down, left, right, etc. should be
considered. Required rendering for browsers which
choose to be impaired would be to display a pop-up
indicating that the 'XXXX' command is not understood
by this browser or some such.
2) Since it is easy to envision a case where the browser expects to be
able to restore a viewed file by re-retrieval and perhaps even have
lost the return to candidate url from the local history cache,
the most general solution would be something like adding (using the
proposed?) a 'role=' attribute to anchor. 'role=backup' would tell
the browser that the intent was to backup but if that wasn't
understood, the href= url would be used. 'role=nohist' would
be useful as meaning that the new href= shouldn't be placed in the
history. 'role=replace' would mean replace the current file in the
history with the referenced file. Etc .... Extending the anchor
is this fashion should allow existing browsers to continue to present
the desired information to the user.
Dave Morris