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

Murray Maloney (murray@sco.COM)
Tue, 16 May 95 17:11:54 EDT

Craig Hubley writes:
>
> I posted separately on treatment of nonstandard values, and whether or
> not it is important to define certain standard values within HTML itself.
> This post is confined to the implications of specific values as proposed
> by Murray and Dave, and includes notes on browser behavior for those REL
> values that appear to require that a behavior other than 'jump to (HREF)'
> be performed. It would be useful if we could confine this thread to the
> definition of specific REL values and detailed implications for browsers.

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
to be working w/o stylesheets today, I could argue that
no special behaviour is _required_ for it. And, since
BANNER is simply a special case of INCLUDE, I could argue
for removing it altogether. That leaves INCLUDE.

More comments follow....

>
> > 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]

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

> >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".

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.
>
>
> 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.

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
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.

These can be safely treated as "goto".
>
>
> 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.

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.

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

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.

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.
>
> > 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).

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.

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.

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.

>
>
> (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.

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.

Murray