The HTML4 spec is rather ambiguous about how the LINK element should be handled. In an attempt to reduce the ensuing confusion, I have tried to write this document, which gives all the possible combinations of attributes and values the spec allows, and then suggests suitable behaviours. -- Ian See also: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt =========================================================================== IMPLEMENTING THE LINK ELEMENT ============================= This document is no longer what I believe. I should be updating it soon, with a new specification that is a lot more useful. The important attributes of the LINK element are: href - indicates location of linked document (mandatory) hreflang - indicates primary language of linked document lang - indicates language of title attribute media - indicates the target media of the linked document rel - indicates the role of the linked document wrt this one rev - indicates the role of this document wrt the linked one title - indicates the title of the linked document type - indicates mime type of linked document is the list found in section 6.12 of HTML4, i.e.: Start, Next, Prev, Contents, Index, Glossary, Copyright, Chapter, Section, Subsection, Appendix, Help, Bookmark. The LINK element defines a link between an HTML (or XHTML) document and some other resource (which may also be an HTML document). Unlike the A element, it may only appear in the HEAD section of a document, although it may appear any number of times. The LINK element has no content, rather the information about the relationships it conveys should be rendered by user agents outside the document itself, for example in a tool-bar with a drop-down menu of links. The LINK element is also used to link to external stylesheets. To process the LINK elements, the UA should first get a list of every LINK. These can be created by the LINK element, the META element (http-equiv="Link"), or HTTP headers. The UA should then make a list of all those LINKs with the value 'stylesheet' in the 'rel' attribute. For each of entry in the list, if the 'type' is not supported, the link should be ignored and not provided to the user (unless the user explicitly requests to see stylesheets that the UA cannot handle). The UA should then shortlist all stylesheets and alternate stylesheets that apply to the medium in question. When deciding if a LINK applies to a medium, the HTML4 rules (section 6.13) for parsing the 'media' attribute should be used. All stylesheets not matching the current medium should be ignored and not used (but listable, if the user wants to see what they are). Note that this will result in different lists for different media. For example, a UA may provide three lists of stylesheets: one for when viewing the document on the screen (to select between alternate screen stylesheets), one for when printing (to select between alternate print stylesheets), and one with all the stylesheets given, to satisfy user curiosity. The UA should then take all the stylesheets in the list of those matching the current media that have no 'title', and apply them (i.e., it should apply all relevant persistent stylesheets). The UA should then find the preferred alternate stylesheet (selected by virtue of the Default-Style HTTP header, or failing that by selecting the first stylesheet not marked alternate but with a title). The UA should then apply all stylesheets with that title (i.e., it should apply the preferred stylesheet). The UA should then get the names of all remaining stylesheets, remove duplicate names, and (along with the preferred stylesheet selected above) list these as the alternate stylesheets. To list the alternate stylesheet to the user, the UA should use the information found in the 'hreflang', 'title' and 'rev' fields, with possibly the information in the 'href' and 'lang' fields too. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From here on, I would ignore this specification if I were you!!! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Then, for each LINK with 'rel' containing one of then the behaviour should be as follows: Provide a link to the document specified by 'href', with the title being made from the following components: 1. The 'title', or if not specified, the value of 'rel' (or a translation of the 'rel' into the user's language). 2. The language given by 'hreflang'. If the 'rel' contains "alternate", then clearly flag that the link is an alternate copy (eg by prefixing the title with "Alternate "). The 'media' attribute may be used either as part of the title or to categorise the linked documents, so that there can be different sections for each media type. The mime type information ('type' attribute) can be used, in the absence of more authoritative information such as Content-Type headers, to decide how to handle the document if it is selected. It may also be shown to the user if the user so requires. For each LINK with 'rev' containing one of then the behaviour should be as follows: Same as for 'rel', substituting 'rel' for 'rev', and clearly denoting in the UI that the relationship is a reverse one. For each LINK with a 'rel' or 'rev' of "alternate" alone, then the UA should follow the following behaviour: Provide a link to the document specified by HREF, clearly flagged as being an alternate version of the same document, with the title given by the following components: 1. The link title ('title'). 2. The target document language ('hreflang'). 3. The medium ('media'). 4. The mime type ('type') or a friendly name version. If none of the above attributes are specified, then merely label the link "Alternate Version" or some such. The UA may support other proprietary 'rel' or 'rev' types, in which case it should deal with them at this point. Notes. A. If two stylesheets are given with the same 'title' and 'media', but with different 'hreflang', then by the system above they will both be applied. When the list of languages is displayed, the languages that that title has associated with it will all be listed. For example, if three stylesheets a.css, b.css and c.css are all called "Acid Bath" but have hreflang=fr, hreflang=en and hreflang=es, they will all be applied simultaneously if "Acid Bath" is selected, and in the stylesheet list, "Acid Bath" will be listed something like this: Acid Bath (French, English, Spanish). This is the only sensible behaviour because the "Default-Style" HTTP header only has room for specifying the title of the preferred stylesheet, not the language. So authors wishing to use 'hreflang' will need to ensure that they also change the 'title', if they wish to not have them apply simultaneously. This is fine, actually, since the 'title' will probably be different anyway (with a different 'lang', too). This is similar to the 'type' attribute. For example, according to the spec (and according to my guidelines), the following links will all be applied, *simultaneously*, by browsers correctly supporting HTML, CSS, XSL and DSSSL. (How that is actually supposed to be handled is seriously undefined!) Thus authors should probably never do the above, instead using: Using a 'title' on each prevents them from ever being applied simultaneously. The order in which they are listed indicates the order of preference (so, if a browsers supports css and dsssl, then the above would only apply the css one, unless and until the user selected the dsssl version from the alternate stylesheets list). The supported stylesheets that are not applied would get listed as alternate stylesheets. B. If a LINK contains both 'rel' and 'rev', then both the 'rel' and 'rev' sections above will match and the link should be displayed twice: once in the "Links" and once in the "Reverse Links" sections of the UI. C. The 'dir' and 'charset' attributes are ignored by the above algorithm. They could be implemented in a way similar to the recommendations I give for the 'hreflang' attribute. EXAMPLES ======== The example below illustrate how several LINK definitions may appear in the HEAD section of a document. Imagine that the current document is "Chapter2.html". The 'rel' attribute specifies the relationship of the linked document with the current document. The values "Index", "Next", and "Prev" are explained lower down. Chapter 2 UAs could use the information in the LINK elements above to create a submenu like this: | ... | | Related Documents >+----------+ +----------------------| Index | | Next | | Previous | +----------+ This would allow very simple access to related resources. The 'rel' and 'rev' attributes play complementary roles -- the 'rel' attribute specifies a forward link and the 'rev' attribute specifies a reverse link. For example, consider two documents A and B. The following link in document A: Document A: ...has exactly the same meaning as the following link in document B: Document B: Both the 'rel' and 'rev' attributes may be specified simultaneously, so for example in the "Chapter 2" example above, you could say: This could be presented to the user like this: | ... | | Related Documents >+----------+ | Reverse Links | Index | +----------------------| Next | | Previous | +----------+ ...and: | ... | | Related Documents | | Reverse Links >+-------------+ +----------------------| Previous of | | Next of | +-------------+ In the following example, the hreflang attribute tells web browsers where to find Dutch, Portuguese, Arabic, and French versions of a document. Note the use of the dir and charset attributes for the Arabic manual. This metadata is purely informative, and can probably be ignored by user agents. Alternatively, it could be treated the same way as the 'hreflang' attribute. Also note the use of the 'lang' attribute to indicate that the value of the title attribute for the LINK element designating the French manual is in French. | ... | | Related Documents >+------------------------------+ +----------------------| The manual in Dutch | | The manual in Portuguese | | The manual in Arabic | | La documentation en Français | +------------------------------+ ...or: | ... | | Related Documents >+------------------------------------------+ +----------------------| The manual in Dutch (Dutch) | | The manual in Portuguese (Portuguese) | | The manual in Arabic (Arabic) | | La documentation en Français (French) | +------------------------------------------+ Preferences could be used to decide exactly what is displayed, for instance the order could be that selected by the user as their preferred languages. You can also use the 'media' attribute to indicate alternatives for different media, such as for print or audio. In the second example below, note the use of the extended syntax for the media attribute -- UAs should recognise that as simply "aural" according to the rules set out in HTML4, section 6.13. These two links could be rendered like this by UAs: | ... | | Related Documents >+--------------------------------+ +----------------------| The manual in postscript | | The manual as read by Mr Burks | +--------------------------------+ Alternatively, UAs could organise the alternatives based on the media, like this: | ... | | Related Documents >+--------------------------------+ +----------------------| Print | | The manual in postscript | |--------------------------------| | Audio | | The manual as read by Mr Burks | +--------------------------------+ =========================================================================== There now follows a copy of a reply I wrote regarding http://www.prismelite.com/linktag.txt ...which was written by Tim Hill . =========================================================================== > A. Which values of REL should have built-in support? > [snip long lists of rel values] All of them, including those we don't know? I would say definitely all of those in HTML4.01, plus others if supporting them is simple. Let's see: Special values: Stylesheet: ignore these. Alternate: prefix "Alternate: " to the title and stick it in a menu on its own. Bookmark, Navigator: Use the "title" on its own and stick that at the foot of the "Navigation" menu. Author: If it's a "mailto:" link, offer the option to "E-mail Page Author...". If it is not, then interpret this as in "Related Documents" below. rev="made": Interpret as rel="author". Meta: Use the "title" on its own and stick that wherever the "Author" link goes. TOC: Treat as "Contents" (see "Related Documents" below). Navigation: These are the magic rel values that should be interpreted to provide the main navigation buttons, IMHO. |< Start, Home, Top, Origin, Begin, First < Prev, Previous, Back ^ Parent, Up + Sibling v Child, Down > Next, Forward >| End, Bottom, Finish, Last Related Documents: IMHO, Any other "rel" value, including all those below, should be treated as "NameOfRelValue: Title" and placed in a "Related Documents" menu. Chapter, Section, Subsection, Appendix, Contents, Index, Glossary, Biblioentry, Bibliography, Citation, Definition, Footnote, Help, Copyright, Disclaimer, Editor, Publisher, Trademark, Copyright. > Interface/Presentation of LINK REL attributes > ============================================= > > 1. Consistent positioning in the interface regardless of the order > of their inclusion in the document. That gets my vote. > 2. Visibility vs. Enabled/Disabled State. Should unused REL values > be shown in a disabled state for consistency, or be hidden > altogether? I think the "[|<] [<] [^] [+] [v] [>] [>|]" links should always be present, and disabled if the appropriate is absent, but others should simply come and go as appropriate. If some of the navigation links are present more than once, then I guess that the menu item should be turned into a submenu (or if it's a button on the bar, then it should be turned into a menubutton like the Back and Forward buttons with their little down arrow). > - Any LINK with REL containing "stylesheet" (and "alternate > stylesheet") should be ignored, as this is handled by the stylesheet > switching mechanism Absolutely. > - Any LINK with REL containing "alternate" should be grouped under > an Alternate document menu, possibly accessible from the View menu. > Perhaps icons or text could differentiate the items based on the > values for the "media" and "hreflang" attributes. Right. Algorithms for that are discussed in my document. http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt > B. How should values of REL without built-in meaning be presented? > A. Should space-separated values for REL have a different meaning > from separate LINKs with the same URL? If so, for which REL values? See about two thirds of the way down this document: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/metadata.txt ...for some ideas. > B. Does the ORDER of space-separated values create a different > meaning? If so, for which REL values? Not in my opinion. > Does this merit prominent support in the UI? Prominent? No. > It seems odd that a user would want to NAVIGATE using REV links when > REL links are already available. I agree... but the standards says "rev" is there, so... > The user might want to KNOW the metadata that REV provides, for > example that the current document, Chapter 1, comes before Chapter 2 > (although that's pretty clearly implied). But to navigate from > Chapter 1 to Chapter 2 by saying "Previous of", as in Ian's > document, doesn't really make much sense. Fair enough. > I think if this is included, it would be better to have it available > in document info than a menu item. That's fair enough. The page titles should be made into links, though, so that it is possible to use them to go to the documents. > Supporting the LINK tag within frames causes some problems. Options: > 1. Display LINKs for top level document IMHO that would be bad. > 2. Display LINKs for the currently focused FRAME but not FRAMESET > (FRAMESETs can't receive the focus) Probably the best solution. Framesets are not structural, they are presentational, in any case. And presentational documents are unlikely to have any navigational metadata... > 2. Minimal LINK tag support in Go menu or a drop down menu. > Difficulty: Low > Description: This is trivial. Just grab the list of LINKs and > display them in a menu; perhaps a Link submenu under the Go menu, or > a single button on the navigation toolbar. Similar to > http://www.useit.com/papers/icab.html Better than nothing! I'm not 100% sure this is "trivial", since you have to do a modest amount of processing of the link elements' attributes to work out exactly where in the menu each link should go. Also, I think we should definitely do this, however much else we do. That is to say, the complete list of LINKs should be available in the menus, in addition to any buttons. > I think we should at least aim for minimal support, and add more later. Absolutely agreed. =========================================================================== Contributors: Ian Hickson Philippe Maestri Tim Hill Matthew Thomas