existing rel values

This page contains tables of known HTML rel values from specifications, formats, proposals, brainstorms, and non-trivial POSH usage in the wild. In addition, dropped and rejected values are listed at the end for comprehensiveness.

Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).

Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.

a style sheet for the current document used with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred. Unfortunately the use of stylesheet in user visible content like <a href> appears to be strictly theoretical.

Synonyms such as "previous", "toc" are not as widely supported as the main term.

proposals

A few rel values have been developed as drafts as a result of going through most of the microformats process, and are thus listed here for your serious consideration. You may use these values, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

HTML5 link type extensions

Please check the Formats table and DO NOT re-register rel values that are already there. Please note that the W3C HTML WG has made a Decision to drop index, up, first and last from the HTML5 spec itself.

Please check the Dropped table and DO NOT register values that are already there. If you believe a rel value was dropped from another specification without prejudice, please provide link/cite to explicit text/decision stating as such, e.g. the value was merely postponed, or perhaps expected to be spun-out into its own spec from the group developing that specification.

Note that entries in the Formats table and entries that are already in HTML5 as built-in keywords are also considered extensions with the "Ratified" status.

Please make sure that registrations added here have all the required data filled in including:

"Effect on link"

"Effect on a and area" and

a link to a spec that documents the keyword as an HTML rel keyword. (A spec that merely defines the file format of the link target but does not define the rel keyword for use in HTML is not the kind of spec that is being required here.)

Entries lacking any of the above required data will likely be removed.

Changes to this registry will not be reflected in validators in real time. But validators will typically get automatically updated with the changes within one week or so

indicates a code repository location. For link, it specifically indicates, in the case of server-generated content, the location of source code responsible for the generation of the current page, or, in the case of static files, where copies of the current page are housed). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and content-repository should be used to indicate the location for the storage of content. Otherwise, the code repository can be considered as also including the content. While the repository should contain its own license file, the code-license rel-value is proposed as a direct pointer to the license (see also content-license).

indicates a license for code (a proposed broader replacement for jslicense). For link, it specifically indicates, in the case of server-generated content, the location of the license for all source code responsible for the generation of the current page, or, in the case of static files, the location of the license for all of these files). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and content-license should be used to indication the license for the content. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the static or generator code files should be done with code-repository (and content-repository for any separate content).

indicates a repository housing data content. For link, it specifically indicates, in the case of server-generated content, the location where separately housed data files used to populate the current page are stored (otherwise "code-repository" is sufficient to include content as well as code). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and code-repository should be used to indicate the location for the storage of the generator source files. Otherwise, code-repository can be considered as also including the content instead. While the repository should contain its own license file, the content-license rel-value is proposed as a direct pointer to the license (see also code-license).

indicates a license for data content. For link, it specifically indicates, in the case of server-generated content, the location of the license for all separately housed data files used to populate the current page are stored, (otherwise "code-license" is sufficient to cover the license of content as well as code)). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and code-license should be used to indication the license for the generator source files. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the data files should be done with content-repository (and code-repository for the static or generator code files).

Refers to a document with JavaScript source code and license information (also called a JavaScript License Web Labels page). We might want choose a keyword for this that is more general -- there are many situations besides JavaScript in which it is desirable or required by license agreements (e.g., GNU GPL) to make an offer of both the source code and a copy of a license when distributing object code versions of a given work.

Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (e.g. with installed "Lightbox 2"-Plugin). When adding [group] to rel="lightbox" all images get a clickable button for next/prev; insert into <a rel="lightbox[group]"><img src="http:example.com/img.jpg"></a>

Lightbox 2 (needs actual specification to be kept in this list, this link is just documentation of one implementation)

Associates a PGP key with a Web page so that the Web page URL can be used as the commenter's URL in PGP-signed blog comments and the blogging system receiving the comment can fetch the key and verify the signature as belonging to the owner of the URL.

Indicates an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high costs of connection establishment latency.

Indicates that the referenced document is a metadata profile (e.g., a social-media/real-name profile such as a Google+ profile) for the publisher of the current page, or some portion of the current page.

indicates any mailbox(es) (i.e. email addresses) to which responses are to be sent. Note: this is distinct from the 'in-reply-to' value which refers to the originating document, not to the address where comments should be sent.

brainstorming

Several rel values are being brainstormed as potential microformats and are thus listed here. If you find you have a use for such semantics in real world examples, consider trying out these values and provide feedback on the respective brainstorming page(s) with your results and experiences.

