The WHATWG Blog

Please leave your sense of logic at the door, thanks!

The Road to HTML 5: Link Relations

by Mark Pilgrim, Google in Tutorials

Welcome back to my semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.

The feature of the day is link relations.

In this article:

What are link relations?

Regular links (<a href>) simply point to another page. Link relations are a way to explain why you're pointing to another page. They finish the sentence "I'm pointing to this other page because..."

And so on. HTML 5 breaks link relations into two categories:

Two categories of links can be created using the link element. Links to external resources are links to resources that are to be used to augment the current document, and hyperlink links are links to other documents. ...

The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type.

Of the examples I just gave, only the first (rel=stylesheet) is a link to an external resource. The rest are hyperlinks to other documents. You may wish to follow those links, or you may not, but they're not required in order to view the current page.

Common link relations include <link rel=stylesheet> (for importing CSS rules) and <link rel=alternate type=application/atom+xml> (for Atom feed autodiscovery). HTML 4 defines several link relations; others have been defined by the microformats community. HTML 5 attempts to consolidate all the known link relations, clean up their definitions (if necessary), and then provide a central registry for future proposals.

How can I use link relations?

Most often, link relations are seen on <link> elements within the <head> of a page. Some link relations can also be used on <a> elements, but this is uncommon even when allowed. HTML 5 also allows some relations on <area> elements, but this is even less common. (HTML 4 did not allow a rel attribute on <area> elements.)

See the full chart of link relations to check where you can use specific rel values.

Changes to link relations since HTML 4

Link relations were added to the HTML 5 spec in November 2006. (Back then the spec was still called "Web Applications 1.0.") r319 kicked off a flurry of rel-related activity. The original additions were primarily based on research of existing web content in December 2005, using Google's cache of the web at the time. Since then, other relations have been added, and a few have been dropped.

rel=alternate

rel=alternate has always been a strange hybrid of use cases, even in HTML 4. In HTML 5, its definition has been clarified and extended to more accurately describe existing web content. For example, using rel=alternate in conjunction with the type attribute indicates the same content in another format. Using rel=alternate in conjunction with type=application/rss+xml or type=application/atom+xml indicates an RSS or Atom feed, respectively.

HTML 5 also puts to rest a long-standing confusion about how to link to translations of documents. HTML 4 says to use the lang attribute in conjunction with rel=alternate to specify the language of the linked document, but this is incorrect. The HTML 4 Errata lists four outright errors in the HTML 4 spec (along with several editorial nits); one of these outright errors is how to specify the language of a document linked with rel=alternate (The correct way, described in the HTML 4 Errata and now in HTML 5, is to use the hreflang attribute.) Unfortunately, these errata were never re-integrated into the HTML 4 spec, because no one in the W3C HTML Working Group was working on HTML anymore.

rel=archives

New in HTML 5

rel=archives "indicates that the referenced document describes a collection of records, documents, or other materials of historical interest. A blog's index page could link to an index of the blog's past posts with rel="archives"."

rel=author (and the removal of the rev attribute)

New in HTML 5

rel=author is used to link to information about the author of the page. This can be a mailto: address, though it doesn't have to be. It could simply link to a contact form or "about the author" page.

