[whatwg] Footnotes, end notes, side notes

[Ian Hickson]

I haven't added any new markup for footnotes or end notes. Side notes 
without callouts in the main flow are possible with <aside>.

For footnotes and end notes there have been a number of proposals, such 
as the following (and variants on them):

   text text <footnote> note note </footnote> text text

   text text <a href="#fn1" target=footnote>1</a> text text
   <footnote id=fn1> note note </footnote>

   text text <a href="#fn1" rel=footnote>1</a> text text
   <div id=fn1> note note </div>

   text text <fn xref=fn1/> text text
   <footnote id=fn1> note note </footnote>

   text text <ref to=fn1>fallback> text text
   <footnote id=fn1> note note </footnote>

None of these are really compelling, in my opinion. None have the 
"awesome" factor that really makes it likely that UAs will ever implement 
them well. None are especially compellingly better than the currently 
available options:

   <span title="note note">text tex text text</span>

   <p>text text</p>
   <aside> note note </aside>
   <p>text text</p>

   text text <a href="#fn1" id="r1" class="footnote">1</a> text text
   <div id=fn1><a href="#r1">↑</a> note note </div>

I have added a section showing examples of how to use these.

Having said that, here are more detailed comments in response to the 
feedback provided:

On Tue, 31 Oct 2006, Michel Fortin wrote:
> 
> I'm all for a syntax for footnotes (and sidenotes, and endnotes). The 
> question is what do we want a footnote markup to accomplish? Minimally, 
> it should associate a note with its context so that you know there is a 
> note and that you can refer to it if you want. This definition encompass 
> a couple of methods to do such notes that are in use currently, in HTML 
> and elsewhere.
> 
> 1. One of them, mostly used with sidenotes, is to have the note directly 
> in the text:
> 
>     <p>Some text <span class="sidenote">this is a sidenote to put
>     in the margin</span> and some other text.</p>
> 
> With pretty trivial CSS, you can then put all the sidenotes in the 
> margin. With some javascript[1], you can also create a list of footnotes 
> at the bottom of the page. This method is also consistent with how word 
> processors treat footnotes: as distinct pieces of text inserted 
> punctually at some place in the main text but which are rendered 
> elsewhere.
> 
>  [1]: http://www.brandspankingnew.net/specials/footnote.html

With <aside>, you can do this, though not directly in a paragraph. If you 
use more markup, you can make this work today with fallback:

   <p>Some text <span class="sidenote"><span>(</span>this is a sidenote to 
   put in the margin<span>)</span></span> and some other text.</p>

It might require some tweaking, but you get the idea.


> 2. Some syntaxes meant to be written directly by humans, like Latex, 
> also allow you to defer the note content until a later time to make 
> things more readable. In these cases, you put a marker in the text, then 
> associate the marker with the note content which can be placed elsewhere 
> in the document. This make the text more readable. My own text-to-HTML 
> tool (PHP Markdown Extra, semi-private beta version 1.1) use such a 
> syntax:
> 
>     Paragraph linked to a footnote[^1].
> 
>     [^1]: This is the footnote content.
> 
>     Some other paragraph.
> 
> I'm not aware of anyone doing this for footnotes or sidenotes in HTML; 
> it doesn't seem very practical to style either.

You could do this with aside:

   <p>Paragraph linked to a footnote<a href="#fn1" id="r1">[1]</a>.</p>

   <aside id="fn1"><a href="#r1">[1]</a>: This is the footnote 
   content.</aside>

   <p>Some other paragraph.</p>


> 3. The last method of expressing footnotes in HTML is to create markers 
> in the text and put the footnotes in an ordered list at the bottom of 
> the page. For instance, my text-to-HTML tool generates this markup from 
> the above example:
> 
>     <p>Paragraph linked to a footnote
>        <sup><a id="fnref:1" href="#fn:1" rel="footnote">1</a></sup>.
>     </p>
> 
>     <p>Some other paragraph</p>
> 
>     <div class="footnotes">
>     <hr />
> 
>     <ol>
>     <li id="fn:1">
>        <p>This is the footnote content.
>           <a href="#fnref:1" rev="footnote">↩</a>
>        </p>
>     </li>
>     </ol>
>     </div>
> 
> This provides a trivial way to style footnotes as footnote, it'll even 
> looks good unstyled and is completely backward compatible.

