W3C home > Mailing lists > Public > www-html@w3.org > November 2001

Semantics of <link rel="next">

From: Ben Bucksch <ben.bucksch.news@beonex.com>
Date: Sun, 11 Nov 2001 21:04:26 +0100
Message-ID: <3BEED9CA.5030606@beonex.com>
To: www-html@w3.org
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

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

The example, however, is

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


> 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


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

  2.4. Hypertext links in HTML - IETF Draft from 1996


>	 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 

> <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 Sunday, 11 November 2001 15:13:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:58 UTC