Re: HTML link types - implied behavior of specific REL vlaues

Craig Hubley (
Fri, 19 May 95 03:12:12 EDT

> By my reckoning, only INCLUDE, BANNER and STYLESHEET
> are REL attributes which might require anything more
> than a "goto" behaviour. Given that we the web seems

I think we are reckoning the same, I think those were
the only three I thought 'exceptional' in this regard.

> to be working w/o stylesheets today, I could argue that
> no special behaviour is _required_ for it. And, since

Sure, you could just show the stylesheet and do nothing.
I kind of like this default. It means browsers that don't
support stylesheets will be constantly showing users what
they *should* be doing and are not. If authors actually
use them. This is a nice way to get the market driving

> BANNER is simply a special case of INCLUDE, I could argue
> for removing it altogether. That leaves INCLUDE.

I really *like* the INCLUDE/EMBED link, it was one of the
nicest things about KMS (a pioneering hypertext system).
You could just consider it to be a 'link' to a page that
is the same as the original, plus the embedded text/data.
However, this suggests that the HREF would be the *whole*
page, not just the stuff to embed... A non-INCLUDE-aware
browser would show you a page with just the embedded text.
That isn't too bad actually.

> Please explain the use of <A or <LINK w/o a HREF value.

Actually I thought that people were already using REL values like
'NEXT' *instead* of an HREF, given that the head might include a
'link' that defined <LINK REL=NEXT HREF="http://...nextpage">.
It seems that this is *not* the case, I must have misunderstood.

It seemed like an obvious extension to me that if the behavior of
NEXT is defined in the head, you don't need to restate how to look
up the NEXT in body, you can just say <LINK REL=NEXT> and be well
understood. Except by browsers that don't process the relationship
as stated in the head. That's why I thought this was a problem.
If no one is doing it, it isn't.

> > 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".
> OK, maybe it would be helpful to explain this better, but it
> not part of HTML. It is simply a reserved keyword which
> may not be used -- or at least has no meaning -- in HTML.
> Just like HOME and BACK.

So you intend *all* REL values to be strictly informational and to
guide nothing but cosmetic aspects of presentation, those that do
not affect the flow from one page to another ? That's reasonable.
It doesn't matter to an author much if a link 'HOME' is in the browser
button bar, or part of the text. It won't foul up his document. If
we can say in the standard that REL values are *not* allowed to alter
the expected presentation/sequence of pages beyond where/how links appear
to the user agent, then we probably don't need anything more, as you say.

However, my expectation was that REL values *could* affect navigation.
If we said that HOME, BACK, and PREVIOUS have 'no meaning' in HTML
*and* allowed them to alter the navigational sequence of the document,
then I can write a strictly HTML-compliant browser that, when it
encounters a link where REL=HOME, always returns you to my company's
home page. I don't think we ought to leave such a 'loophole' open,
at the very least we should strongly discourage such use with some
guidance and a clear statement of who is responsible when something
goes wrong with a browser interpreting a document.

Likewise nor naming schemes:

> I'm not sure what you mean by "expected to keep track of".
> The <LINK REL=NEXT HREF=...> will tell the browser
> which document is next. To take advantage of this

Actually it tells the document how to retrieve the next document,
which may be a static URL, or may be a more dynamic cgi-bin URL.
Subtle difference.

> information, a UA should provide a user interface hook
> which allows the user to access the PREVIOUS/NEXT document.

> I'm not sure what the point is in calling them "pronouns",
> but they do not (in and of themselves) represent any
> specific HREF values. The HREF value has to be provided.

In the head. But am I allowed, in the body, to say:

<LINK REL=next>next page</LINK>

leaving out the HREF, since 'link to next' was defined in the head ?
I thought this was allowed. Thus I called these REL values 'pronouns'
(as they replace the more specific entity with a more generic abbreviation).

*Not* allowing it, that is, requiring the HREF to be stated anew each link,
seems to be better, as it will support non-REL-concious browsers during
the transition period. It also allows different semantics for 'next' to be
defined (in the body, where they do not have any implications for browsers
beyond a 'goto') by stating different HREF values. This might be of some use
differentiate, say, chronological from spatial 'next', or to allow multiple
paths through a document (e.g. two different critics' paths through a book).

This would encourage standards-forming behavior as, if I have eight different
ways to get to the 'influences' of a painter, I can say REL=influences eight
times with eight different HREFs, in the body, each pointing to a different
artist that the 'artist under discussion' emulated, the map generator creates
one map that follows them all. Over time 'influences' becomes a standard for
art criticism documents. No behavior besides a 'goto' is ever required. If
REL=next means something radically different to some group of authors, tough,
but for now we need not disallow its use in the body strictly for information.
Your 'reserved' warning in the RFC would be enough.

This would partially solve the name space problem, at least for browsers,
Even in the worst case where REL=next etc. is used in links in the body for
differnt things, end users can tell which 'next' is which from context or
from the anchor text.

> These can be safely treated as "goto".

Yes, if the HREF appears explicitly in every link. If this is what you're
proposing, no problem. It's backwards-compatible, and semantically clear.
The REL value has no influence other than to tell the browser to support
some consistent paradigm for navigation. It can't affect the sequence and
it doesn't matter if 'REL=next' in links in the body, as only those in the
head would appear in the button bar. In the body 'next' has no special
meaning... ?

> > 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.
> Hmmm. Let's have a separate discussion of whether ACTION is needed
> and what keywords it would support -- now and over time. I'll
> even agree that INCLUDE or EMBED would be likely candidates
> for such a list if it is deemed to be required.

Yes. But I am thinking now, as I hinted above, that defaulting to 'goto'
for a REL=INCLUDE is not so bad, except for user agents (like search engine
worms or map generators) which will not know after they follow such a link,
if they are at a page with the entire text, or at one with only the INCLUDEd
text. I agree that this is serious enough to prompt us to push INCLUDE off
until we have a reliable way to define such actions. It just doesn't seem
worth it to hold up standardization of the other values just for this one.

A separate discussion on how to specify link-related actions seems to have
popped up simultaneously with this REL/REV discussion. IT's an issue that
won't go away. I believe that the WWW (rather than just HTML) needs a model
of link behavior and a way for a document in any format to support such
behavior. Otherwise it would be difficult for a link in a PDF or RTF page to
include reliable links to a document in HTML, or to one in SGML, or VRML,
etc. The link model is clearly a web-wide problem, and HTML can't do more
than provide a reasonable interface to the aspects of the link model that
it supports. As the lingua franca of the Web, though, the HTML group has
a responsibility to lead in this regard I think. Otherwise the web might
splinter, and that's not good for anybody.

> In any case, <A REL="INCLUDE FOOTNOTE" ...> would seem to give you
> what you need -- as described above.

Once again we have this problem of 'what page do I end up on?' (WPDIEUO?)
Obvious to a user, scary for a map generator or search engine worm. But
a REL=footnote is no problem if the anchor text itself *is* the footnote
text. In this case a compliant browser can generate a number/symbol as
anchor, moving the anchor text. A browser that does not support special
'footnote' behavior will place the footnote in the midst of the text in
the font/color of any other 'link anchor'. Totally backwards compatible.

This is a little clumsy but it will not cause anything to explode and
once again, the market can force the update as authors start to use
footnotes. If it *does* support special 'footnote' behavior, then it
can appear at the bottom of the page, or sitting alongside in its own
window. Either way there is only one 'HTML page' and one unified end
user presentation, and no confusion about whether an HREF includes the
full page or just a 'diff'. How the footnote appears is of no interest
to a search engine worm or map-generator; All it needs to know is what
page it is on, and if we follow the above convention it will always know.

> Well, the author could accept that a document would have some features
> in UAs that support BANNER and not in others. Sort of like TVs
> that support color, surround sound, captions, SAP, etc.

Yes. A Banner in a non-compliant browser would simply appear as more
link anchor text, if we followed the convention above.

> Clearly there must be a binding between the BANNER attribute and
> the <BANNER> element. This leads me to wonder whether BANNER
> should be a supported value. Perhaps the generalized INCLUDE
> mechanism is all that is needed. The included document could,
> after all, include <BANNER> ... </BANNER>. I'm not sure why
> Dave wanted to special-case BANNER.

If we can accept the 'anchor text hack' where the actual footnote or
banner are taken from the anchor text, rather than being new HREFs,
then authors can simply set HREF=(the current page) and non-compliant
browsers will be fully supported.

> Not an exception. It depends on the context in which it is used.
> If used in a <LINK>, then it is intended to be read and applied.
> If it is used in an <A>, then it is intended to be a hypertext
> link to be traversed like any other.

Ah. I see. So <LINK> is intended to have 'active' interpretation
of a REL value, and <A> is not ? Does a <LINK> with no REL value
specified, default to the behavior of an <A>, i.e. the 'goto HREF'?
I am not sure I like the same attribute, i.e. the REL, used to
specify something strictly to the *user* in an <A> tag, and to
both the user and the user *agent* in the <LINK> tag. This will
probably lead to errors when authors used to <A> tags start to
use <LINK> tags. I would prefer if the behavior of <LINK> and
<A> tags always defaulted to the same thing, and REL meant the
same thing in each. That would make <LINK> a strict successor
to <A>. Isn't that what was originally intended, to force some
stricter semantics on links in the long run ?

> In the former case, the onus is on the UA to read and apply the
> stylesheet and, perhaps, provide a facility to view/edit the
> stylesheet (or a copy) that the author specified. We cannot
> require the UA to do anything with it. The user may have
> set their preferences to ignore stylesheets specified
> by authors.

Yes. In this case *all* REL values, including those specified
in <LINK> tags, should be strictly interpreted as 'goto (HREF)'
rather than some 'nicer looking behavior', don't you think ?
At least I would like to see users able to choose between:
1. fully stylesheet-specified presentation
2. browser-defaults-only presentation (sure, 'pretty up' the footnotes)
3. all-fancy-stuff-off presentation (no, show me the stuff no-frills)

I am worried about browser vendors hardwiring some interpretation
of REL values into their browsers, while others are defined in
stylesheets. This will definitely lead to unpredictable behavior.
I favor an interpretation that lets stylesheets override anything
that is doubtful, i.e. the stylesheet is where this preference
belongs. Each vendor may default to different sets of preferences
(as with fonts, etc.), but some 'plain vanilla' mode might help if
things screw up (as they always do) with the fancier presentation.

> In the latter case, I suggest that the UA has no responsibility
> to read or apply the stylesheet. Various user-environment
> parameters would guide the UA in deciding how to present the
> specified document (stylesheet). This might be a plain text
> view of the document, a custom editing tool, or a commercial
> software package. The point being that we (HTML WG) can only
> suggest how this form might be used.

I agree. We could make suggestions but only clearly stated as such.

> Well, except for PATH and NODE, I think that it is safe to say
> that the rest can safely be treated as "goto"s. But I do think
> that it would be helpful to provide some hints as to behaviours
> which might be applied.

PATH and NODE are a way of defining alternate navigation paths
through a single corpus, one of the main reasons for 'typed links'
in most hypertext systems is to make such 'alternate markups' easy
to find and follow, and to allow them to be defined by parties
*other than the author* as well. This might be an 'annotation'
issue, and another thing that should be specified on the W3 level,
as a single PATH might include many documents in multiple formats.

So, it seems to me that if we can adopt the 'anchor text convention'
I suggest, drawing the FOOTNOTE and BANNER from the anchor link text
rather than the HREF (and counting on compliant browsers to generate
some reasonable footnote mark, and not show the BANNER in the body),
we can support INCLUDE, FOOTNOTE, and BANNER as optional extensions,
that can reasonably default to a 'goto HREF'. No statement in the
standard, and no 'absolutely mandatory extension' to the browsers
required. Links with REL=INCLUDE, FOOTNOTE, and BANNER will look
weird at first but all browsers will support them with no special
effort, and no need to define any special 'link behavior stylesheet',

If this is too much for us to stomach, we can leave these out and
leave in only those links that default to 'goto (HREF)' without
this hack.

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