Linking Arms, Arming LINKs

Thomas Dowling tdowling at ohiolink.edu
Thu Jul 5 11:16:32 EDT 2001


On this list and elsewhere, I have occasionally bemoaned the fact that
no major browser ever saw fit to support the LINK element (and thus
never completed support for HTML 2, among other shortcomings).  If
you're unfamiliar with it, LINK was added to the first formal HTML
specification to answer the complaint by the hypertext experts of the
day that the language had no syntax to describe the relationships
between the current document and any other documents.  That is, while
this may make perfect sense to humans, it's opaque to the browser
itself:

  <a href="next.html">Next Page</a>

It also shows a relationship to the next page from a *point* in the
current document, not from the document as a whole.

If the browser understood the importance of this link--"next" being a
pretty common place to go--it could provide a place in the user
interface for it, and for other pages identified as having common
relationships to the current page (previous, first, last, up,
alternate printer-friendly version, etc.). LINK elements within a
document's HEAD provide this:

  <link rel="next" href="next.html">

Once supported in the browser's interface, the way to navigate links
for such identified relationships becomes consistent not only from all
points on a page (this "next" link never scrolls off screen), but from
page to page, site to site, and vendor to vendor.  If implemented
across the board, the essentials of navigation would work the same in
a library's web site, catalog, indexing/abstracting services, full
text sites, and other sites they use.

The problem, of course, is that while the major browser makers have paid
lip service to standards support, they've always dodged LINK implementation,
pointing out that almost no authors use it.  Authors then never bother
learning about it because no major browsers support it.  And on and on.

This may be changing, depending on whether you think Mozilla will ever
be part of a "major" browser.  With recent Mozilla builds, you can add
a toolbar that displays the LINK relationships (see <URL:
http://bugzilla.mozilla.org/show_bug.cgi?id=87428> for discussion).
This will probably be built into the next release, and may very well
be in Netscape 6.1.

This means that a growing number of users is likely to have the
potential to benefit from pages with sensible LINK relationships
(please don't misinterpret me: these would be *in addition* to in-page
links to the same resources).  But very, very few pages will take advantage,
and users are likely to disable the LINK toolbar eventually.

Partly to take advantage of this, and partly as an excuse to spend
some time really thinking about how pages on my sites relate to each
other, I'm planning to go through several sites I run and create LINK
elements as appropriate.  I plan to focus on subsets of the
relationships supported by Mozilla as of <URL:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40212>,
especially next, previous, up, top, contents, search, and help.  How
many pages don't point somewhere for at least one of those
relationships?

I invite other webmasters to do the same, and to ask vendors if they
plan to follow this HTML standard for navigation.  The worst that can
happen is that you spend an afternoon reacquainting yourself with how
your pages are laid out.  The possible benefit is a boost to your
site's usability for users with supporting browsers and the beginnings
of an additional way to think about page navigation.


Thomas Dowling
Ohio Library and Information Network
tdowling at ohiolink.edu



More information about the Web4lib mailing list