The Road to HTML 5: Link Relations
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?
- How can I use link relations?
- Changes to link relations since HTML 4
- Extending rel even further
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..."
- ...it's a stylesheet containing CSS rules that your browser should apply to this document
- ...it's a feed that contains the same content as this page, but in a standard subscribable format
- ...it's a translation of this page into another language
- ...it's the same content as this page, but in PDF format
- ...it's the next chapter of an online book that this page is also a part of
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
See the full chart of link relations to check where you can use specific
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 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/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=alternateadded to HTML 5
- r485 defines how to use the
mediaattribute in conjunction with
- r1942 make the
titleattribute required for
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.)
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=authoradded to HTML 5
- WA1: rev attribute (and followup two years later)
- Where did the "rev" attribute go?
- Removing @rev
- Absent rev?
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.
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=feedadded to HTML 5
- r335: more thorough definition
- Autodiscovery paces
- Inferring rel="feed" from the media type
- PaceEntryMediatype (2, 3)
- IRC chat about browser compatibility and usage within existing web content (continued on next page)
rel=first, last, prev, next, and up
HTML 4 defined
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=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=next, just like HTML 4 (but mentioning
rel=previous for back-compat). It also adds
rel=last (the last in a series, mirroring
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=first/prev/next/lastadded to HTML 5
rel=upadded to HTML 5
- r1126 and r1127 make it clear that
rel=first/prev/next/lastrefer to any sequence of pages, not just a hierarchical structure.
- r1130 makes it legal to duplicate the
upkeyword in a single
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. [
- <link rel=icon width="" height=""> (initial proposal, later changed to
- Re: <link rel=icon width="" height="">
- <link rel=icon sizes=?> What if sizes is incorrect?
- The sizes="" attribute for rel=icon
rel=iconadded to HTML 5
- r1558 adds the
sizesattribute, and r1559 adds an example
- r1712 says that, if the browser decides that multiple icons are appropriate and equally desirable, the last one listed should be used.
- r1713 further explains how to determine precedence if multiple icons are listed.
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."
- real world semantics, the presentation that launched a thousand ships
- creative commons supports rel="license"
- rel="license" spec on microformats.org
rel=licenseadded to HTML 5
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.
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=noreferreradded to HTML 5
- no referer attrribute for <a>, same reason as ping - initial discussion of a mechanism for blocking referrer information on individual links
- several messages about a way to disable referer headers for links
- "I don't think that spelling the attribute "noreferer" is consistent. It should be "noreferrer"."
- "I'll switch to [no]referrer."
- r1950 extends
rel=noreferrerto also blow away the 'opener' when used with target=_blank
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=pingbackadded to HTML 5
- Pingback 1.0 specification
- WordPress Trackback Tutorial
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
- What improves Web applications? "A big plus point would be to prefetch the next page so it loads immediately the 'next' button is clicked."
rel=prefetchadded to HTML 5
- Link prefetching FAQ on Mozilla Developer Center
- test whether your browser supports
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.
rel=search links that point to OpenSearch description documents) is supported in Microsoft Internet Explorer since version 7 and Mozilla Firefox since version 2.
- OpenSearch: Autodiscovery in HTML/XHTML
rel=searchadded to HTML 5
- Creating OpenSearch plugins for Firefox
- Available search plugins for Firefox
- Search Providers for Microsoft Internet Explorer
- r484 adds a note about OpenSearch documents in particular
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=sidebaradded to HTML 5
- r668 revamps the definition based on the concept of a "secondary browsing context."
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-tag microformat specification
- rel-tag FAQ
rel=tagadded to HTML 5
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.
Very useful, thanks
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?
@bruce: rel=shortlink should be used instead of stepping on canonical’s toes.
Link for the “the Pingback specification” is broken.
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=canonicaland mixing the two up could have disastrous effects.
@bruce: use rel=shortlink
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.
@Milo: fixed the Pingback link, thanks.
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/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)
The “canonical” URL just happens to be shorter than the others, so
rel=shortlinkmakes (if not entirely semantic) sense in this example, but what if the canonical URL was longer?
rel=shortlinkdescribe two very different relationships, and one shouldn’t be used in the place of the other.
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?
[…] most recent Road to HTML5 blogpost is on the subject of link relations. To sum up in one sentence, link relations ‘explain why […]
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).
Equally true for rel=”nofollow”
It’s too much to use in html coding. Any easy way to deal with it?
I helped compile this list of known rel values (but am not responsible for subsequent changes).
+1 for rel=”accessibility” (doesn’t mean that I don’t think Bruce is barking, though).
[…] Pilgrim published an article about link relations in HTML 5 with more information about the rel attribute, which I found interesting; I had no idea that […]
[…] 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.” […]
[…] HTML5 mikor jössz már? De ha egyszer itt leszel, a következ?ket biztos hozod magaddal: The Road to HTML 5: Link Relations […]
[…] – in response to Mark Pilgrim’s overview of link relations in HTML5 Bruce Lawson suggests adding re=accessibility and Andy Mabbett implements it. Go […]
[…] 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 […]
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?
Remember rel=shorturl and rel=shortlink ARE NOT EQUIVALENT TO rev=canonical
How about rev=vote-for and rev=vote-against equivalents for @rel???
I’m sorry, but I just don’t see the big diff between
rel=updefines and document and
rel=tagdefines a tag. But aren’t tags at 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 ; 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
linkelement 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?
[…] The Road to HTML 5: Link Relations Sem comentários […]
[…] The WHATWG Blog » Blog Archive » The Road to HTML 5: Link Relations […]
[…] the markup to HTML5. (Includes addition of new relationship […]
[…] removes <link rel=feed>. As I documented earlier this year, rel=feed was a reasonable idea that never took off. Only one browser ever implemented it, and in a […]
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.
Note that rel=”shortcut icon” isn’t correct, use just shortcut=”icon”.
[…] April 17th installment all about link relations. And while that may sound confusing, boring, or pedantic, it is actually […]
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…
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.
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.
[…] useful websites use some form of pagination. However, link relations are not in widespread […]
Apparently rel=up has been pulled out of the HTML5 specification and now triggers errors.
Do you know why it was pulled?
@Laurent Goderre : http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c15
[…] rel attribute emerged as a standard for link relations, a method of describing some specific purpose of a link. Not all links, you see, are functionally […]