> The LINK and A Elements
> ========================
> ...
> REL
" The REL value may be used to guide the browser in determining the exact effect
of activating a link. The effect of activating either an <A...> or <LINK...>
tag, when no REL value is specified, is usually to jump to the given HREF,
making that document visibly available to the user. This behavior may vary
drastically with different REL values, not all of which will require an HREF.
[and/or, we could add the separate ACTION advisory attribute as Ian proposed]
>Browser-defined links
>=====================
I'd rather be a bit more specific, at least for purposes of the discussion:
REL values that represent Browser- or User-defined HREFs [1]
============================================================
> HOME [1]
> RESERVED. Defined by the user (using the WWW_HOME
> environment variable). This relationship may not be
> overridden; HTML user agents should ignore any
> author-supplied REL=HOME setting.
>
> BACK [1]
> RESERVED. Defined by browser. This relationship may not
> be overridden; HTML user agents should ignore any
> author-supplied REL=BACK setting.
No controversy. Implemented in every browser I've seen, in HyperCard, and
in other popular hypertext systems. Notes on browser behavior are obvious,
something like: "HOME customarily returns the user to his/her own home page.
BACK customarily returns the use to the last page that s/he had visited."
> FORWARD [1]
> RESERVED. Defined by browser. This relationship may not
> be overridden; HTML user agents should ignore any
> author-supplied REL=BACK setting.
Slightly more problematic. This is chronological, yes, the complement of BACK?
We may need a note on browser behavior here just to say "FORWARD is the reverse
of BACK, and usually allows the user to return to the page visited immediately
after the one they are currently viewing (assuming it was reached through BACK).
If the user did not reach the current page through BACK, FORWARD has no clear
customary meaning, and may default to (behave similarly to) NEXT or any other
reasonable value".
REL values that represent Author-/Document-assigned HREFs [2]
=============================================================
>REL=NEXT [2]
>REL=PREVIOUS [2]
More browser behavior implications, since they are expected to keep track of
which document is the NEXT of that one, which is its PREVIOUS, etc., and be
able to map these to toolbar or menu items. In this case 'NEXT', 'PREVIOUS',
etc., have actually become pronouns that represent specific HREF values. It
is similar for REL=INDEX etc.
REL values that invoke browser-specific presentation behavior [3]
==================================================================
The remaining RELs that seem to clearly require some presentation behavior:
> REL=INCLUDE [3]
I like this one, I would have preferred to say something like ACTION=EMBED,
but it's the only one of the remaining links that leaves the user agent in
front of the user agent anywhere other than at the named HREF. The def'n
seems to clearly imply that you stay in the same place and the browser is
changing what you're looking at. So perhaps this needs to be included in
the 'hardwired' list above. Alternatively, if we adopt Ian's ACTION (or
METHODS) list, INCLUDE becomes an ACTION we can assign to any given link,
regardless of its REL or HREF values. This seems more appropriate to me,
as I might want to "INCLUDE" or "EMBED" a footnote, a glossary definition,
a short bibliographic entry. The ACTION is a separate idea from the REL.
> REL=BANNER [3]
Since this text does not move around like other text, the browser has to
support this explicitly, and authors have to be aware of the implication
of using it. If we like this one, we'll probably have to hardwire it in
the standard as well. Otherwise I don't see how an author can build one
document that supports both BANNER- and non-BANNER-implementing browsers.
> REL=STYLESHEET [3]
Another exception. I don't think anyone wants to 'jump to' a stylesheet,
although this may serve a documentary purpose. Rather, it is interpreted to
alter the presentation of the entire document in which it appears...
Default behavior here might be to bring up the browser's 'HTML appearance
preferences' dialog which presumably maps one to one to the presentation
options available in the browser, set to the values defined in the stylesheet.
One of these 'browser preferences' options should be whether or not to show
the REL values as part of the link anchor, or show them only when the user
hovers over the link (as is done now for the HREF of an A tag).
(Other) REL values which are documentary, application- or author-specific [4]
=============================================================================
All of the other values appear to be safe for the browser to interpret as
'jump to (the given HREF)'. Any list of these should be strictly advisory,
as there is no need for browser vendors to do more than default them. I
posted separately on the naming/treatment of such values, as it is a separate
issue from the definition of standard values.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5