Everything on this web page should be applicable to the latest versions of HTML, except that recent HTML standards by W3C recommend or require the use of lowercase tag names. This web page was written with uppercase tag names because it was originally written for an older version of HTML. However, other than the lowercase/uppercase issue, the information in this document has remained relevant to the latest HTML standards that W3C publish.
Support for the <LINK> tag, a valid part of HTML specifications, is so underused that many people, including professional web designers, are unaware of this standard tag. This leads to web designers implementing custom solutions to offer the navigation features described in the LINK tag specifications, not realizing that any HTML specification for such features even exists. There have been some extentions to the LINK tag's functionality, such as specifying FavIcon.ico shortcut icons, and specifying CSS style sheets, or even Microsummaries. These extensions may be far more well known than the tag's original purpose, which is to specify page relations so navigational tools can be used. Sometimes people spend a lot of effort creating custom solutions to implement the same basic functionality that the <LINK> tag was designed to do, yet people simply do not know that it exists. An example is this proposal for a new tag.
As a quick example of how a LINK tag can be used, page 3 of a forum could have LINK tags to support hyperlinks to the previous page, the next page, or to go up in the heirarchy to a table of contents (or a list of forum topics or a list of forums).
Another example would be a page showing results of a query that was provided to a search engine.
In both of these example scenarios, if a web page uses this tag and a browser supports the tag, then a user can go from page to page using a navigation button in the browser. (At least in theory, the browser could also support a keyboard interface, similar to the Alt+Home keyboard combination that lets a person quickly go to the home page, without needing to move a person's hand off of the keyboard).
The other typically-used option for navigation is to make users scroll to the top or bottom of the page, in hopes that site-specific navigation hyperlinks are located there. Some sites don't place navigation hyperlinks in both locations (at the top and the bottom). So, if a user scrolls back up a bit to look at the middle of the page, and then decides to move onto another page, the user needs to just guess which direction to scroll to (which is why the user “hopes” to find navigation when scrolling to the first direction). That guessing isn't needed when the user has a familiar interface at a known visual location.
The other piece of really good news is that using the <LINK> tag does not cause problems. Browsers do not break when the <LINK> tag is used, even if they do not visually show any support for the <LINK> tag. Perhaps that is simply a pleasant side effect of the fact that the <LINK> tag is actually a very old part of HTML.
The web browsers page may have some information for specific web browsers, such as Firefox add-ons: Supporting the <LINK> tag. For Internet Explorer 5+ on Win2K/XP, the “<Link> Navigation Bar”/“<LINK>-Bar” adds some support. There is no equivilent option for users of other versions of MS IE (such as MS IE 6 for Win9x).
Webmasters can support proper usage of the <LINK> tag when they are implementing features that are well-supported by the <LINK> tag. For instance, many web sites could use hyperlinks for listing a “Copyright” page, a “Start” (or “Home”) page, a Table of “Contents”, or the “Next” page in the series of pages. Details, on how to make such a <LINK> tag, are located on this web page.
Using these pages can brighten up some web browser features that would otherwise be dimmed (a.k.a. “grayed out”). Therefore, supporting the use of a “LINK” tag can make web browsing more pleasant for some users visiting a supporting site.
To use a <LINK> tag, first find a possible common use of a link tag. Some common examples (like the Table of “Contents”) were mentioned earlier, and a larger list of commonly supported relationships is provided later.
Next, decide whether to use REL= or REV=. In most cases, REL= will probably be the logical choice. REL indicates that the relationship specified is how this page views the specified URL. For example, REL=Next indicates that the specified page is what this page would consider to be the "Next" page. In contrast, REV= indicates the relationship that the other page would indicate. For example, REV=Previous indicates that this page would be considered to be the “previous” page by whatever URL is specified.
Although the previous paragraph said REL= will likely be what is most commonly used, that typically won't be the case with the MADE relationship. Just as REV=Previous indicates that this page is thought of as “Previous” by the specified value, likewise REV=MADE indicates that the page is “Made” by the the specified value. (See LINK page discussing this.)
In XHTML, <LINK> tags should end with a space and a slash before the greater-than sign that ends the tag.
Link - Document relationship says, “While the value of REL and REV is case-insensitive, the Lynx browser renders the relationship exactly as given by the author. Authors should therefore be consistent in their case,” advice which is probably not necessary for technical reasons but rather stylish ones: Viewers would be able to see inconsistency.
The <LINK> element can be useful in the following ways:
HTML 4.0 list of link types.
Webmasters who make multiple web pages can probably have opportunity to use multiple of these tags.
HTML 4.0 list of link types describes as “Refers to a document offering help (more information, links to other sources information, etc.)”
(Help is mentioned by Document Header.)
The most common method is MADE, followed by an E-Mail address. Some pages will specify MADE followed by a person's name. HTML REL, REV - HTML Code Tutorial demonstrates both using syntax of: <LINK REV=MADE TITLE=“Person's Name” HREF=“mailto:firstname.lastname@example.org”> However, TITLE is used differently by another tutorial: htmlhelp.com page.
Note that this is the one relationship where REV is considered to be most commonly more correct than REL.
The “Contents” relationship is probably going to be the most used relationship from this section.
“Alternate”, particularly when used with the “lang” attribute (per HTML 4.0 list of link types). So, for example, the tag might look something like: <LINK Alternate="about:blank" lang="de">
Link Bars web page also references a “Translation” relationship (instead of an “Alternate” relationship), but that doesn't seem to be widely supported. Therefore, the preferable method seems to be using “Alternate” instead of “Translation”.
(The “Help” tag type was previously mentioned here, but is discussed further in the “Navigation” section.)
Having this on a page tells the web browser the location of a shortcut icon that the browser should use, and indicates that the browser should not try to look for /favicon.ico as the location of a shortcut icon. The most standards-compliant way to use this would be <LINK REL="Icon" TYPE=";image/vnd.microsoft.iconquot; HREF="filename.ico">
(The TYPE field may not be needed. The value of vnd.microsoft.icon came from Wikipedia's article on Favicon, citing IANA recognition. An alternative value of image/png may be supported by Firefox and other browsers.)
The sometimes-used format of <LINK REL="Shortcut Icon" HREF="filename.ico"> is in violation of standard specifications, which indicate that a space in a relationship field is meant to separate multiple relationships, although using that may actually work on comforming browsers that look for the “Icon” relationship (and would ignore the word “Shortcut”).