RE: Semantics of <link rel="next">

I believe that "next" should simply be the next part of your content,
whatever follows from the current page.

If you have a series of chapters, just link to the section that follows
(sub-sections or next chapter), as if you were turning the pages of a book.

The idea of "next" is to guide the user through the information in a useful
manner, so I would do whatever works for your content.

Cheers, Dave

------------------------
 David Balch at FASSOC
david.balch@fassoc.co.uk
   www.fassoc.co.uk
------------------------

-----Original Message-----
From: www-html-request@w3.org [mailto:www-html-request@w3.org]On Behalf
Of Ben Bucksch
Sent: 11 November 2001 20:04
To: www-html@w3.org
Subject: Semantics of <link rel="next">


Trying to implement <link> tags for my website, I am very confused about
what "next" means.


  1. Problem

My site is a hierarchy. Trying to add the "next"/"prev"/"first"/"last"
links, I didn't know, which pages to use:

   1. Does Next go to the next sibling (node/page with the same parent)? or
   2. Is the whole hierarchy imaginary flattened and Next goes to the
      next page in that linear string of all pages, giving some kind of
      a (non-guided) tour through the whole site? or
   3. Are the semantics up to the author?


For example, if I am at the main page of Chapter 3 and press next, do I
get to the main page of Chapter 4 or to the first subpage of Chapter 3,
e.g. Chapter 3.1?

I'd argue for the first approach, and that's what I used in my
generator, but I can see advantages of the second one.

In any case, I think that it is important that the semantics are
identically across web-sites, because consistency is the whole point of
the <link> toolbar feature.


  2. Existing defintions


  2.1. HTML4

The HTML4 spec (also applicable for XHTML 1.0) just says
<http://www.w3.org/TR/REC-html40/types.html#type-links>

> *Next*
> Refers to the next document in a linear sequence of documents.
>
Unclear.

The example, however, is
<http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3>

><TITLE>Chapter 2</TITLE>
>  <LINK rel="Index" href="../index.html">
>  <LINK rel="Next"  href="Chapter3.html">
>  <LINK rel="Prev"  href="Chapter1.html">
>
This suggests (1), if there is a Chapter 2.1.


  2.2. HTML+

<http://www.w3.org/MarkUp/HTMLPlus/htmlplus_55.html>

> You can define a linear sequence through each of these subdocuments by
> including LINK elements with REL=NEXT and REL=PREVIOUS. This will
> allow readers to read through each part of the book in turn.

Unclear. (Esp. "each part in turn".)


  2.3. HTML3

<http://www.w3.org/MarkUp/html3/dochead.html>

> REL=Next
> The link references the next document to visit in a guided tour.
>

  2.4. Hypertext links in HTML - IETF Draft from 1996

<http://www.ics.uci.edu/~ejw/authoring/draft-ietf-html-relrev-00.txt>

>NEXT
>	 The NEXT relationship identifies the next document in an
>	 author-defined sequence of documents, such as a linear book.
>
Suggests (3)

The spec is the only one (later) mentioning hierarchies at all. It
specifies "sibling" for relationships as in (1). There's an interesting
example:

> <A REL="SIBLING NEXT" HREF="..." > next </A>

This sounds logical, but shifts the problem somewhat to the UA. Current
implementations behave unknown (and sometimes odd), if there is both a
"next" and a "sibling next" rel.

Section 6 cites an HTML 3.0 draft with "Hypertext Paths" or "Guided
Tours" similar to (2), defined in the parent node only and implying a
lot of logic in the UA. Not really useable.

To summarize, this spec considers all three cases (1, 2, 3) and is thus
IMO the best spec of all. Should be investigated further. No idea, why
there appearently haven't been subsequent revisions/specifications.


  3. Discussion


  3.1. Siblings

This method is most useful for sites/documents, which take the hierarchy
(and hyperlinking) to an extreme: Going deeper in the hierarchy is
optional and only useful, if more in-depth information to a certain
topic (page) is wanted by the reader. The parent is a summary of its childs.

