Re: Proposal: restricting <LINK> to hyperlinks
||email@example.com (Murray Altheim)
||Thu, 24 Aug 95 18:37:47 EDT
Bert Bos <firstname.lastname@example.org> writes:
>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.
>[description of current LINK, A, IMG and INPUT element usage...]
>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.
Albert Lunde <Albert-Lunde@nwu.edu> responded:
>While this suggestion is logical, it flies in the face of existing usage
>of <LINK> (spotty and confusing as that is.)
The reason there has been so much recent discussion over BASE, LINK and
META is that each has overlapping functions in current usage. What I
believe we are trying to do is clear up this "spotty and confusing" usage
before it becomes even more widespread, especially with implementation of
UA and editors that incorporate BASE and LINK features.
Bert Bos <email@example.com> continues:
>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
I cannot agree more fully. This is part and parcel of my continuing
argument over using META for non-link, unrespected meta-information (such
as expiration, keyword, search content, bookmark information, etc.), LINK
for extra-document linking (like toolbar buttons as you mention), and BASE
for relative link resolution.
>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.)
Very good point, but this sounds like a 3.0 implementation; I would
certainly leave glossary specification open-ended, with support for either
method. I'm sure there will be times where a document author merely wants
to define a few terms, other times when a large-scale glossary tool is more
For the purposes of HTML 2.0, I don't see the advantage in explicitly
specifying any type of glossary or indexing mechanism, and believe that 'A'
with a fragment-id into a glossary document (such as that implemented on
many of W3C's documents) serves the purpose well. As Dan has repeated many
times, the power and beauty of HTML has been its simplicity, and I couldn't
The past level of discussion over BASE, LINK and META seems to have died
down a bit. I'm assuming we're all tired of it. I know I'm not the only kid
in the sandbox on this one. Are we moving at all toward any sort of
My recommendation on this would be (in a nutshell):
(1) BASE: relative link resolution
from the earlier August 4th draft:
>5.2.2. Base Address: BASE
> The optional <BASE> element specifies the base address for
> resolving relative links from the document, overriding any
> context otherwise known to the user agent. The required HREF
> attribute specifies the URI for navigating the document (see 7,
> "Hyperlinks"). The value of the HREF attribute must be an
> absolute URI.
(2) LINK: hyperlinks
melding the August 8th DTD draft and Murray Maloney's draft:
>5.2.4. Link: LINK
>The LINK element indicates a hypertext link relationship
>(see 7, "Hyperlinks") between the document in which it is found
>and some other object. The LINK element takes the same attributes
> as the <A> element (see 5.7.3, "Anchor: A"). Any number of LINK
>elements may be used within the head of an HTML document.
>The LINK element is empty (does not have a closing tag).
>The hypertext link described by the LINK element is not typically
>represented within the text area of an HTML user agent. Instead,
>an HTML user agent is free to either ignore any LINK element and
>the hypertext link associated with it, or to represent the
>hypertext link in some other way.
>Presenting hypertext links as active icons in a toolbar is one
>way to present them to the user. Another may be to present the
>target document in a concurrent window, such as with a table of
(3) META: document meta-information
from the August 8th draft:
>5.2.5. Associated Meta-information: META
>The <META> element is an extensible container for use in
>identifying specialized document meta-information.
>Meta-information has two main functions:
> * to provide a means to discover that the data set exists
> and how it might be obtained or accessed; and
> * to document the content, quality, and features of a data
> set, indicating its fitness for use.
This seems pretty simple. I would hope to see the LINK definition made more
explicit and expanded somewhat to support Murray Maloney's language on
hypertext links (similar to the above), which I think is very well written.
Would someone please respond as to where this simplified proposal would
fall flat in HTML 2.0? This seems in line with Murray Maloney's direction
on LINK and LINK attributes, eliminates the current confusion (both DTD and
current UA implementation) over BASE, and allows LINK and META to function
as stated: hyperlinks and document meta-information, respectively.
As regards links (as redundant to META or vice versa) being an expression
of document meta-information, the semantic phrase "meta-information" only
need be more tightly defined for LINK as that information provided that
resolves to a link. As Murray M. says: " Its purpose is solely to inform
the user agent that a link exists." How this is expressed in a UA is not a
question of HTML proper but provides a direction for browser authors.
Roy Fielding discussed previously the original intention of META as "a
halfway-house for unrespected metainformation". I would assume from his
message that he advocates creating an element for all defined respected
metainformation, which I don't disagree with in principle. For the purposes
of completing the 2.0 specification, I believe delineating the
functionality of LINK and META is step one forward, leaving further
definition of respectability to future DTD versions.
On another note, discussion has occurred recently over the problems of not
following current usage (ie., early implementation of a draft standard). I
would presume to ignore current usage where it is, as Albert says "spotty
and confusing". This seems to be the case in current usage of the above
three elements, as amply demonstrated by Ka-Ping Yee and others in
describing variations in browser behaviour.
 "HyperText Links in HTML" by Murray Maloney. This was sent to HTML-WG
Fri, 11 Aug 1995 11:24:34 -0400 (EDT). I have made this copy available on
my server at:
Murray M. Altheim, Information Systems Analyst
National Technology Transfer Center, Wheeling, West Virginia