This is just a last moment idea inspired by the movie Starship Troopers which flashed in to my mind a couple of days ago as I was thinking about Jetpacks for the Jetpack for Learning Design Challenge. It is primarily a Microformat/Link Type proposal for rel-info with some ideas and prototypes demonstrating how it could be used.

Abstract

When you are reading something on the web there are usually pages which exist elsewhere on the web that would provide background information, and further reading if you desired to dig deeper into the subject(s) you are reading about. Sometimes some of those pages are linked to from the article you are on, but often the link wouldn't make sense in the context of the content, and using a link tag isn't very useful to a user, so the link is not made.

I propose a rel-info link type, even if just as a Microformat, for 'a' and 'link' tags to provide a link to context-sensitive information.

With rel-info a user can read more about the Movie that was discussed at Netflix or IMDB easily for example, because the publisher (or a script the user subscribes to, more on this later) provided a rel-info link which the user can easily find and follow with a Jetpack, Firefox extension, or some other browser extension.

Proposal

When rel-info links are provided on a page browser extensions can easily extract them from the page, which can lead to a large number of use cases, of which I am sure I have only just scratched the surface. There is another side to this coin however which is that there are a large number of ways that rel-info links might be added to a page.

Let's explore the latter case, first the person who published the page could add rel-info links, but then browser extensions could add rel-info links, they could also search for and remove rel-info links. A user could subscribe to a person's or institution's suggestion feed or script which adds and/or removes rel-info links to pages, along with using a AI based browser extensions to add rel-info links.

When the rel-info links are going to be consumed there are some other interesting possibilities, for example a browser extension could filter the links by a HTML 5 'data-topic' attribute by keeping a list of topics that the user dislikes or likes, the domain could also be used for filtering. A browser extension could allow the user to mark pages as read so that they are removed from pages in the future as another example.

Prototypes

To test this link type out with a Jetpack I first had to add it to some pages, so I decided to write a couple of UserScripts to do this demonstrating how they can be dynamically added to pages by anyone even users themselves. The first userscript was to add the rel-info link type to IMDB links, and another to add the rel-info link type to Wikipedia links.

If you install the above UserScripts then you should find rel="info" or rel="... info" on your IMDB and Wikipedia links. Once you have done that you can check out and install the "Would You Like To Know More?" Jetpack. This is a slidebar Jetpack, and when you open this slidebar the focused tab is then scanned for rel-info links, if any are found then they are displayed in a list for you to choose from, if you click one of the provided links a new tab will be opened for the new page.

These UserScripts and the Jetpack take advantage of HTML 5 'data-' attributes, by adding a 'data-source' attribute to the rel-info links added on the userscript side, which the jetpack was written to check for and display if found. This is an example of how HTML 5 'data-' attributes can be used with the rel-info link type which I propose to create more interesting results.

I just read an interesting comment by one of the fieriest rev=canonical opponents Sam Johnson where he explains his confusion here, by saying:

I'm surprised the rev=canonical guys are still banging on about this... nobody outside of the web developer community has a good word to say about it and it's been universally criticised by the standards community (with good reason).

rev=canonical is saying "I'm the canonical URL and that URL over there points at me". That means it must only ever be used on the canonical URL itself - too bad for an infinite number of potential permutations. Then there's the likes of Matt Cutts pointing out that one should give, not take, canonical-ness but Chris Shiflett (one of the primary promoters) foolishly dismisses this feedback as "irrelevant". Mark Nottingham is more direct in Counting the ways that rev="canonical" hurts the Web but the rev=canonical fanboys cite this as "evidence that those writing the standards are going off track".

I suggest rel="shortlink" as an unambiguous solution to this fiasco - the short[_- ]?ur[il] option has more permutations than can easily be counted and delivers no additional value.

In order to discourage people from supporting many variations I'm now serving up warnings and errors when rev=canonical and rel=short*ur? are discovered at http://rel-shortlink.appspot.com/.

Sam

Well that is wrong and here is my response:

[More]

Well I am very excited to write this post, but I concede if the title did not peak your interest this may be as exciting as watching grass grow. If you are confused at all at this point, I should mention that there has been a lot going on that has lead up to my post, so I'm going to post a bunch of links in chronological order below before getting in to my thoughts, so that we can insure you are on my wavelength.

