RE: Footnotes in HTML3: questions/proposals

Keith Rogers writes:
>Any of these solutions seriously limits the use of footnotes
>for the HTML author.  Maybe the new media of web-based documents should
>open up the possibility of much wider footnoting.  In paper-based documents,
>footnotes are used sparingly so as to avoid cluttering up the pages with
>information that not everyone needs or wants.  In an electronic document,
>no one need read any information they do not want, so footnotes could be
>used in a much wider sense to make text more accessible to all readers.
>Footnotes could be used to explain acronyms or technical terms, to identify
>people mentioned, etc.

What you are describing are not footnotes. They are some other kind of
document element. It sounds like you are describing variations on a glossary.
So what is needed is not to pollute the concept of the footnote, but to
include the concept of a searchable glossary.

In actual fact, the implementation of footnotes in HTML 3.0 is very flexible.
It works like this:

- The footnote is defined with an ID attribute that identifies it.

  <fn id="fn1">
  The framiture is adjacent to and orthoganal with the burbawitz.
  </fn>

- References to a footnote are simply anchors.

  Attach the <a href="#fn1">framiture</a> as illustrated.

There is nothing that would prevent an HTML author from marking all occurances
of "framiture" as an anchor that links to an explanatory footnote. However,
it sounds like you are trying to avoid excessive markup of a document, which
is fine. However, modifying the designed purpose of <FN> is probably not the
way to do it. There is already a "glossary" link relation:

  <LINK rel="glossary" href="myglossary.cgi">

If the glossary can be assumed to be searchable, then it is up to the browser
implementor to provide a means of searching a glossary. It could be as simple
as providing a button on a toolbar that allows the reader to enter a search
term, or it could be as fancy as interpreting a SHIFT+CLICK to mean that the
word under the pointer should be submitted for a glossary search. Or both.

How the browser presents the results of the glossary search is also not
specified. It could treat it as a regular document, or it could recognize
that this is a special case and do something else, such as put the results
in a pop-up (balloon) window.

This is the right way to do the kind of thing you want to do.

[omitted]
>
>Now, having said that, it is quite possible that I am missing something
>fundamental and my argument does not hold water.  If you think this is
>so, please instruct me as to where I have gone wrong.  If you think I
>have made a legitimate point that others might be interested in, let me
>know and I'll post this to the mailing list.

I think the fundamental thing that you are missing is that if you see a need
for a document element that seems to be missing from HTML you should probably
ask yourself how that element should be designed and propose that element,
rather than proposing changes to the HTML spec that either pollute the concept
of an existing element or that suggest dictating mechanism to browsers.

In the case of your example, what you are really looking for is not a document
element at all, but a concept of a relationship between documents. As it
happens, an element to describe relationships between documents already
exists in the form of the <LINK> element and the specific relationship that
you described has already been defined in the HTML spec.

There's a convention in technical writing that the defining instance of a
term (usually the first instance) is in italics. HTML 3.0 defines a <DEF>
style element. The HTML specification could be augmented to state that words
or phrases that appear in a <DEF> element can reasonably be expected to be
found in a glossary search, if a glossary is defined for the document. This
would not dictate mechanism to browser implementors, nor would it force
authors to limit glossary terms to those that appear in <DEF> elements.

Michael Johnson
Relay Technology, Inc.

Received on Wednesday, 28 June 1995 08:36:43 UTC