Indeed. (Though I might quibble on the precise structure.)


> Before defining a markup for footnotes or sidenotes, I think it'd be a 
> good idea to see what goals the syntax should fulfill. Is backward 
> compatibility one of them, or should we always rely on the browser 
> capabilities to relocate footnotes where they should be, or should we 
> allow both?

Both seem good.


> Some other things to take into consideration:
> 
> * Footnotes should probably not be allowed to escape their enclosing 
> article element. For instance, if you have a couple of weblog articles 
> on your main page, each article having some footnotes, it'd probably not 
> be a good idea to have footnotes from all articles mixed together in the 
> same list.

Makes sense. You'd want footnotes scoped to <article>, and end notes 
scoped to the nearest sectioning element, probably.


> * Although not necessarily very common, some people like to put multiple 
> paragraphs, lists, and some other block-level elements in footnotes and 
> sidenotes (more often seen in sidenotes in books). I think it'd be a 
> good idea to allow that in the markup.

Fair enough.


> * Sidenotes may not be achievable in the browsers's default stylesheet 
> without adding a side margin. They could always be displayed as float, 
> but it seems to me that footnotes would be the best fallback mechanism. 
> Sidenotes are also impractical on small screens too. That's why I 
> believe that, ideally, footnotes and sidenotes should share the same 
> markup, styling is what should make the difference.

Agreed.


> I'm not yet proposing any markup, I want to start the discussion on what 
> it should accomplish, and what is realistic.

I agree with your analysis. I'm not sure where to go from there, though.


On Tue, 31 Oct 2006, James Graham wrote:
> 
> I think and distinction between footnotes, sidenotes and endnotes is 
> basically presentational and whilst we should try to ensure that 
> markup+CSS can create all three appearances we shouldn't treat them 
> distinctly.

Agreed.


On Tue, 31 Oct 2006, Alexey Feldgendler wrote:
> 
> The drawback of the tranditional markup is that it requires knowing the 
> ordinal number of the footnote in advance.

That could be done from CSS, too.


On Tue, 31 Oct 2006, James Graham wrote:
> 
> Indeed. I think HTML would benefit from some general solution for 
> providing numbered references (indeed, I brought this up before), not 
> just for footnotes but also for e.g. sections, elements in lists, 
> bibliographies, etc. One can imagine simple markup like
> 
> <ref to="idref">fallback content</ref>
> 
> but I think there are issues with parsing documents containing such 
> references.

Yeah. CSS will provide this kind of thing, but do we need markup to 
support it?


[Snip a discussion on how footnotes would be rendered in various UAs.]

On Tue, 31 Oct 2006, David Walbert wrote:
> 
> "Sidenotes," though, is ambiguous. If the term refers to footnotes that 
> happen to be placed beside the text, then yes, they're identical 
> semantically to footnotes. But "sidenotes" may also refer to "pull 
> quotes" or "callouts" -- some small piece of text to be highlighted 
> rather than additional explanatory information of the sort that would 
> appear in a sidebar or footnote. Or, if "sidenote" refers to what is 
> usually called a "sidebar," then we're talking about something that is 
> both more extensive than the typical footnote and of greater importance 
> relative to the main text -- its position on the side of the page is 
> rather than at the bottom is not merely presentational but is indicative 
> of the weight of the content. Moreover, a callout or sidebar is not a 
> numbered or marked reference and need not be referred from a precise 
> location within the text -- whereas a footnote or endnote relates to a 
> specific word, sentence, or paragraph, a sidebar/callout/pullquote 
> relates more vaguely to a more general section of text, or in the case 
> of some sidebars, to the full article.
>
> So while markup for footnotes/endnotes could be standardized fairly 
> easily (in as much as writing standards is ever easy), I don't even know 
> where I would begin to define sidenotes semantically. As I've used them 
> in print and on the web, they'd need to relate to (1) a header, and 
> therefore to the section of text underneath it; or (2) a paragraph, 
> list, or other defined block of text. But a sidebar might need to 
> contain block-level formatting (and even multiple paragraphs and 
> potentially headers), which means it couldn't be placed inside one of 
> those elements.

