"Standard" values for the "rel" attribute of <link> and <a> have been proposed in at least four different documents (see the above URL). These documents sometimes conflict with each other and are confusing. I'm working on a draft document that collates all link types still useful (i.e., eliminating "banner") and defines which are equivalent to which; when I've finished, I'll attach it here for discussion. We need this to resolve some UI problems which really hinge on which types we recognize and how.

We should start with the IETF WebDAV relrev draft and go from there, we may want to ask that working group for a stamp of approval too. Moving to Documentation

I disagree. We should start with the current link toolbar implementation and go from there. We already started with various "official" specs, recommendations, or contributed specs three years ago with bug 2800. Then we debated them, and eventually implemented something. Please don't do an end run around all this work just because you disagree with some of the mappings. If we want documentation, I'll be happy to write up a "guide to using LINK" that corresponds to this implementation. If you want a spec, I'll copy-and-paste the switch statement that maps REL values to link types and reformat for non-programmers.

Tim, I think our current implementation could use a little work-it's regressed a bit since the most detailed spec was worked out in 87428. Anyway, I've attached a draft for comment; I'll be announcing it on the newsgroups shortly for discussion.

(sorry about the spam, I had the dependencies hooked up backwards, and bugzilla won't let you change that in one step :( )

I am nost confused about what Next means in a hierarchy (same parent of flattened)? Will write a mail to w3c and post link here. IMO, it is very important that we do this stuff right. Ad-hoc implementation will lead to the same mess we had with HTML. In other words, this bug is very important IMO. I agree that we should get IETF and or w3c on the hook, if possible.

MY post about "next": <http://lists.w3.org/Archives/Public/www-html/2001Nov/0006.html> > We should start with the IETF WebDAV relrev draft and go from there In the case of "next", it is by far the most well-thought. I wonder, why the authors of the HTML spec appearently completely ignored it.

Also compare bug 109467.

Does this bug cover a UI spec for how the toolbar should work, or just documenting what all the link types should mean and how they should be used in an html document? I think we should probably have separate bugs for these separate issues. Bugs like bug 102990, bug 103417, bug 103429 and bug 103459 can't really be resolved without a unified UI spec to work towards. However, they don't really impact the meaning of the link types, which seems to be what this bug is about. So I think they're really separate issues. If I get a chance I'd like to write up a possible UI spec; at the moment, though, I'm not sure whether to attach it to this bug or to file a new one for it. Thoughts?

brainstorming a bit: I was thinking about rel vs rev attributes, and wondering if it made any sense for mozilla to cache this data in some fashion so that if Page_A claims to be a parent of Page_B then when you visit Page_B mozilla could indicate this in the links toolbar even if Page_B doesn't bother to tell you about the relationship. Page_A claiming rel relationship X to Page_B is equivilant to Page_B claiming rev relationship X to Page_A As an example of how this might work, suppose http://usenetarchive.example.com/ does not have any link relationships specified. However http://usenetarchive.example.com/comp.lang.perl.misc/ http://usenetarchive.example.com/comp.lang.perl.modules/ http://usenetarchive.example.com/comp.lang.perl.moderated/ each claim that http://usenetarchive.example.com/ is the parent page. Suppose you visit each of those three newsgroup pages, and mozilla caches the information that the homepage is a parent. Next time you visit the homepage, the links toolbar remembers that those three pages were children of the homepage, and now reflects those relationships even thought there is not meta information in the homepage itself. Pros: gets more leverage from incomplete link information gives user increased ease of access to related info like "what's related" functionality except that the mechanism does not impact privacy and requires explicit claims of relationship Cons: requires its own cache (with associated prefs, etc) potential performance issues potential for third party abuse. eg: /~fredsucks/ claims to be child of /~fred/ later, user visits /~fred/ and sees bad child potential for too much information. eg: every page in usenet archive lists homepage as parent user visits thousands of pages researching some issue user visits homepage links toolbar lists thousands of child pages *if* anyone thought this was worth doing, prefs could disable the feature and hopefully eliminate any performance issues. Perhaps the UI could distinguish between relationships which had been specified in the currently-viewed page and any relationships cached from other pages. Maybe the other pages' entries could be in italics or something. That along with a preference indicating what those italic entries were and giving a way to turn them off might go some way to reducing the impact of potential abuses. [x] enable links toolbar [x] hide toolbar when no links available [x] remember and display relationships between pages (these links will display in italics) [x] for any page, remember only the most recent [_25_] relationships specified in other documents That [_25_] would be a menu with a few reasonable values. does anyone see anything in the standards which would preclude such a function? It seems to me like a reasonable use of the available information which would benefit users. -matt

Foudn the following in WAI: "* Allow depth-first as well as breadth-first navigation." (<http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-nav-structure>, example techniques, 12.) It refers to document-internal navigator, but I found it interesting, because it suppotrs my view that "Next" may mean the first child or the next sibling (although there are childs), depending on content and user preference/mood.

If it were up to me I'd say that a "first child" could be indicated by <link rel="child next"> and a "next sibling" could be indicated just by <link rel="next">. If the "child next" link is first in document order, it will be preferred over the "next" from the POV of populating the "Next" button. Of course, that would completely exclude use of the "next sibling" link from the UI. Resolving that issue would require making the "next" and "previous" buttons (and "up", IMHO) work like "back" and "forward" - with little dropdown arrows next to them, and a menu.

I hope WHATWG is going to address this. Ian?

I guess it could; if it does it'll be at: http://whatwg.org/specs/web-apps/current-work/#link-types

No activity in 10 years. Closing. Specs https://html.spec.whatwg.org/multipage/semantics.html#linkTypes http://www.w3.org/TR/html5/links.html#linkTypes MDN https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types