You may list new proposed rel values here, and even better if you can list and link to POSH uses in the wild.

Link to a map. Possibly embedded within an adr, hCard, geo or hCalendar. Parsers MAY attempt to parse the URL if it is a link to a known map site (e.g. Geohash, Google Maps, Multimap) and extract co-ordinates and other useful data.

indicates the URL and content-type of a resource that is likely to be a required resource when the next action or navigation is triggered. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.

indicates the URL and content-type of a resource that should be fetched as early as possible by the user agent. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.

indicates the URL of the next navigation target. Initiating a prerender allows the user agent to deliver an instant navigation experience: the user agent downloads the top-level resource and its assets, and performs all of the processing steps required to show the page without actually showing it to the user.

POSH usage

There are numerous rel values used as POSH, both in the wild, whose origins are not necessarily known, nor are their meanings consistent. There are also numerous rel values from external proposals of varying degrees of merit. It is useful to document their existence and summarize their implied meanings/usage intent as research that may be used to perhaps take one or more of them thru the microformats process if there is both sufficient interest and sufficient in the wild usage.

Note: If a value is missing from this table, it may have either already been promoted by writing it up as a proposal, or demoted by being explicitly dropped. Please check the other tables first before adding to this table.

Note: this list is incomplete, please help complete it from the following sources:

Location of the xml-rpc gateway for a Wordpress install that allows external programs to add, edit and delete posts. Used by "WordPress blog client" software for automating posting and updating blog content from your desktop.

Nonetheless, there may be some mileage in using them in microformats, at least until HTML5 is widely available.

Dublin Core

In the past, Dublin Core values have been added to this page in the table about HTML5 features, but no examples, nor an actual specification explicitly stating how the value(s) should be used in HTML could be found. The linked specifications below have been updated so we should start considering Dublin Core values accordingly.

rel value

summary

source

schema.DC

a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, with regard to the fifteen terms of the Dublin Core Metadata Element Set already published

a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, reflecting the changes described more fully in the 2012 document "Maintenance changes to DCMI Metadata Terms" [10]

examples from that search only use invisible <link href> element. At first glance it appears the results from the search show only uses with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred.

RFC2731 defines rel="schema.AC" and rel="schema.RC" with the pattern rel="schema.PREFIX" as a syntax for defining namespaces for use in meta[@name], *[@rel], *[@rev] and (as per eRDF) *[@class] attributes. A link to a Dublin Core metadata schema is generally not suitable for end users, so <link href> appears to be more appropriate than <a href> for those that use Dublin Core metadata schemas.

The scheme proposed above provides metadata namespace declarations. As described by DCMI specifications, such indications cannot be provided w/o a suitable namespace. In order to give complete pieces of information, the correct description set must be: <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"> (for the namespace declaration, followed by) <meta name="DCTERMS.[element]" content="[element.value]"> for related elements.

Note: schema.DCTERMS is conventionally related to an upgraded elements list than schema.DC and should be preferred as rel values. Both are discussed here for subject completeness)

proposal to use in content currently only theoretical. Thus unfortunately the use of Dublin Core in user visible content like <a href> appears to be strictly theoretical. See microformats-discuss/2008-January/011445.html for a proposal to use Dublin Core in user visible content.

recent improvements. DCMI solves some trouble concerning metadata through the description set model. Some of these informations cannot currently be provided in any standard ways other than DC, namely dates, validity and periodicity. Following this public bug report ([12]), the correct namespace declaration for DC and DCTERMS metadata are now considered valid HTML code. We must encourage this practice both for internal usefulness and for shared practices.

"Expressing Dublin Core metadata using HTML/XHTML meta and link elements" also includes examples of <link rel="DCTERMS.[element]" href="">, where [element] = subject, isReferencedBy, creator, and publisher. The <link> tag is used instead of the <meta> tag whenever the content is a URL. (Note that this use is different from, but related to, <link rel="schema.DCTERMS" href="">.) Potentially, any of the 55 DCTERMS elements could be used in this way, and this could include use in HTML 5.

As said before, HTML5 validators now allow the use of <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"> for namespace declarations.

According to DCMI specification linked above, as well as "Expressing Dublin Core metadata using HTML/XHTML meta and link elements" documentation, HTML5 @rel attribute proposed values table has been updated. It now includes a subset of DCMI /terms/ namespace properties, more specifically those whose value can (or must) be logically expressed by a resource, so that the "href" attribute value becomes a non-literal value surrogate referring to the resource itself.

