HTML link types - how much must be specified in the standard ?

Craig Hubley (
Tue, 16 May 95 04:30:55 EDT


Good job! Here are the meta-comments, detailed commentary follows in a
separate note.

> It is a first cut at a list, with a small attempt at
> describing what some of us have been discussing for
> a couple of years. In particular, I'm not convinced
> that the list of Document Types is needed anytime soon,
> but I included it after following a URL that Dan sent me.

I find the 'document types' list troublesome, as it is not a
statement of relationships *between* documents but rather of
the nature *of* documents, and that raises a whole host of
issues. Could we possibly make this a separate RFC ?

> I've tried to go lightly on browser behaviour, but your
> mileage may vary. Please let me know. I don't see
> how I can avoid some mention of possible browser behaviour
> in the face of certain REL/REV values, but I don't know
> how far I can safely go without overstepping the bounds
> of the HTML WG.

I think we need more mention. There are several navigation-oriented
roles, some of which which are already implemented in most browsers.
These are the core. If we actually want them to *replace* the hand-
crafted approaches used by authors now, though, they have to be put
into *all* browsers and the list of roles put in the HTML standard
itself. Otherwise I will still need my 'next' cgi-bin script to be
sure that any compliant HTML browser will be able to read my document.

This is a different situation than the 'informational' link roles which
imply no behavior beyond the standard 'goto (HREF)' of an <A ...> tag.

I understand why we need to separate the syntactic and semantic definitions,
but this list already includes explicit and implied browser behaviors, and I
don't think we can avoid dis-ambiguating a few more, if we want the intent
of this document to be fully understood and its potential to be implemented.

If the HTML standard does not specify the exact behavior of "next", then I
still need to hardwire it, therefore I gain nothing if this document is
only advisory. The navigational links that imply a specific browser behavior
should be specified in the standard in at least a 'notes on behavior' sidebar.
Is there a problem with this ?


I think the link types Dave/Murray have defined are all useful, but most can
be reasonably interpreted as an assignment of a REL value to mean a specific
HREF, or as a simple 'jump to (HREF)'. Values which imply a 'jump' can be
purely advisory.

It seems there are at least three levels of user agent behavior implications
in this list:

1. those which require the browser to implement a very specific behavior (e.g.

2. those which allow an author to use a REL value instead of a specific HREF,
essentially using the REL value as a pronoun (e.g. NEXT, PREVIOUS) and
may represent those 'pronouns' as generic icons on a toolbar or a menu.

3. those which are more or less documentary in nature, and which may always
be interpreted with the default behavior 'jump to (HREF)' reasonably if
no more specific behavior has been implemented in the browser.

As I said above, it's hard to guarantee 1. and 2. will be available to every
user if REL values are not expressed directly in the standard. Authors will
be expected to accomodate both implementing- and non-implementing- browers,
which is a problem when the behavior of the link cannot default to a 'jump'.

REL values of type 3., on the other hand, can be reasonably pushed off into
an advisory document, as they require no specific behavioral guarantees of
an HTML user agent.

I have separately posted a detailed commentary on Murray's list of values,
which discusses the implications of the 'user agent behaviors' in detail.

It would be useful if we could debate the implications of specific values
separately from the above. Therefore I've split this into two threads:
this one to debate what needs to be standardized to what level, and how
to decide whether a given REL value (if any) ought to be defined in the HTML
standard or simply included in an advisory RFC.

Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5