Re: PATHs in HTML
Bert Bos <bert@let.rug.nl>
Message-id: <9401121700.AA13451@freya.let.rug.nl>
From: Bert Bos <bert@let.rug.nl>
Subject: Re: PATHs in HTML
To: www-talk@www0.cern.ch (* WWW discussion list )
Date: Wed, 12 Jan 1994 18:00:28 +0100 (MET)
In-reply-to: <9401102022.AA00994@redback.> from "Jim McBeath" at Jan 10, 94 12:22:32 pm
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1744
I would definitely vote "yes" to the PATHs-in-HTML proposal.
Jim McBeath writes:
|Dave Raggett and I have been having an email discussion of PATHs in HTML.
|What follows is the results of that discussion, which I present as
|a proposal for an enhancement to HTML (and WWW clients).
Maybe the word "PATH" is too vague and too overloaded already. Why not
call it a "TOUR"?
|Client programs could add the following commands that deal with paths:
|1. Traverse current path
|2. Traverse named path
|3. Find in current path
|4. Find in named path
|5. Print current path
|6. Print named path
If I understand correctly, these commands automatically become
available to the user iff the browser detects a "Subdocument" or
"Path". It would be interesting to see how interface designers handle
this: greyed menu items? a pop-up tool bar?
|This scheme is easy to understand, easy to define, and easy to implement,
|entirely in the client. Clients which did not understand REL=Subdocument
|and REL=Path would just ignore those attributes; the user could still use
|the path node to get to the nodes in the path by selecting an anchor.
!!!
The most heavily used button in my Mosaic browser is the "Back"
button, which proves to me that this is something I've been waiting
for.
Bert
--
_________________________________
/ _ Bert Bos <bert@let.rug.nl> |
() |/ \ Alfa-informatica, |
\ |\_/ Rijksuniversiteit Groningen |
\_____/| Postbus 716 |
| 9700 AS GRONINGEN |
| Nederland |
\_________________________________|