Subject: RE: Footnotes in HTML3: questions/proposals Message-Id: <MICHAELJ.email@example.com> From: firstname.lastname@example.org (Michael Johnson) To: email@example.com (HTML discussion list) Date: Wed, 28 Jun 95 07:57:55 EDT 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.