<aside> and <nav> are intended to address these use cases.


[snip various e-mails about the CSS proposals]


On Tue, 31 Oct 2006, Michel Fortin wrote:
> 
> Interesting. If I understand well, this CSS proposal would allow a note 
> inserted in the middle of a paragraph to become a footnote. For instance 
> this:
> 
>     <p>This paragraph has a footnote<footnote>This is a footnote</
>     footnote>.</p>
> 
> could be presented like this (where 1 is presumably superscript and 
> linked to the footnote):
> 
>     This paragraph has a footnote1.
>     ______________
>     1.  This is a footnote.
> 
> That'd very interesting. But the markup is poor for backward 
> compatibility and makes it difficult to include more than one paragraph 
> in a note. So I'm going to propose an improvement to this markup.
> 
> (For the next example: <fn> = footnote; <fnref> = footnote reference.)
> 
> What is needed to solve the backward compatibility problem is a second 
> way of indirection, so that the footnote can be placed elsewhere. This 
> is the first piece of the puzzle:
> 
>     <p>This paragraph has a footnote<fnref for="my-footnote"></fnref>.</p>
> 
>     <fn id="my-footnote">
>       <p>This footnote can contain block-level elements!</p>
>     </fn>
> 
> In this example, a reference to the footnote is found in the paragraph, 
> and the footnote content is elsewhere in the document. The browser would 
> be in charge of numbering the marker correctly (or not, if the 
> stylesheet says so) and to put the referenced footnote in a list with 
> the other footnotes in the order they are reference.
> 
> Notice the empty content of <fnref>? That's substitution content for 
> backward compatibility: if you put a link to the footnote within the 
> <fnref> element, when displaying things as footnote the actual content 
> is substituted by the marker, but footnote-unaware browsers will show 
> the link. In the previous case, the fallback content for the reference 
> marker could have been:
> 
>     <sup><a href="#my-footnote">1</a></sup>
> 
> Since footnotes are referenced and reordered, you're free to place them 
> wherever you want. If you care about backward compatibility, you should 
> put them all together at the end of your article and there you have your 
> list of footnotes. Footnotes without reference are considered to be 
> referenced from where they are in the source. Or if you want them to be 
> styled as sidenotes, just put the notes before or after the paragraph 
> they relate to in the source, or even inline inside paragraphs (although 
> inline footnotes should be restricted to inline content), and hide the 
> marker.
> 
> The last piece of the backward compatibility puzzle is the <fnl> 
> (footnote list) element. This element is optional, but if present, 
> preceding footnotes inside the same sectioning element will be relocated 
> inside this element. <fnl> would be styled as an ordered list, and its 
> list items would be footnote elements (<fn>).
> 
>     <p>This paragraph has a footnote<fnref for="my-footnote"
>        ><sup><a href="#my-footnote">1</a></sup></fnref>.</p>
> 
>     <fnl>
>     <fn id="my-footnote">
>       <p>This footnote can contain block-level elements!</p>
>     </fn>
>     </fnl>
> 
> I suggest that footnotes be relocated at the end of the first <article> 
> element, or to the first <fnl> element following them in the source. It 
> goes without saying that footnotes already inside <fnl> stay where they 
> are, although they should be reordered in the order they are referred to 
> in the text.

At this point, why not simplify the markup and remove the <fnref>? And 
turn the <fnl> and <fn> into a <section> and some <div>s or something and 
you have backwards compatible markup that already does everything we need 
without sacrificing any of the stylability...


