Re: Proposal: restricting <LINK> to hyperlinks

Albert Lunde = |
Murray Altheim = |>

 |> (2) LINK: hyperlinks
 |> 
 |>    melding the August 8th DTD draft[1] and Murray Maloney's draft[2]:
 |>    >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).
 |[...] 
 |> 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.
 |
 |One of the existing usages of LINK is to present a mailto: URL
 |for the author of a document. Various proposed usages have included
 |a URL for a style sheet. I'd say that actual usage has favored the
 |idea that <LINK> describes a URL related to the document, in various
 |ways, which may or may not represent a "hyperlink" in the usual
 |sense, and may or may not make sense in a toolbar.

A LINK to indicate the author with a mailto: is a correct hyperlink
and would not be out of place in a toolbar (NB: I don't say that it
*must* be put into a toolbar).

The basic principle is that a browser doesn't have to be smart to use
LINK. It may do all kinds of nice things with LINK elements that have
a recognizable REL attribute, but if it just puts all LINKs in a
drop-down menu that should be acceptable as well. For REL=made that's
certainly acceptable.

A style sheet is a different matter. There are some implementations. I
know (and have running copies of) four:

 1. Cascading Style Sheets: partial and experimental implementation in
    Arena and emacs-W3, uses <LINK REL=style...> as well as embedded
    <STYLE>...</>.

 2. SoftQuad Panorama PRO: uses processing instructions
    <?STYLESPEC...> and a separate `entityrc' file

 3. My own `stream-based style sheets': implemented in Argo (demo'ed,
    but not released); only uses embedded <STYLE>...</> or client-side
    resource files.

 4. Hyper-G's style sheets: used in Harmony, client-side style sheets
    only.

There may be others; I remember that Viola-W3 had something, but I
don't know how it works.

It seems that style sheets in LINK are not very widespread, and are
very experimental anyway. If it can be shown (and I think it can) that
it is better to restrict LINK to things that are more like hyperlinks,
then there would be no problem leaving REL=style out of the
definition.

The same goes for REL=navigator, if the navigator is like in Panorama:
not an independent document, but a special style sheet to selectively
display and hide elements.

My checklist for LINK runs something like this:

 1. can the link be put in a toolbar or menu?
 2. can the link be ignored altogether?
 3. can the type (REL attribute) be omitted without harm?
 4. does the user explicitly have to traverse the link for something
    to happen?
 5. does it perform an action or display new info

If you get 5 times `yes' than it's a LINK.

Maybe the way to get our intuitions about LINK (and META and even
BASE) into line, is to come up with as many examples as we can and see
if we can't agree on how they should be handled?


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

• Joe English (joe@trystero.art.com)