Footnotes, endnotes, and sidenotes on Web pages

Content:

Footnotes are common in scientific and technical texts. In general, on Web pages they are best replaced by normal links, with link texts that reflect the content, such as in “Compare this to definition of ‘footnote’ in WWWebster”. No extra techniques are needed then.

On the other hand, when a document is printed, the linked documents will not be included, of course. Whether this matters depends on how essential the footnotes are and how feasible it is to print them separately. If you wish to include short footnote-like remarks into the document itself, you can put them at the end of a document and refer to them with internal links. That way the user can choose to follow such a link immediately to see the note, or read through the document, then check the remarks at the end. Alternatively, you could put the footnotes into a separate file and link to it.

The traditional footnotes have some benefits

However, if you are converting a print publication to Web format, or otherwise wish to use traditional-style footnotes, you might wish to consider using the technique described in this document. I will assume that numbers are used as footnote indicators. This makes it easy to associate the footnote references and the footnotes in printed documents. But naturally the references will not be descriptive at all, just pure labels. Besides, if you ever add a footnote, you would have to renumber all footnotes after it. Using author names or initials instead would make the references somewhat descriptive, at the cost of making them longer.

I will also assume that the footnote references are internal links. This by default makes them look different from normal text on screen. This may involve underlining. It’s debatable whether this is useful on screen (I think it is), but on print, it’s normally pointless and even disturbing. I assume that the footnotes themselves appear at the end of the page. Unfortunately it’s not possible to make the footnotes presented so that each footnote appears at the bottom of the printed page where the footnote reference appears.

Such simple footnote references are short, often very short like just “[1]” or even just “1”. Thus they don’t disturb normal reading much, on screen or on paper. Yet they clearly identify locations where the footnote information is available, either by following the link or by looking at the end of a print copy.

Using “[1]” style footnotes

If you number the footnotes consecutively, you can use footnote references like [1], [2], etc. To make them work as links, you naturally use markup like
<a href="#fn1">[1]</a>
when the link is internal. Make sure you don’t forget the “#” character! The appearance of the reference will depend on the presentation style of links [1].

This requires that the destination of the link is marked up, too. There are different ways to do this. The safest, i.e. the one that works on all browsers, is to use markup like the following:
<p><a name="fn1">[1]</a> footnote text</p>

The naming scheme of the “anchors”, like fn1, fn2, etc., is up to you, but would not recommend using just numbers 1, 2, etc. as anchors. The reason is that this would prevent you from using the id attribute for setting up the destination, since id values must not begin with a digit. And it seems that the use of name attributes for setting destinations will be deprecated in favor of the id attribute.

Linking back

There are various improvements that you could make to the simple approach suggested above. First, you could link back from the footnote to its reference, so that the user can easily get back to where he was, or just check what each footnote relates to [2].

Naturally this only works when there is only one footnote reference for each footnote, but this is the common case. And the markup is simple. The reference is something like <a href="#fn1" name="fr1">[1]</a>
and the footnote is correspondingly
<p>[<a name="fn1" href="#fr1">1</a>] footnote text</p>

It could be argued that the footnotes, especially when numbered consecutively, constitute a list, so that ol or ul would be the appropriate markup. However, various practical considerations favor the simpler approach of making them paragraphs (or sequences of paragraphs, if needed). In particular, you cannot make the number in an ol list a link, since the number is not part of document content, just presentation.

The brackets

You have hopefully asked yourself why I have put the brackets inside link markup in the footnote references but outside it in the “back” links. The explanation is that this avoids the problem that the page would have two links with exactly the same link text, pointing to different locations, thereby violating accessibility recommendations. Using the presence or absence of brackets for such a distinction is somewhat pathetic, but better than nothing. The use of numbers as link texts is bad for accessibility, but here we think we may have a reason.

Instead of brackets, other punctuation could be used, but brackets are probably the best shot. In theory, we could generate the brackets using generated content in CSS, but this is not supported my major browsers like IE. However, there’s a different approach: use just numbers as link texts, and set borders around the number using CSS border properties 3.

It has been argued that it is an established practice to use superscripts as footnote references and that this should be used on Web pages, too. The document Scholarship on the Web: Endnotes presents arguments for this view and demonstrates how it could be implemented.