In such a site, it makes completely sense to go to the next sibling
without reading the childs. Reading a certain child or all childs would
be an active decision of the reader, not the default one. Thus, Next
would point to the next sibling, not the first child.


  3.2. Flattened

I assume that First, Previous, Next, Last are all used consistently,
that they navigate through a linear set of pages (that set isn't
necessarily the whole site/document). I.e., if you press Previous often
enough, you end up at the First page, similar for Next/Last. If you
press Next, the new page's Previous is the old one, and vice versa. This
implies that, within that set of pages, First and Last always point to
the same pages.
I argue that everything else would severely confuse users, and rightly
so, i.e. is not wanted.

Now, if I really flatten the whole site, creating a linear tour through
the whole site and using that string as the "set of pages", I end up
with a First that is always identical to Start and a Last that always
points to the same random page that happens to be last in my string. In
other words, First and Last would be useless.

Note that while Next here creates a tour, it is not necessarily a
*guided* tour. If you do it most logical (generated), the tour goes
through the whole site, no matter how uninteresting the pages are.

OTOH, this interpretation makes a lot of sense for documents (broken up
into several HTML pages) with a structure of traditional books, which
are read linearily.


  3.3. Author-defined

Leaving the decision completely up to the author and specifying only
that "next" means, well, next, gives most room to create a sensible
guided tour, if approriate, or use the sibling approach, where the
author consideres that approach most appropriate for its content.

However, this approach has the severe disadvantage that it creates a lot
of inconsistency. It is hard to predict for the visitor, if he should
trust the author to create a nice guided tour, which he should follow,
or if the author generated the link, with variing quality as the result.

Since the whole point of the <link> element is to establish consistency
between sites, I don't think that this approach is good, at least not
when used alone.


  4. Suggestion


  4.1. Markup

Since all approaches make some sense, my suggestion is to support all of
them explicitly in the markup. I suggest

   1. "sibling next"
      to link to pages using the 1. approach
   2. "linear next"
      to link to pages using the 2. approach
   3. "guided next"
      to allow the author to define a sensical, guided tour through a
      (sub)set pf pages. The assumption is that the user starts as
      "guided first", reads the page, loads "guided next", reads and so
      forth until he finished reading "guided last".
   4. "custom next"
      to allow the author to use a scheme different from the above.

"next sibling" etc. could also work.

There is one problem with this syntax: Some UAs (e.g. current Mozilla)
will render a list of "guided" for each "guided next", "guided prev"
etc. link. This is unforunate. An da.hoc alternative is "guided-next",
but that wouldn't be recognized as "next".


  4.2. UAs

However, how to render that? (Of course, that should not be specified,
we should know that it is possible to render that sensibly and make
approriate suggestions to implementors.)

The title attribute doesn't help at all here. If I consider to follow a
tour, it is not sufficient to know the direct next stop. I need to know,
what I will see throughout the tour, which cannot be infered from the
direct next stop. In other words, the approach (or semantics) of the
Next/Prev/First/Last UI (usually buttons) in a particular case must be
clear to the user by simply looking at it.


  4.2.1. GUI

Maybe be following: There is a button "Next", with a right-pointing
arrow as icon. In addition, each approach listed above has its own icon,
which is shown before the arrow.

If there are several Next approaches used on the same page (e.g. a "next
sibling" *and* a "next guided"), the button also has a menu, which is
accessible by yet another icon (e.g. down arrow, to the right of the
button label) and which lists Next links of all used approaches, with
the corresponding approach icon and the |title|.
The button itself is mapped to the Next link of "best" available
approach. Guided is best, not sure about the ranking of the others.

If there is only one approach used, map the Next button to that link,
without any menu. The title attribute is the tooltip.

Probably should confused, but really isn't. The only disadvantage are
the many icons.

So, the user could always access Next by one click and know beforehand,
which semantics are used. He would also have access to alternative
approaches (and be clear about what is what), if the author added them.


  4.2.2. Text

The UA could just enumerate all links, prepending the |title| with "Next
Guided: ", "Next Sibling: " etc..



CCs on the whole thread appreciated.

Received on Monday, 12 November 2001 04:36:46 UTC