Timeline

1. 2005-12-??: Link Relationships - Web Authoring Statistics by Google.
2. 2006-01-04: SEO advice: url canonicalization by Matt Cutts.
3. 2006-06-05: [whatwg] Where did the "rev" attribute go? by Ian Hickson.
4. 2008-05-02: Domain Canonicalization by Nathan Buggia.
5. 2008-08-20: The Difference Between REL and REV attributes of the A Tag (or REL vs. REV) by Erik Vold.
6. 2008-11-18: [whatwg] Absent rev? by Ian Hickson.
7. 2008-11-30: URL Referrer Tracking by Nathan Buggia.
8. 2009-02-12: Partnering to help solve duplicate content issues by Nathan Buggia.
9. 2009-02-12: Specify your canonical by Joachim Kupke and Maile Ohye.
10. 2009-02-12: Fighting Duplication: Adding more arrows to your quiver by Priyank Garg.
11. 2009-03-11: The Rev Attribute, Link Types, and Vote Links Explained by Erik Vold.
12. 2009-03-17: How To Use The Rev Attribute by Erik Vold.
13. 2009-04-01: Short URL Auto-Discovery by Robert Spychala.
14. 2009-04-02: DiggBar Launches Today! by Kevin Rose.
15. 2009-04-03: on url shorteners by Joshua Schachter.
16. 2009-04-03: URL Shortening Hinting by Kellan Elliott-McCrea.
17. 2009-04-09: Google Juice & Page Views: Or How I Learned to Stop Worrying and Love the DiggBar by John Quinn.
18. 2009-04-10: Save the Internet with rev="canonical" by Chris Shiflett.
19. 2009-04-11: A rev="canonical" Rebuttal by Ben Ramsey.
20. 2009-04-11: rev="canonical": DiggBar outrage causes bad ideas to come out of the wood work by Dare Obasanjo.
21. 2009-04-11: Summarizing My rev="canonical" Argument by Ben Ramsey.
22. 2009-04-11: A rev="canonical" HTTP Header by Chris Shiflett.
23. 2009-04-11: rev=canonical bookmarklet and designing shorter URLs by Simon Willison.
24. 2009-04-11: Revving up by Jeremy Keith.
25. 2009-04-12: RevCanonial blog turns 10! by Kellan Elliott-McCrea.
26. 2009-04-12: rev=canonical considered harmful (complete with sensible solution) by Sam Johnston.
27. 2009-04-12: Specifying rev="canonical" With HTTP by Ben Ramsey.
28. 2009-04-13: Introducing rel="shortlink" - a better alternative to URL shorteners by Sam Johnston.
29. 2009-04-13/14: I (used to) like rev="canonical" by Leslie Michael.
30. 2009-04-14: rev=canonical by Anne van Kesteren.
31. 2009-04-14: Rev-canonical should be handled with care by Ciaran McNulty.
32. 2009-04-14: Counting the ways that rev="canonical" hurts the Web by Mark Nottingham.
33. 2009-04-15: (Yet) Another DiggBar Update by John Quinn.

My Thoughts

[More]

Rev Attribute

The html rev attribute in my opinion is underused and incredibly useful. In short the rev attribute is the reverse of the rel attribute. Here are the HTML 4.01 specification definitions:

• rel: 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.
• rev: 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.

A few months ago I wrote about the difference between the rev and rel attribute where I give an example which may help, and there is also a good example here.

Link Types

Link types are the values that can be used in the rel and rev attributes. Some link types are old, some are new, some are microformats, others are used by search engine bots. This is the HTML 4.01 list of link types, and this is the HTML 5 draft list of link types.

Some of the link types added to the HTML 5 specification are: archives, author, external, feed, first, and many others. Some of the link types removed are: start, chapter, section, subsection, and a few others.

The external and nofollow link types were also added to the HTML 5 specification which have been widely used for some time now in the rel attribute for SEO purposes. The tag link type was the better defined rel="tag" microformat before it was added to the HTML spec, however I expect and hope the microformat specification will continue. The tag link type was created at Technorati, which they describe here, and this is how it was created.

Vote Links