If you omit the brackets, and especially if you make the footnote reference a mere superscript (in smaller font), it becomes pretty difficult to manage to click on the link with a mouse. This is especially problematic to people with minor motoric disabilities. (People with major motoric disabilities probably use keyboard navigation anyway.) Thus, I recommend that brackets be used at least in screen media. Unfortunately there is no simple way to make the screen presentation contain brackets and print presentation use e.g. just subscripts. In practice you would need extra markup in addition to a style sheet.

If you decide to use superscripts, note that this may sometimes cause confusion with mathematical superscripts, such as exponenents. Besides, there are presentational problems with superscripts, such as uneven line spacing, discussed in section Superscripts, subscripts, and exponents of the document Math in HTML (and CSS).

Preventing undesired line breaks

Naturally, a footnote reference should be kept together with preceding text, i.e. a line break before the reference is not acceptable.

If the footnote reference is preceded with a space, a browser could well split the line there, according to normal rules. This can be prevented by using a NO-BREAK SPACE, &nbsp;, instead. Example of markup:
...some text.&nbsp;<a href=...>[99]</a>

Thus, a space before the reference is not much of a problem. And such a space probably makes the appearance a little clearer, though this is partly a matter of taste. But whether you use a space or not, there is the problem that some browsers may break a line right before a left bracket, as explained in detail in the document Word division in IE and other notes on the nobr markup. The only safe protection is to use the nonstandard nobr markup, for example
...some <nobr>text. <a href=...>[99]</a></nobr>

The same problem exists if you use parentheses () instead of brackets around the footnote number.

Using title attributes to give a hint

Most modern browsers support the title attribute for various elements. It specifies an “advisory title”. For links, thus is best interpreted as giving a hint about the destination of the link, or providing a title-like description of it, as a “tooltip”. Typical browser implementation is a small popup text on mouseover. The classical description of this feature is Jakob Nielsen’s alertbox Using Link Titles to Help Users Predict Where They Are Going.

The “tooltip” implementation of title attributes is not very good in browsers. Partly for this reason, various other methods [4], usually JavaScript-based, have been suggested and used. For the most of it, they introduce quite some complexity without significant benefits.

How about frames?

Frames are evil. But for the presentation of footnotes, they might be a good idea if they were implemented well. You could view a document so that the window is divided into a main display area and a smaller area below it, for viewing the footnotes. Clicking on a footnote reference would position the footnotes document appropriately. This is faster and more convenient than normal links.

In this approach, the footnotes would appear in a separate document. It would be easy, in principle at least, to make the page work in no-frames mode too: clicking on a footnote link would just open the footnotes document in the same window, or in a separate window.

I have experienced a little with this approach, when converting a printed article of mine, Passiivin käytöstä, into Web format and adding some remarks as footnotes. Even if you don't understand the language (Finnish), you probably get an idea of how the approach would work.

However, the approach requires some extra work, and the gain is rather small. Besides, the implementation of frames in most browsers is poor, e.g. causing problems in printing.

Sidenotes as an alternative

Sidenotes are not common in books, and they are not used much on web pages either, but they might be rather suitable for web use. The reason is that usually the available width, though limited, is more than needed for normal text with a reasonable line length.

A sidenote is convenient to the reader, because it is available immediately, though in rare situations, horizontal scrolling might be needed. You don’t need to follow any link or even move the mouse, just move your eyes a bit. Admittedly, this means problems in nonvisual browsing, but we can arrange things so that in such a mode, the sidenote follows the main text that it relates to. This is usually an acceptable fallback.

A sidenote can be defined as an annotation text that appears on the right (or on the left) of main text. It is often presented in a different font face and size.

There are many possible approaches to including sidenotes on web pages. Having studied alternate methods like CSS positioning and floating, I have come to the conclusion that the simplest method gives the best results. This method consists of a two-column table, with the main text in one column, the sidenotes in the other.

This approach could be criticized for using “tables for layout”. However, the table involved is logically tabular data, just textual data. Not all tabular data is numeric.

Using the CSS methods, it becomes awkward to control the heights of pieces of text so that each sidenote starts at the same vertical position as the main text thet it relates to.

