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

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

Craig Hubley writes:
>
> > 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 ?

As I said, I am not convinced that this list is needed soon,
but I'd like to hear from others in the group. I do not
agree that these do not define a relationship, and I do agree
that they do define the nature of the documents.
>
> > 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.

I agree that the "Sequence" and "Hierarchy" relationships for the
core of the list. It should be noted that there is no requirement
that the HREF associated with these REL values should not be
cgi-bin scripts -- that's how we do our NAVIGATE relationship now.
>
> This is a different situation than the 'informational' link roles which
> imply no behavior beyond the standard 'goto (HREF)' of an <A ...> tag.

Well, we have yet to see what behaviour a clever UA developer might
imply from what you are categorizing as "informational" relationships.
>
> 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.

OK, but I want to be sure that we don't go too far in specifying
expected behaviour. As Larry pointed out recently, with respect to
some of the semantic markup, we need to leave the door open for
UA developers to address the needs of their expected user community.
So, I am in favor of providing hints, even strong hints, but I don't
want to restrict UA developers.
>
> 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 ?

For NEXT, PREVIOUS, PARENT, etc, I think that we need to be clear that
the expected behaviour is a "goto", but I don't want to specify that
a UA must include an icon on a toolbar, or the design of the icon,
or the design of the toolbar. I imagine that some authors will
want to develop their own toobars to include in a BANNER element.
I also imagine that some authors will want to place icons (and
alternate text strings) at the top and/or bottom of their documents.
>
> LEVELS OF LINKAGE
>
> 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.

No! Even if the anchor leads to an explicit target and acts only as
a "goto", there is still potential for creative user interface design.

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

Those are built into the browser. If/When UAs provide other types
of similar functionality -- which rely on the browser's internal
record of history or user preferences -- the HTML spec will not
have to change to accomodate these features.
>
> 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.

Instead? When we use a <LINK REL=NEXT we still have to hardwire the
URL of the next document. Even if we were to rely on some external
agent to resolve the meaning of NEXT, we would have to hardwire a
cgi-bin URL that could resolve on the server side. I don't understand
how we could avoid specifying a URL.
>
> 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.

While a "goto" is part of the behaviour expected when a link is activated,
there are other behaviours which might be interpreted and acted upon.
Adding toolbar icons for example. Another example which was mentioned
recently (I forget who) had the UA treating DEFINITION links specially
-- if more than one identical DEFINITION anchors were discovered, then
highlight only the first instance or at least subdue the highlighting
of subsequent instances.
>
> 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'.

I certainly expect that authors will have to design for the lowest
common denominator until UAs catch up. We saw this when we were
developing SCO's online doc and provided alternate mechanisms
so that lynx users, for example, would still be able to use
our online doc.
>
> 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.

Wrong! Unless you don't consider the user interface to be behaviour.
>
>
> I have separately posted a detailed commentary on Murray's list of values,
> which discusses the implications of the 'user agent behaviors' in detail.

I'll reply to that mail soon.
>
> 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.

That works for me. I look forward to reading what the rest of the group
has to say on this subject. The more important issue, for me, is to
define the list and identify specific and potential UA behaviour.

Murray

===========================================================================
---------------------------------------------------------------------------
Murray C. Maloney Internet: murray@sco.com
Technical Publications Writer/Architect Uucp: ...uunet!sco!murray
SCO Canada, Inc. My Phone: (416) 960-4031
130 Bloor Street West, 10th Floor Fax: (416) 922-2704
Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937
===========================================================================
Disclaimer: I'm speaking for myself. 'T ain't nobody else to blame but me.
---------------------------------------------------------------------------
Sponsor member of Davenport Group Member of IETF HTML Working Group
===========================================================================