Re: Navigation Tag

[ Sorry if you get two copies of this, but it seems that my first
message did not get thru in 24 hours, so I suspect it vanished
somewhere. ]

On Tue, 7 Dec 1999, D.A. Schepers wrote:

> I propose a universal navigation markup tag. Using this, the author of a web
> page could designate the address of the next or previous page in a sequence.

The obvious answer to that is that we _have_ such a tag. We have had
it since HTML 2.0: the LINK element. Although there is no official
specification of the possible REL values for it, the real problem is
that browsers have generally failed to even try to implement it properly.
"We said we want LINK, but they misheard it as BLINK."

But the obvious answer isn't always the correct one.

Given the history and the present, the problem is that authors cannot
rely on LINK, and therefore they need to include specific navigation links
via A HREF too (or some other navigational tools). And this implies that
if authors start using LINK and browsers start supporting it, then
pages will have _both_ the browser's implementation of LINK and the
author's explicit links. Such duplication looks foolish, even if it isn't
accompanied with _other_ duplications (such as the widespread use of both
image links and textual links to the same information, usually without
making clear that they _are_ duplication).

So a different approach might be needed, somewhat analogously with the way
OBJECT or is _intended_ to work:

Allow the LINK element in the document body, and make it a container.
Example:
<link rel="next" href="sec7.html" title="Section 7: Hypermystics">
<a href="sec7.html"><img alt="next" src="arrow.gif"
title="Section 7: Hypermystics"></a>
</link>
Specify that a browser is recommended to implement LINK elements using
a browser-specific document-independent user interface, ignoring the
content of the element, but may alternatively just render the content of
the element (and ignore the attributes of LINK). Naturally older browsers
(such as all current browsers) would do the latter.

To be useful, this change should be accompanied with a specification of
a minimum set of REL values recognized by browsers which use the
recommended implementation. Initially this could be based on
http://www.w3.org/TR/REC-html40/types.html#type-links
hopefully amended by the addition of "Up" and "Top" (with some reasonable
definitions: "Up" means going upwards in a hierarchy of pages, as from
a subsection to a section, and "Top" means the main page of a "site",
whatever that means in detail).

> One major advantage to this concept is that a browser could map the
> navigation tags to keyboard activities (I am using CTRL+Arrow Keys)

This could be handled by allowing the ACCESSKEY attribute for LINK.
It's already allowed for A HREF and some other elements which might
appear for navigational purposes (as the content of LINK). The real
problem is to make browser vendors support ACCESSKEY reasonably. The
present situation is not very good, see
http://www.hut.fi/u/jkorpela/forms/accesskey.html

> In order to ensure compatibility with older browsers, as well as ease and
> consistency of implementation by authors, this navigation tag could be
> optionally tied to traditional navigation links.

Yes indeed.

> My take on this is that any
> particular HREF tag could be given a new argument corresponding to a
> navigation direction, or possibly to an element of a list or navigation tags
> predefined on the webpage.

That's the problem I have tried to address in the proposal above.

Note that modifying the syntax and semantics of LINK would allow
other things than navigational tools, too. In particular,
authorship information could be given as a LINK element, with
a HREF attribute referring to author's homepage (or Email address)
and the content being e.g. an ADDRESS element containing an A HREF link.

The reason for making LINK allowed in the body is of course that such an
approach lets the author put the element into the place where its content
should appear as part of the document rendering, if the browser displays
the content (instead of having e.g. a "standard" icon in its user
interface in a "standard" place).

-- 
Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html

Received on Wednesday, 8 December 1999 07:59:22 UTC