In practice, the markup can be rather simple:

<table class="annotated" summary=
"Text with annotations in the second column.">
<tr><td>Piece of main text.</td>
    <td class="sidenote">Sidenote</td></tr>
 ...
</table>

This works even without stylesheets, though with insufficient horizontal spacing between the text and the annotation and with no font difference between them. It is however probably best to do all formatting in a stylesheet, because that’s much simpler than adding presentational HTML.

Note that the width of the table or the columns (cells) is left unspecified in HTML. They could even be left unspecified in CSS, letting browsers divide the available width between the columns according to their width requirements. This usually works rather well, if the amoung of text in the sidenotes is much smaller than the main text.

You would use paragraph markup and other markup normally in the cells of the first column. For a paragraph with no associated annotation, you could use a row with an empty second column, or you could put the paragraph into the same cell as the preceding paragraph.

For basic styling of a table containing text and annotations, you could use the following stylesheet:

table.annotated td { vertical-align: top; } /* Align top of sidenote with top of text. */
table.annotated td.sidenote { /* For the sidenote column…*/
       font-family: Arial, sans-serif; /* use Arial (& something else for copy), */
       font-size: 90%; /* reduce font size by 10 %, and */
       padding-left: 2em; } /* create 2em spacing on the left. */

You might consider setting some specific width, such as 15em, for the column of sidenotes. This would be suitable especially if you break the table, for some interspersing elements like headings and tables, since without a width settings, the sidenote column widths would vary. You could even set table-layout: fixed for the table to speed up rendering. Without that setting, a large table takes a long time to get rendered, since the browser has to read and format the entire table before being able to display any of it.

Typically, 15em is quite sufficient when the sidenotes are short explanations.


Remarks

An internal link is, in this context, a link that points to a location on the same page. That is, it means a “jump” inside the page. The phrase often denotes a broader concept, namely a link that points to somewhere within the same site (whatever that means in detail).

From the usability point of view, internal links have been criticized for not being suitable on the Web, where the common idea and concept is to link pages rather than parts of pages. See Jakob Nielsen’s alertbox Avoid Within-Page Links.


Footnotes to this document

[1] The common browser default for link text appearance is underlined text, in blue color if the link is unvisited, magenta if it has been (recently) visited. For internal links, browsers differ in their interpretation of “visiting”. Some browsers automatically treat all internal links as visited, on the grounds that the page has been accessed. It is generally best to avoid trying to interfere much with the default rendering of links. This is explained in detail in the document Links Want To Be Links.

[2] In HTML, a link is inherently directed, one-directional, from one point to another. To connect two points or elements in both directions, you need to set up two links, and you need two anchor names for that. Note that following the “back” link, you get to the footnote reference, i.e. past the text it really relates to, since browsers typically position the document so that the destination is at the very top of the canvas. You may wish to consider a more elaborate scheme where the destination of the “back” link is a separate anchor at the start of the text that the footnote relates to.

[3] For information on CSS, check the document How to write style sheets (CSS). In this approach, you could assign the same class attribute to all footnote references, e.g.
<a href="#fn3 name="fr3" class="fn">3</a> and use a style sheet like the following:

@media screen {.fn {  border-style: solid;
                      padding: 0 0.06em;
                      border-width: 1px 2px; } }
@media print { .fn {  vertical-align: super;
                      font-size: 70%; }
               body { line-height: 1.4; } }
Note that this approach makes the footnote references appear as superscripts in print media.

[4] The above-mentioned document Links Want To Be Links contains the section “Animating” links, which illustrates some of the methods. The simplest method is probably to write some explanation (either the same as the title text or a different formulation, or different content) onto the browser’s status line, e.g.
<a href="#fn42" name="fr42" title=
"Notes on Albert Einstein"
onmouseover="window.status='A very short biography of Einstein, with emphasis on human interest matters'; return true"
onmouseout="window.status=' '; return true"
>[42]</A>

However, it is widely regarded as inappropriate to play with the status line, or generally to break the normal user interface of browsers so this approach cannot be recommended, except possibly in special occasions after careful consideration. (The preceding link is accompanied with code that illustrates changing the status line, so that you can see how it hides essential information, the URL.)