The Vote Links microformat are rev attribute values that I hope will become a link type in some future HTML specification. These are three values described by the Vote Links microformat, they are:

• vote-for: Represents approval.
• vote-abstain: Represents abstention or indifference.
• vote-against: Represents disapproval.

Currently I always rel="external nofollow" on any link that I will rev="vote-against", and rel="external" any link that I rev="vote-for" atleast once, which covers 75% of my links. But there are other links which I want to be more specific about, and for me that is where the Vote Links microformat comes in handy, because I can vote-for a link that I also nofollow. For example, I usually nofollow my links to Wikipedia (becuase it has so much Page Rank already) and use the vote-for microformat to show my support.

Conclusions

1. The rev attribute has been widely misunderstood and misued, but it is very useful.
2. There is a dramatic difference in the link types defined in the HTML 4 specification and the HTML 5 specification draft, but even some of the depricated link types appear useful to me.
3. The rev attribute is not in the HTML 5 specification draft, which is like removing the yang from a yin-yang, and I have not found a good reason for it, only a few hints which reinforce my belief that it is not good idea.
4. Vote Links rock!
5. Between the HTML specification chaos and Microformats, this is the time where we all get to decide what we want to embrace, and let the HTML specification follow our lead.

I'm still not sure if I'm a fan of all of the microformats that I have come across so far. But I can tell you that I am a huge fan of the VoteLinks microformat, because I think there is a huge need for them in SEO arena.

Currently search engines like Google, Yahoo, and that other search engine (made by the same company that makes that crappy browser) all primary rely on PageRank, which determines the importance of a document by considering the importance of the documents that link to it. In PageRank, every link is valuable, except those links that use the nofollow link type (ie: any link without the nofollow link type is considered an endorsement). PageRank does not consider the possibility that document A might want to have a vote on document B's calculated importance, besides just the option of endorsing document B.

Enter the VoteLinks microformat. With this specification, website masters can now specify links on their web documents as votes for or against other web documents. You can also abstain from voting, ofcourse.

For example, you may have noticed that in my second paragraph I was taking a shots at the Microsoft Corporation (which I love to do) and if you look at the html markup, then you will notice that those links are votes against Live Search and Internet Explorer. So now I'm telling any user agent that visits this document that this document is a vote against those Microsoft products. This document is also a vote for some wikipedia articles, Google, Yahoo, and the VoteLinks microformat. That's a lot of knowledge that spiders can gain because of this markup, hopefully the search engine spiders start considering this microformat as a factor soon..

Anyhow, if you want to start using the VoteLinks microformat now, all you need to do is insert the following values into the rev attribute of your html anchor tags:

• vote-for: This signals that the current document is a vote for the href url of the anchor tag.
• vote-against: This signals that the current document is a vote against the href url of the anchor tag.
• vote-abstain: This signals that the current document is indifferent to the href url of the anchor tag.

If you are concerned with using the target attribute when using document type definitions for which the target attribute is not valid, and will thus throw validation errors. Then I have written a microformat safe improved version of the unobtrusive javascript written here, and also found (slightly improved) here.

Here it is:

With this function, all you need to do is call the externalLinks() function when the page loads and all of the anchor tags with a href value, without an existing target attribute, and that includes the string "external" somewhere in the rel attribute will be given the target="_blank" attribute+value pair.

PageRank is built on links, so search engine optimization is centered around them, and people link to the entities that they support. But many times, I see people increasing their own bounce rate by linking to an external page they support without using the target="_blank" attribute+value pair on the anchor tag.

This especially does not make sense most of the time, because most of the time, the external link is really a side note to the website and webpage at hand. So, using target="_blank", which forces the link to open in a new tab or window, is exactly what you should want, for the simple reason that it makes sense, and that it will reduce your bounce rate.

Don't be a fool, use target="_blank"!

If you want to create an html tag in JavaScript on the fly, the good way (ie: without using document.write and innerHTML). Then this is how you do it, use:

Where 'tagName' is the tag name (for example: a, script, style, p, h1, h2, h3, input, select, etc...). This will create a tag node that you can then attach to the DOM tree of your document with the following functions:

• appendChild()
• insertBefore()
• replaceChild()