Elements from /elements/1.1/ namespace have not been included on purpose. According to "FAQ/DC and DCTERMS Namespaces", the old namespace is maintained for legacy purposes only and it is not as suitable for non-literal values as the ones denoted by <link> elements.

Use with HTTP Link Header

You can also use any of the rel values (that are allowed for link elements) with HTTP Link Headers,

Example: returning a Javascript file with a license (since JS itself has no way to indicate a license)

unspecified

Some rel values have been added to this page perhaps in one of the tables above, but no examples, nor an actual specification explicitly stating that the value(s) should be used in the HTML 'rel' attribute could be found. They are listed here in the hopes someone can discover more specific/precise URLs to examples or specifications about them (preferably both). Until such precise URLs to examples/specs are provided, the values can be treated as they are purely theoretical and thus of little interest.

A simple list here is sufficient.

non HTML rel values

There are markup languages other than HTML that also have a rel attribute, often based upon the HTML rel attribute.
It is useful to document some of these other languages and their rel values for both reference purposes, and to provide background research for the possible development and re-use of these values in HTML, as poshformats or microformats

When included in a resource representation of an event, the "sub" (subscription) link relation MAY identify a target resource that represents the ability to subscribe to the pub/sub event-type resource in the link context.

When included in a resource representation of an event, the "unsub" (subscription cancellation) link relation MAY identify a target resource that represents the ability to un-subscribe from the pub/sub event-type resource in the link context.

dropped

The following rel values were in earlier version(s) of specification(s) and it is presumed by their absence from the most recent version of the respective specification(s) that they have been deprecated or obsoleted.

In general, you SHOULD NOT use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you MUST NOT use the dropped versions.

In particular:

if a rel value was in a draft and is missing (without explanation) from the final spec, or

if a rel value was in a previous version of and is missing (without explanation) from an update to the specification (even a draft update)

Then absent any other information or explanation, it is presumed that the group/editors working on that specification decided to explicitly drop it (either in development, or in the updated version) and thus it should be obsoleted (not re-registered).

If you wish to add them, please research why such values were omitted from latter specifications before doing so. If you do discover the reasoning, please add a short statement or link to thereof into the appropriate place in the following table.

If there is more data, e.g. a link to an email of discussion of the spec development that explains why the rel value was dropped, and it explicitly states, e.g. it was without prejudice, or merely post-poned, or perhaps expected to be spun-out into its spec (or some other explicit positive reason), then it makes to link/cite that explicit text as part of a proposal.

Sources:

HTML3 (HTML3) / has been superceded by HTML 3.2 - which itself has been superceded by HTML 4.0 - which itself has been updated by HTML 4.01, commonly referred to as "HTML 4" in this wiki and other places.)

Proposed HTML 4.0 link types (HTML4dropped) - obsoleted/superceded by the HTML 4.0 Recommendation. Any values that were in the "Proposed HTML 4.0 link types" document but didn't make it into the HTML 4.0 Recommendation were thus explicitly dropped and should be avoided.

dropped without prejudice

In one known instance (from HTML4 to HTML5), some rel values were in an earlier version of a specification (or a proposal) and were dropped from a latter (draft) version, and it was noted that these values were dropped with the intent that they could still be proposed in a registry and thus they explicitly were not deprecated or obsoleted. This section documents such values as separate from the dropped section.

In general, you SHOULD NOT use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you MUST NOT use the dropped versions.

Rel values that were dropped without prejudice from a specification will be considered similar to new values that have never been specified.

If you know of additional rel values that were dropped without prejudice from an update to a specification, please cite a URL and quote from the group developing the specification that officially states from that group that the dropping of the values was done without prejudice, or equivalent statement (such as explicit allowance of external registration, proposal, and/or development).

This table serves a historical purpose. If you wish to propose a value from this table, please copy it and leave it in place.

"The final proposal argues for the removal of some relation values, to wit, it suggests removal of index, up, first and last. It was pointed out in survey comments that these relations are already registered in the IANA link relation registry. Presumably, these relations could also be entered in whatever other registry or registries HTML5 adopts for this purpose.

...

"Next Steps

...

"Since the relations to be removed are already registered at the IANA link relation registry, no further action is needed to include them there. WG members are free to register or record these relations elsehwere [sic], as well."

previous attempts at documenting

There have been previous attempts at documenting known rel values, most of which fell out of date due to being dependent on a single author maintaining them. They're listed here purely for historical reasons, and are not sufficient to be references of their own (since they're just individual curations of other references)