Links (often called hyperlinks) are the feature which justifies the HT in HTML (HyperText Markup Language).
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.
I have worked at <A HREF="http://www.hut.fi/english.html">HUT</a>.
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.
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).
Include explanatory text e.g. in parentheses after the link. This works more universally than the other ways, which are not very widely supported by browsers yet, but it often looks clumsy and redundant.
Include a REL attribute into your A element. This is a good idea if there is a suitable REL value for the purpose, e.g. REL=Glossary when the linked document is a glossary for the current document.
Include a TITLE attribute into the A element. See Jakob Nielsen's excellent alertbox Using Link Titles to Help Users Predict Where They Are Going .
<A TITLE="The official specification of the Internet E-mail protocol"
<A TITLE="Requirements for Internet hosts"
in Finnish, with a short summary in English"
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.
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=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.
Avoid excessive linking. If every word in your document is a link, the reader does not know which are the useful links.
When you use e.g. an abbreviation or technical term which is not explained in your document, try to find a suitable document which gives some explanation to which you can link. (In this context, you might use a TITLE text which is simply an expansion of an abbreviation. This might suffice to many readers, so that they need not follow the link.) Whether this should be made at the first occurrence only or at every occurrence depends on the circumstances.
Similarly, it is often a good idea to link to organizational and personal home pages (if available) when mentioning an organization or person.
Naturally, when citing a document, provide a link to its online version (or at least to online bibliographic information about it) if such information exists on the Web.
Often you have "footnote-like" information which you wish to make available via the Web but which is of less importance (to most readers at least) than your main document. As an alternative to using the SMALL element, consider making it a separate HTML file (or set of files) and attach e.g. a Further reading section to the main document, providing suitable links. This applies especially to technical details which might be useless and even irritating to the majority of your readers, yet valuable to some readers.
If you would like to link to several documents from a point (e.g. when mentioning a computer program name, you would like to link to a short description of it, to a full manual, to an FTP site for downloading etc.), create a small file containing those links with suitable explanations and link to it. This gives you the additional option of providing links to copies of the same information, such as downloading links to alternate FTP sites.
Try to make the link text short but descriptive.
Link to relevant and reliable information only. Linking to bad-quality documents might be worse than no links, since people would waste their time with them instead of searching for newer and better documents on the Web.
When referring to issues outside your main themes, try to link primarily to short, clearly written documents which contain links to more detailed and technical information. For example, avoid linking directly to an ISO standard or an RFC in a document written for a wide audience.
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.
Web servers can usually process .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.
Zipping can save time and space, and it can be used to pack several closely related files (such as a binary program and its documentation and data files) into a single file, making downloading easier and faster.
In principle, a link can refer to other Internet resources as well, such as a Usenet newsgroup, an E-mail address, or a file in an anonymous FTP server. See the description of URLs for the syntax as well as some remarks. Here we will discuss just one special case, links to E-mail addresses.
Next part: Images, formulas, etc.