rel=author is equivalent to the rev=made link relation defined in HTML 3.2. Despite popular belief, HTML 4 does not include rev=made, effectively obsoleting it. (You can search the entire spec for the word "made" if you don't believe me.)

Given that rev=made was the only significant non-typo usage of the rev attribute, HTML 5 added rel=author to make up for the loss of rev=made in HTML 4, thus allowing the working group to obsolete the rev attribute altogether. Other than the un/semi/sortof-documented rev=made value, people typo the "rev" attribute more often than they intentionally use it, which suggests that the world would be better off if validators could flag it as non-conforming.

The decision to drop the rev attribute seems especially controversial. The same question flares up again and again on the working group's mailing list: "what happened to the rev attribute?" But in the face of almost-universal misunderstanding (among people who try to use it) and apathy (among everyone else), no one has ever made a convincing case for keeping it that didn't boil down to "I wish the world were different." Hey, so do I, man. So do I.

rel=external

New in HTML 5

rel=external "indicates that the link is leading to a document that is not part of the site that the current document forms a part of." I believe it was first popularized by WordPress, which uses it on links left by commenters. I could not find any discussion of it in the HTML working group mailing list archives. Both its existence and its definition appear to be entirely uncontroversial.

rel=feed?

New in HTML 5, but may not be long for this world

rel=feed "indicates that the referenced document is a syndication feed." Right away, you're thinking, "Hey, I thought you were supposed to use rel=alternate type=application/atom+xml to indicate that the referenced document is a syndication feed." In fact, that's what everyone does, and that's what all browsers support. Firefox 3 is the only browser that supports rel=feed. (It also supports rel=alternate type=application/atom+xml.) The rel=feed variant was proposed in the Atom working group in 2005 and somehow found its way into HTML 5. Just yesterday, I was discussing whether HTML 5 should drop rel=feed due to lack of browser implementation and complete and utter lack of author awareness.

rel=first, last, prev, next, and up

HTML 4 defined rel=start, rel=prev, and rel=next to define relations between pages that are part of a series (like chapters of a book, or even posts on a blog). The only one that was ever used correctly was rel=next. People used rel=previous instead of rel=prev; they used rel=begin and rel=first instead of rel=start; they used rel=end instead of rel=last. Oh, and -- all by themselves -- they made up rel=up to point to a "parent" page.

HTML 5 includes rel=first, which was the most variation of the different ways to say "first page in a series." (rel=start is a non-conforming synonym, for backward compatibility.) Also rel=prev and rel=next, just like HTML 4 (but mentioning rel=previous for back-compat). It also adds rel=last (the last in a series, mirroring rel=first) and rel=up.

The best way to think of rel=up is to look at your breadcrumb navigation (or at least imagine it). Your home page is probably the first page in your breadcrumbs, and the current page is at the tail end. rel=up points to the next-to-the-last page in the breadcrumbs.

rel=icon

New in HTML 5

rel=icon is the second most popular link relation, after rel=stylesheet. It is usually found together with shortcut, like so:

<link rel="shortcut icon" href="/favicon.ico">

All major browsers support this usage to associate a small icon with the page (usually displayed in the browser's location bar next to the URL).

Also new in HTML 5: the sizes attribute can be used in conjunction with the icon relationship to indicate the size of the referenced icon. [sizes example]

rel=license

New in HTML 5

rel=license was invented by the microformats community. It "indicates that the referenced document provides the copyright license terms under which the current document is provided."

rel=nofollow

New in HTML 5

rel=nofollow "indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages." It was invented by Google and standardized within the microformats community. The thinking was that if "nofollow" links did not pass on PageRank, spammers would give up trying to post spam comments on weblogs. That didn't happen, but rel=nofollow persists. Many popular blogging systems default to adding rel=nofollow to links added by commenters.

rel=noreferrer

New in HTML 5

rel=noreferrer "indicates that the no referrer information is to be leaked when following the link." No browser currently supports this. [rel=noreferrer test case]

rel=pingback

New in HTML 5

rel=pingback specifies the address of a "pingback" server. As explained in the Pingback specification, "The pingback system is a way for a blog to be automatically notified when other Web sites link to it. ... It enables reverse linking -- a way of going back up a chain of links rather than merely drilling down."

Blogging systems, notably WordPress, implement the pingback mechanism to notify authors that you have linked to them when creating a new blog post.

rel=prefetch

New in HTML 5

rel=prefetch "indicates that preemptively fetching and caching the specified resource is likely to be beneficial, as it is highly likely that the user will require this resource." Search engines sometimes add <link rel=prefetch href="URL of top search result"> to the search results page if they feel that the top result is wildly more popular than any other. For example: using Firefox, search Google for CNN; view source; search for the keyword "prefetch".

Mozilla Firefox is the only current browser that supports rel=prefetch.

New in HTML 5

rel=search "indicates that the referenced document provides an interface specifically for searching the document and its related resources." Specifically, if you want rel=search to do anything useful, it should point to an OpenSearch document that describes how a browser could construct a URL to search the current site for a given keyword.

OpenSearch (and rel=search links that point to OpenSearch description documents) is supported in Microsoft Internet Explorer since version 7 and Mozilla Firefox since version 2.

rel=sidebar

New in HTML 5

rel=sidebar "indicates that the referenced document, if retrieved, is intended to be shown in a secondary browsing context (if possible), instead of in the current browsing context." What does that mean? In Opera and Mozilla Firefox, it means "when I click this link, prompt the user to create a bookmark that, when selected from the Bookmarks menu, opens the linked document in a browser sidebar." (Opera actually calls it the "panel" instead of the "sidebar.")

Internet Explorer, Safari, and Chrome ignore rel=sidebar and just treat it as a regular link. [rel=sidebar test case]

rel=tag

New in HTML 5

rel=tag "indicates that the tag that the referenced document represents applies to the current document." Marking up "tags" (category keywords) with the rel attribute was invented by Technorati to help them categorize blog posts. Early blogs and tutorials thus referred to them as "Technorati tags." (You read that right: a commercial company convinced the entire world to add metadata that made the company's job easier. Nice work if you can get it!) The syntax was later standardized within the microformats community, where it was simply called "rel=tag".

Most blogging systems that allow associating categories, keywords, or tags with individual posts will mark them up with rel=tag links. Browsers do not do anything special with them, but they're really designed for search engines to use as a signal of what the page is about.

rel=contact

rel=contact was briefly part of HTML 5, but r1711 removed it because it conflicted with the same-named XFN relationship.

Extending rel even further

There seems to be an infinite supply of ideas for new link relations. In an attempt to prevent people from just making shit up, the WHATWG maintains a registry of proposed rel values and defines the process for getting them accepted.

↔

39 Responses to “The Road to HTML 5: Link Relations”

  2. There’s been a kerfuffle about rev=canonical lately. What’s the best practice for people who wish to do this, when rev is no longer in the spec?

  3. @bruce: rel=shortlink should be used instead of stepping on canonical’s toes.

  5. rel=shorturl and rel="alternate short" have been floated. They’re both better solutions than rev=canonical. What if the URL you’re viewing isn’t the canonical URL for that resource? There are a myriad of good reasons why it might not be. It also introduces confusion, because it is one character away from rel=canonical and mixing the two up could have disastrous effects.

  7. Is there any kind of ‘official’ listing of all the reasons for linking to another page? Of course, such a list would never be complete, but I’d sure like to see it.

  9. Re: rev="canonical"

    Consider this circumstance:

    There is an online store, and depending on which actions the user takes when browsing/searching they could end up on the same product page with very different URLs. (All of the possible URLs contain information not actually used by the script to display products, they are just there for the benefit of search engine rankings). For example:

    /product/12345 (canonical URL)

    /product/12345/Band-X/Album-Name (came from a link on that artist’s page where it is inexpensive to include the band and album in the URL)

    /product/12345/Band-X/Album-Name/Genre (etc.)

    The “canonical” URL just happens to be shorter than the others, so rel=shortlink makes (if not entirely semantic) sense in this example, but what if the canonical URL was longer?

    I think rev=canonical/rel=shortlink describe two very different relationships, and one shouldn’t be used in the place of the other.

  10. Thanks for the advice on best practice alternative to rev=canonical.

    Reading this blog post, it occurred to me that I’m forever hearing the complaint “why is the ‘accessibility’ link always the last one on the page” (so people who need accessibility help, WCAG 2 policy, contact details for alternate formats can have a terrible job finding the right link).

    The “bad old days” meant that helpful developers would give an accesskey attribute to that link (which were undiscoverable or conflicted with their assistive technologies).

    What about putting rel=”accessibility” in the header, pointing to the “accessibility page” (or on the actual link; I haven’t thought this through deeply). That way, assistive technologies could offer a standardised command to go to the site’s accessibility page by following the rel=accessibility link.

    Or am I barking?

  12. I’m not sure I agree that the claimed “thinking” for rel=nofollow is actually accurate to the original intention. Some people may have jumped to conclusions and glommed onto that way of thinking initially, but it always seemed clear to me that the primary benefactor of the change was search engines (after all, who invented and promoted it?), making it a heckuva lot easier for them to remove spammed results from their calculations. Normal users saw no benefit except indirectly through better search results. I would be astounded if anyone who actually gave it a handful of minutes of thought to the problem expected it would reduce comment spam by even a hair any time in the near future (measured as, at a minimum, a decade, and probably longer).

  13. You read that right: a commercial company convinced the entire world to add metadata that made the company’s job easier. Nice work if you can get it!

    Equally true for rel=”nofollow”

  18. […] As many Web designers and developers know, HTML has been slowly evolving since it was introduced as a practical mark-up language for the Web in the early 1990’s. In fact, HTML has undergone exactly four major revisions, with the most recent revision taking place in 1997. Given that it has been more than 12 years since there has been any significant change to HTML, I read with great interest the latest post from Mike Pilgrim titled “The Road to HTML 5: Link Relations.” […]

  21. […] into the war between the two here; I’ll just focus on a specific development in the arena: link relations. There’s more to it than rel=stylesheet and rel=alternate. About a dozen […]

  22. My argument for keeping the @rev attribute has always been more than “I wish the world was different”, it boils down to:

    1) the confusion of @rev is dwarfed by the confusion of removing it in the long run.
    2) without @rev the number of values for @rel can grow quite large and will grow more confusion than it would have been to keep @rev, when a single value can be used for both @rev and @rel.
    3) in situations where a @rev value is simple to choose, choosing a @rel equivalent can cause debates. What @rel value would you purpose to replace @rev=canonical for instance?

  25. I’m sorry, but I just don’t see the big diff between rel=tag and rel=up. Sure rel=up defines and upper document and rel=tag defines a tag. But aren’t tags at upper level than the linking document? Won’t we see dozens and dozens of <link rel="tag up"/>s? I mean aren’t documents tagged as sub–documents of their parents? And who did think of that way to get tag names? It uses the right-most part of the URI; wich is the part of the hiercial part of IRIs after the last slash—and if the last character in the hiarchial part is slash, then that slash is removed. IMHO awful. The fragment identifier is left out, and the title attribute of the link element isn’t even mentioned. And if the tag is to be used without fetching the resource as the spec states; why not use the <meta name=tags content="foo, bar"> model?

  30. I took the road to HTML5. Thanks to you.
    Regarding rel=nofollow after some tests it seems this instruction (as some others noarchive, googleoff, etc.) is not respected by the Google Bot. So I moved them off.

  31. Note that rel=”shortcut icon” isn’t correct, use just shortcut=”icon”.

  33. @Philippe:

    Regarding rel=nofollow after some tests it seems this instruction … is not respected by the Google Bot.

    The “nofollow” attribute value is confusing and was not well chosen. The presence of rel=nofollow does not mean that the Googlebot will not follow the link. It will — after all, that is Google’s objective, to follow links and index the web. But it will not pass page rank from the linking site. So the Googlebot respects the intent of the attribute, which is the important thing. Perhaps it would have been better to call it rel=no-page-rank, but that might have been too Google-specific…

  34. Is it possible to detect the support of rel attribute by the browser? Specifically noreferrer – I want to link direct URL if the browser supports this attribute, or link intermediate page hiding referrer without the support.

  35. Jakub, no, there is no completely reliable way of detecting that. The only way that would be possible is by checking if the UA is one that is known to support it, or by monitoring the result of the user clicking other links marked as noreferrer. e.g. If the user clicks a link without noreferrer and another with noreferrer, and the Referer header is absent from the latter, then you can be more confident that the user’s browser supports it. You could then set a cooking to record the result. But note that such a technique may not be completely reliable or accurate.

  37. Hi,

    Apparently rel=up has been pulled out of the HTML5 specification and now triggers errors.

    Do you know why it was pulled?