On Mon, 6 Nov 2006, Matthew Raymond wrote:
> 
>    I have a similar view, although I have some refinements:
> 
> | <p annotation="my-footnote">
> |   This paragraph has a footnote
> |   <a rel="annotation" href="#my-footnote"><sup>[1]</sup></a>.
> | </p>
> | [...]
> | <footnote>
> |   <p>References:</p>
> |   <al>
> |     <ol>
> |       <li id="my-footnote">
> |         <p>This footnote can contain block-level elements!</p>
> |       </li>
> |     </ol>
> |   </al>
> | </footnote>
> 
>    In the example above, |annotation| serves the same purpose as the 
> <fnref> element. This allows you to associate an entire block of text to 
> the annotation rather than just a single point. The <footnote> element 
> is there to allow more extensive content than a simple list. The <al> 
> element is a list for annotations. It handles the <ol> element in the 
> same way <datalist> handles <select>, making <ol> only significant for 
> fallback purposes. Because <al> is a list, it can take straight <li> 
> elements.
> 
>    The <a hrel="annotation"> and its contents, when the child of an 
> element that has an |annotation| attribute, can be ignored by the user 
> agent and replaced with an annotation-specific presentation. If the 
> |annotation| attribute is left off, the user agent can assume that the 
> parent of an <a rel="annotation"> element is the context of the 
> annotation.

This seems even more complex...

[snip various other problems with the above proposal]


On Mon, 6 Nov 2006, Sander Tekelenburg wrote:
> 
> What I miss in this is something to help users return from the footnote 
> to where they were in the main text. I think we need to consider that a 
> requirement. What about a rev="my-footnote" attribute on the al list 
> item, to allow UAs to offer users a mechanism to return to where they 
> came from? (Downside would be that this would revive that old rel/rev 
> can of worms...)
> 
> Another thing is that whether the annotation should be considered a 
> footnote, endnote or whateverelsenote seems to me a presentational 
> issue, so I'm not that enthusiastic about calling it a <footnote> 
> element. Why not simply <annotation>? You can then allow the author to 
> decide where in the page, or in a group of pages, to place the 
> <annotation> element, and use CSS for the presentational aspects. (You 
> could allow the same with <foonote>, but that name suggest it must only 
> be used for footnotes.)

Of course annotations bring in even more people with even more opinions 
and soon if we're not careful we end up with an over-generalised system 
that can't do footnotes. :-)


On Sun, 5 Nov 2006, Martin Atkins wrote:
>
> It seems to be that the visual continuous media equivalent of a footnote 
> is something like a tooltip or pop-up box containing some text. It'd 
> only be displayed when the user requests it, by clicking on or hovering 
> over it. Paper documents permanently display the footnotes only because 
> of the limitations of the media.
> 
> Doing click-to-view "footnotes" with current CSS is tricky, but doing 
> hover-to-view is reasonably straightforward using some trickery with the 
> :hover pseudo-class and display:none, as long as the footnote content is 
> inline.
> 
> Reverting to traditional footnotes for print media based on the same 
> markup is not straightforward, however. The CSS3 support for shuffling 
> elements about would do it, but we're not there yet.

I think the CSS stuff is less of a big deal than you make it out to be, 
but I agree in general with those comments.


