Proposal: restricting <LINK> to hyperlinks

This is a suggestion for a change of terminology in HTML and for a
slightly different interpretation of the LINK element. In short: the
term `hyperlink' should be used more in accordance with existing
hyperlink literature and the LINK element should consistently result
in a button in a toolbar, independently of any REL attributes.



The HTML draft talks about all elements that have a URL (LINK, A, IMG
and INPUT) as `hyperlinks'. This is not in accordance with the normal
interpretation of the term. In two of them, the user has nothing to
choose. Currently, only A can really be considered a hyperlink; LINK
is used inconsistently. (Note that IMG and INPUT have `SRC' while LINK
and A have `HREF'.)

IMG is a mechanism for inclusion of sub-documents. Although in some
browsers it may be an option not to display them, this is purely a
user-interface feature and has nothing to do with the hyperstructure
of the document.

An INPUT with a SRC attribute is very similar to IMG. In later
versions of HTML, other elements may have a SRC as well: LI, NOTE,
FIG, etc. They are mechanisms for creating a (virtual) document out of
smaller parts, particularly in cases where the smaller parts are not
expressible in HTML. (SGML normally uses external entities, but URL's
are slightly more convenient.)

The meaning of LINK is unclear. Its use is suggested for attaching
style sheets, info about the author, glossaries, etc. Some of these
functions could be considered hyperlinks (link to the author, to a
`next' document, etc.) others link to meta-information that the reader
isn't supposed to see (stylesheet, navigator, etc.)



It's better to define LINK strictly as a hyperlink. It is then not
much different from A, except that the source anchor of A is a small
fragment of a document, whereas the source anchor of LINK is the whole
document. That translates to different visual presentations. LINK
would typically end up in a toolbar or menu. The typing of links (the
REL attribute) even allows a browser to use nice icons for the buttons
in the toolbar.

Note that this `toolbar' is not the same as the `banner' that is
suggested for HTML3, or the HTML viewer with multiple panes. Where the
button that corresponds to a LINK is displayed is up to the
browser. It could go into a menu, a toolbar along the side, floating
toolbox, a popup menu under the right mouse button, etc. At the most,
the style sheet could suggest alternative icons or labels for it.

LINK should not be used for meta-data, such as style sheets or
navigators. Although a URL is used to refer to them, they are not
documents for human consumption, but `processing instructions' for the
browser. Of course, in some cases there may be more than one style
sheet to choose from and in that respect the user has a choice, but it
is still not a hyperlink, that the user traverses to find new
information.

A glossary could be either way, hyperlink or meta-data, depending on
how we define a glossary on the Web: if it's just a document with an
alphabetical list of words, than LINK is fine. On the other hand, if a
glossary is some yet-to-be-defined mechanism for looking up words
automatically, then it is meta-data. For example, a browser might
allow the user to click the right mouse button on any word and
automatically send a query to a glossary server. (To be precise, the
meta-data would tell the browser how to create `computed hyperlinks',
but is not a hyperlink itself.)



I've used the term `processing instruction' (PI) deliberately. In
fact, in SoftQuad's Panorama, the style sheet and the navigator *are*
processing instructions. And although one should be careful with PI's,
this looks like a very good candidate.

It is, of course, possible to use META or a new element to hold the
pointers to style sheets, navigators, and glossary servers, but it's
more natural to declare them in front of the document. Otherwise the
parser might have to back up and start all over, because the style
sheet wanted the document displayed differently. A PI in the DTD
subset seems the best place.

It should also be possible to attach style sheets & navigators to
DTD's, instead of document instances. Panorama solves this by asking
the server for a file called `entityrc' that holds the relevant
info. This works, even independently of the HTTP-protocol, but it has
the drawback that authors have to create another file and that an
extra connection to the server is needed. I don't know a better
solution, though.


Bert
-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN

Follow-ups

• Albert Lunde (Albert-Lunde@nwu.edu )
• Roy Fielding (fielding@beach.w3.org)