Technically links are specified using A (anchor) elements, and some technical issues are discussed in the description of the A element. In principle, some other HTML constructs define links, too. In particular, the LINK element defines a link between two documents.
A link is a directed connection between a particular point in a document and another particular point in the same or another document or another resource on the Internet. The points are often called anchors in HTML terminology.
The two ends of a link (the anchors) are in different logical positions: the link is from one point to another. The latter, called the target of the link, is very often the beginning of a document or, perhaps more logically speaking, an entire document.
In the simplest case, you create a link from one point of your HTML document to another HTML document (which could be your own or written by someone else, perhaps physically located at the other side of the globe). You have to decide which words act as a visual representation of the link, i.e. as the phrase which refers to the other document, and you need to know the Web address (the URL) of that document. Then you just put the pieces together into a suitable A element. For instance:
I have worked at <A HREF="http://www.hut.fi/english.html">HUT</a>.This might, in one environment, be rendered as follows:
I have worked at HUT.
The link text, here the abbreviation HUT, acts as a link to a Web document which explains what the abbreviation means and also provides a lot of information about it. The rendering of links varies a lot - the link text might be underlined, colored, or otherwise distinguishable from normal text. In particular, underlining is not part of the link concept, just one possible rendering. The user(reader) is assumed to know how links are rendered in the particular environment.
The user should also be assumed to know how to use his browser in order to follow a link, i.e. to access the linked resource. There is hardly any reason to tell the user to click something, especially since clicking is by no means the only possible method for following links. (A keyboard or some other pointing device than a mouse or spoken commands might be used in different environments.)
It is also browser-dependent whether and how the linked resource can be viewed in a new window, stored into a file, passed as data to some application, or processed in some other way.
In particular, as an HTML author you need to do nothing to allow the user to open a document in a new window. In a typical graphical browser, such as Internet Explorer or Netscape, the user can use the rightmost button of the mouse for the purpose when selecting the link (instead of the normal use of the leftmost button), then select the alternative Open in New Window in the pulldown menu opened. Naturally, the user could then move that window to another position on the screen and resize it suitably. If you think that most of your users don't know such things, you may give a note about them, when you have a link for which such a treatment might be especially suitable (such as in the To whom? section of this document). But any references to such issues of browsing techniques should be kept to minimum in Web documents, unless such techniques are their main topic!
Typically people assume that a link refers to some general information about the thing expressed as the link text. Thus, the link HUT in our example leads to the home page of HUT (which hopefully explains what the abbreviation stands for, what the institution is, etc).
If the nature of a link is different, you can try to help the user understand it, allowing him to make a rational decision whether to follow the link or not. There are actually several ways for doing that, and in some cases you might use all of them:
At least one of the methods described above should be used at least if the link is of unexpected nature, such as referring to very detailed technical reference in a tutorial or referring to an example only in a context where the reader would expect the link to point to general information. Examples:
<P>The expiration time must be expressed in one of a few strictly defined formats (as defined formally in <A TITLE="The official specification of the Internet E-mail protocol" HREF="ftp://ds.internic.net/pub/doc/rfc/rfc822.txt">RFC 822</a> and <A TITLE="Requirements for Internet hosts" HREF="ftp://ds.internic.net/pub/doc/rfc/rfc1123.txt">RFC 1123</a>). </P>
My interests include comic books (especially <A TITLE="A large Calvin and Hobbes site, with a daily strip and a lot more" HREF="http://www.calvinandhobbes.com/">Calvin & Hobbes</a>), <A TITLE="Some material, by me and by others, about the Finnish language, mostly in English" HREF="../Finnish.html">Finnish language</A>, and <A TITLE="My experiences on making beer and wine at home; in Finnish, with a short summary in English" HREF="../beerwine.html">making beer and wine</A>.
Note: Internet Explorer 4.0 shows the TITLE texts when cursor is on a link, but only after a delay of a second or two.
As regards to REL and REV values in general, there is no official requirement on browsers to support any particular set of values. The idea of specifying the nature of a link with REL and/or REV has been in HTML from the early days, but it has not been deployed much. Probably, and hopefully, things will change.
The following table lists some REL values which authors can use, expecting them to be supported by at least some browsers now or in the near future. They were listed in an Internet Draft (draft-ietf-html-relrev-00.txt, now expired) in 1996 as well as in the HTML 3.2 Reference Specification, and they have been included into the list of link type values in the HTML 4.0 specification. (See also W3C working draft Hypertext Links in HTML.)
attribute setting | type of link (role of linked resource) |
---|---|
REL=CONTENTS | A document serving as a table of contents. |
REL=INDEX | A document providing an index for the current document. |
REL=GLOSSARY | A document providing a glossary of terms that pertain to the current document. |
REL=COPYRIGHT | A copyright statement for the current document. |
REL=NEXT | The next document to visit in a guided tour. |
REL=PREV | The previous document in a guided tour. (This value was originally named PREVIOUS.) |
REL=HELP | A document offering help, e.g. describing the wider context and offering further links to relevant documents. This is aimed at reorienting users who have lost their way. |
REL=BOOKMARK | A bookmark, used to provide direct links to key entry points into an extended document. The TITLE attribute may be used to label the bookmark. Several bookmarks may be defined in each document, and provide a means for orienting users in extended documents. |
In conjunction with style sheets, a LINK element with REL=STYLESHEET can be used.
Although it is technically easy to set up links, it is pragmatically often difficult to use them the right way. Here are some practical guidelines:
From the HTML viewpoint, linking to audio and video resources is easy: simply provide a link to a file which is in a suitable format. (This leaves it to the user to follow the link in order to listen or see the material. In HTML 3.2, there is no way to force audio or video to autoload and autostart.)
<P>This page is so solemn that you may wish to listen to the <A TITLE="[0.5 Mb .au]" HREF="http://www.tpk.fi/sound/porilaisten_marssi.au"> <CITE>Pori March</CITE></A> while reading.</P>
It depends on the browser how references to resources like audio and video files are handled. If a browser supports them, it typically supports some particular repertoire of file formats by initiating ("launching") a separate program for "playing" the file. (It might use a distinct program for each file format or a general-purpose media player program for a large set of formats.)
Thus, for example, in order to
listen to .au
files the user needs, in addition to suitable hardware installed,
a program which can produce sounds interpreting
that specific
format,
and the user's browser must have settings which instruct it to launch that
player program for those files.
In principle, the Web server on which the file resides should be configured to send the correct media type for the file. In practice it mostly does that on the basis of the file name extension (and some browsers incorrectly rely on that extension more than on the media type information).
See also: Guidelines for HTML Writers of MIDI File Pages by Charles Kelly.
You can make plain text and binary files of various formats available to other people alongside with your HTML files, and you can tell about them and provide links to them in your HTML documents.
Similarly to audio and video files (which are actually special cases of binary files), quite a few things must be set up (outside the HTML document) both in the server and in users' browsers for this to work. If your server does not support the file format involved, you can try to use some widely known format and corresponding file name suffix; see also WDG Web Authoring FAQ, questions 5 and 6.
Of course, such links will be useful only to such people who can use a program which processes the particular file format in a meaningful way. A plain text file is normally displayed as such by a browser, at least if the line length is reasonable (preferably less than 80 characters). The processing of a binary file might consist of displaying an image or animation, playing music, or doing some spreadsheet calculations, for example. This might take place within a browser or in a separate program launched automatically by a browser (when programmed to do so), or "offline" so that the Web browser is used just to retrieve the file and to save it into a local file, to be opened later by an application.
Example:
The budget proposal is available as a <A HREF="budget.zip">zipped Excel file</A>People using computers on which Excel is available will then be able to view your document on it. It depends on the browser and its settings how smoothly this can take place. Of course they also need some program (e.g. WinZip) for unfolding a .zip file, but such software exists for almost all environments and is very useful to have installed anyway. The reason for my suggesting the use of zipped format in problematic cases is twofold:
.zip
files appropriately,
telling browsers that they are binary files. Various application
program formats cause trouble much more likely, especially if the
particular format is not normally used in the computer system
on which the server runs.
For instance, the correct media type for an Excel file is
application/vnd.ms-excel
, but either your server
or user's browser might not recognize it.
You can use
a mailto:
URL in the HREF attribute.
of an A element.
Example:
My E-mail address is <A HREF="mailto:jkorpela@cs.tut.fi"> jkorpela@cs.tut.fi</A>.(Please avoid constructs like
<A HREF="mailto:
address">Mail me!</A>
which are useless e.g. when reading a paper copy of the document.)
Selecting such a link typically means that the browser invokes an
E-mail composer, with the recipient field prefilled.
It is not possible to prefill other fields in any reliable way.
See
question How do I specify a subject for a mailto: link?
in
WDG
Web Authoring FAQ.
Use forms
instead of simple mailto:
links
if you want to prefill something.
(I have written
a very simple example of such a form.)