On Tue, 31 Oct 2006, Jonathan Worent wrote:
>
> I came across an article by Jesper Tverskov titled The benefits of 
> footnotes in webpages. (http://www.smackthemouse.com/footnotes) It may 
> be of interest.

Thanks for hte link.


On Wed, 1 Nov 2006, Sander Tekelenburg wrote:
> 
> IMO the problems with the title attribute he lists are in fact browser 
> implementation poverty, not title attribute problems. Same for his 
> arguments for "footnotes".

On Wed, 1 Nov 2006, Lachlan Hunt wrote:
> 
> That's true, but they are all real world, practical problems which still 
> haven't been solved in the past 10 years and there's no evidence to 
> suggest that the situation will change any time soon.

On Wed, 1 Nov 2006, Michael(tm) Smith wrote:
> 
> Whatever browser implementation poverty there might be in handling of 
> the title attribute, the fundamental deficiency is that basing a 
> mechanism for displaying annotations on an attribute value limits the 
> content of the annotations to text. Annotations that can't even contain 
> simple character formatting are useless for anything except the simplest 
> purposes.

All good points.


On Wed, 1 Nov 2006, Lachlan Hunt wrote:
> 
> It would useful to look at previous work and discussion on this issue.
> 
> http://www.cs.tut.fi/~jkorpela/www/fn.html
> http://www.w3.org/MarkUp/html3/footnotes.html
> http://www.sagehill.net/docbookxsl/HTMLFootnotes.html
> http://daringfireball.net/2005/07/footnotes
> http://daringfireball.net/2005/08/notes_on_notes
> http://www.quirksmode.org/blog/archives/2005/07/footnotes_on_th.html
> 
> Also, Wikipedia's markup for footnotes is good example of current 
> practice and also a good use case for them.

Interesting articles.


> > One thing to consider when looking at footnotes is "would the title="" 
> > attribute handle this use case as well as what I'm proposing?". If the 
> > answer is "yes", or "almost", then it's probably not a good idea to 
> > introduce the new feature.
> 
> I really don't think so.  There are accessibility and usability issues with
> the title attribute.
> 
> * Screen readers don't read the title attribute by default.
> * Tooltips are inaccessible (in current implementations) to keyboard users,
> they require hovering with a mouse.
> * Users have no clear way of identifying which content has a tool tip, except
> for maybe abbr and acronym (which get a dotted border in FF).
> * It's also limited to plain text, when even the example from wikipedia
> contains additional markup.
> 
> The first 3 issues could possibly be addressed by changing the 
> rendering, but how do you identify a regular title attribute from one 
> intended to be a footnote?  Would it be appropriate for all of them to 
> be treated as footnotes? I don't think so.

Wouldn't it?


> James Graham wrote:
> > I think and distinction between footnotes, sidenotes and endnotes is
> > basically presentational and whilst we should try to ensure that markup+CSS
> > can create all three appearances we shouldn't treat them distinctly.
> 
> I agree that the distinction between footnotes and endnotes is just 
> presentational.  But I'm not so sure about sidenotes.  We'd really need 
> to look at books that make use of them and see on what basis authors 
> actually decide to use footnotes or sidenotes.  Do some authors use 
> footnotes and sidenotes in the same book, or they exclusively choose one 
> over the other based solely on presentation?
> 
> Also, it wouldn't particularly matter if footnotes ended up being 
> rendered as endnotes in printed media (which is how exisiting browsers 
> render the wikipedia-style markup) but it would be nice if browsers 
> could render them as footnotes at the bottom of each page.

That's mostly a CSS concern.


On Thu, 30 Nov 2006, Benjamin Hawkes-Lewis wrote:
>
> I've been meaning to send a rambling discussion of annotations to either 
> the www-html or whatwg lists at some point. However, I would vehemently 
> stress that it is not that uncommon for notes and marginalia to 
> themselves have notes or marginalia, and it would seem particularly odd 
> to allow that in the limited space of paper but not the free expanse of 
> hypertext.

The mechanisms described can be used in this way (well, other than 
title=""s inside title=""s).


> When an author cannot got hold of a work herself, she must sometimes 
> cite a citation of that work in second work. This is what the 
> abbreviation cit. is for. And sometimes a citation refers to more than 
> one version of a work. Here's an example out of the Oxford Style Guide:
> 
> J. D. Denniston, /The Greek Particles/ (Oxford, 1934; citations are from 
> the 2nd edn., 1954).
> 
> Without more clarity (and that partly means examples) on how <cite /> 
> should apply to the complexity of real academic citations, I'd avoid 
> making the assumption that <cite /> cannot contain <cite /> -- for now.

<cite> is now defined to mean "title of work".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'