Forward and reverse link relationships

The @rel=”nofollow”@ attribute name-value pair prompted me to re-examine what link relationships really are. I found @rel=”nofollow”@ to be an exceedingly ugly hack. And I found reverse link relationships to be as exceedingly wonderful.

h3. Forward and reverse links
The @rel@ attribute describes a _forward link_. A forward link indicates that the document referenced has a special meaning to the document you are viewing. The HTML 4.01 specifcation has this to say about @rel@:
bq. rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.
Let’s consider the document
bc. Which can be read as:
bq. The referenced document author.html contains author information for the current document; story.html.
h3. rel=”nofollow”
Now that you know what a forward link is, I can tell you why @rel=”nofollow”@ is so exceedingly ugly. Example:
bc. Text
With the w3c definiton of @rel@, read as:
bq. The referenced document contains “nofollow” information for the current document.
Which doesn’t make sense at all. What is the “nofollow” relationship? With @rel=”nofollow”@, search engines, and some high-profile bloggers have introduced the concept of processing instructions into the link relationship. If we reread my example nofollow link as it is being treated by the search engines we get:
bq. A User Agent should not follow the link to, or index it.
This is so 1995, and no different from @

@, @@ or any other past www atrocity. If one wanted to introduce the idea of a link being untrusted, one should have said just that: The following link is untrusted:
bc. Text
h3. Reverse link relationships
Oh, these are wonderful. Let’s read the “HTML 4.01 definition:”:
bq. rev = link-types
This attribute is used to describe a reverse link from the anchor specified by the href attribute to the current document. The value of this attribute is a space-separated list of link types.
If we have two documents, a.html and b.html, that are part of a sequence of documents (such as the archetypal weblog entries), a.html could contain:
bc. And b.html could contain
bc. Not only that, “b.html” could also indicate that it indeed _is_ the “next” document for “a.html” by adding this:
bc. Read as:
bq. This document is the “next” document for the document a.html.
However, using previous and next examples aren’t all that useful, since we already have previous and next forward link relationships. If we instead look at search results, it starts making sense. Imagine that you have written an entry about link relationships in HTML, and someone searching Google for link relationships and html found your document and visited it. Let’s also assert that your weblog system is able to find and store incoming links from Google. You could then add something like this:
Which can be read as:
bq. The current document is a search result for the Google search query linked to in the @href@ attribute.
Another example, which perhaps may be easier for weblogs to add, is for Pingbacks and TrackBacks. Usually, anyone who’s linking to your entries is writing something related to your entry, and if the document is doing this, you can add:
I’m quite confident there are plenty more uses for reverse relationships than these two examples. Find them. Use them.

Leave a comment


  1. Sure, I like the rev relationship. One useful application would be to confirm a rel relationship.
    In my opinion, the nofollow link type isn’t that bad wrt the HTML standard. I agree, however, that the link type name nofollow is a poor choice. I’d rather call it irrelevant.
    “The referenced document spam.html contains irrelevant information for the current document; story.html.”

  2. Jim

     /  2005-10-10

    Håkon, that would be infeasible to use correctly. For instance, many websites attach a rel=”nofollow” link to all user submitted links. These websites have no idea whether or not the link is irrelevant, in fact they usually *are* relevant, so your suggestion would mislabel lots of things. The untrusted value, on the other hand, could be applied without this problem.