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

I interpreted it,
the >next< page is that page, what corresponds the page with >prev< link.
For example:

first page (fo2.htm):
<LINK REL="next" HREF="foo.htm">
next page (foo.htm):
<LINK REL="prev" HREF="fo2.htm">

Later
Miklos Monostory
----------------------------------------
infoteam@fw.hu  |  http://infoteam.fw.hu
--------http://htmlinfo.fw.hu------------
----------------------------------------
----- Original Message -----
From: "Ben Bucksch" <ben.bucksch.news@beonex.com>
To: <www-html@w3.org>
Sent: Sunday, November 11, 2001 9:04 PM
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 Tuesday, 13 November 2001 09:38:27 UTC