Re: My suggestions

"William M. Perry" <wmperry@aventail.com> wrote:
>Karl Dubost writes:
>>At 10:13 +0100 21/01/1997, Peter Flynn wrote:
>>>Actually it's a very big surprise. Lack of standardisation has never
>>>prevented browser makers from jumping the gun in other fields, so I fail
>>>to see why this should prevent them here (in fact both Lynx and Mosaic
>>>do implement LINK partially).
>>
>>Could you tell us what partially does mean ? Which functionnalities are
>>available in Lynx and Mosaic ?
>
>  Lynx, Mosaic, and Emacs-W3 can all show you a toolbar or drop-down menu
>of defined <link> relationships.  So, if you had a document that looked
>had:
>...
><head>
>...
><link rel="toc"       href="/docs/toc.html"     title="Contents">
><link rel="help"      href="/docs/help.html"    title="Get Help!">
><link rel="copyright" href="/docs/copying.html" title="Copyright Info">
><link rel="glossary"  href="/docs/glossary.html" title="Glossary of Terms">
></head>
>...
>
>  You would have instant access to any of those links. Emacs-W3 does it
>both with a menubar entry 'Navigate', as well as a toolbar, Lynx shows a
>row of links across the top of your display, and Mosaic/Win 3.0 shows it in
>a window off to the side.  So the info is _always_ avaiable, and won't run
>off the top or bottom of your screen, etc.

	Though Lynx does not waste it's precious "character cells" keeping
the toolbar always on the screen, it can be accessed at any time via the
TOOLBAR keystoke command (normally mapped to '#').

	These are the REL values (case insensitive) which the current
Lynx code recognizes as "banner instructions" for creating its
psuedo-toolbar:

	Author, Banner, Begin, Bibliography, Bookmark, Child,
	Contents, Copyright, Disclaimer, Editor, End, First,
	Glossary, Help, Home, Index, Last, Meta, Navigator,
	Next, Origin, Parent, Pointer, Prev, Previous, Publisher,
	Sibling, ToC, Top, Trademark, Translation, Up

It will use those REL values as the link name, unless a TITLE
attribute is present, in which case it will use that value.
A number of them are expected to have a TITLE=[link name],
but need not.  For example, Banner and Bookmark are "generic"
banner link tokens, expected to have a TITLE=[link name]
descriptive of what they are, and in effect make the namespace
for banner links infinite.

	An HREF must be present for the banner links to be created,
except for these three "special cases":

	Help, Home, Index
	
Lynx will use the URL for its own main help page, default home
page, or default index file, respectively, (based on its
configuration and/or environment variables) if an HREF isn't
present in the LINK.

	For LINK REV="made" or REV="owner", it is not necessary
for the HREF to be a mailto URL, but if it is, the value of a
TITLE attribute, if present, will be used as the default Subject
header.  The HREF could point to a mailing script, or to the
author's home page, for example, if the crass spammers become
a problem for the author.

	The considerable discussion which has ensued about the
REL/REV attributes hopefully might induce Liam Quin to reconsider
the invitation from the IETF to update the Malony/Quin relrev
draft.  It would be ideal if an IETF WG focussed on these issues
were created, restoring fully public, fully documented and archived,
dissussion, review, and ultimate standardizing in the area of HTML
-- based on direct participation by any and all interested persons
and organizations involved with the Internet (as, thank the Lord,
still exists for HTTP).

	This is not intended to be a flame, but consider the
possibility that the attitude:

	I was asked if I wanted to chair a separate working group.
	But I have been too busy, and I don't think the travel is
	justified, particularly when Netscape and Microsoft aren't
	really very interested, I think, in IETF standards in this
	area.

creates as self-fulfilling prophecy, with no prospect of the values
which originated the Web being restored.  This cliche still applies:

		If you're not part of the solution,
		then you're part of the problem!

That's the "default" in the "real world".

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545

	<Q LANG=en_US>My only regret is that I have
		      but one life to give to my Web</Q>

=========================================================================

Received on Thursday, 23 January 1997 17:41:22 UTC