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