Dave Cramer wrote:
> In print publishing, a footnote consists of two parts: a reference
> (often rendered as an asterisk or superscripted number) and the
> footnote body.
>
> Footnotes themselves can be quite complicated. Footnotes can
> contain multiple paragraphs, block quotes, lists, and tables.
> Footnotes can contain other footnotes (an edge case, admittedly,
> but we publish David Foster Wallace, who is notorious for this).
> Footnotes can extend across multiple pages. In short, a footnote is
> a container that can hold almost anything.
Yes. To add to the list of examples, I just read a novel that consist
only of footnotes. If it was available in English, the title would
have been something like "Armand V.: Footnotes to an unexplored
novel". It's only available in Norwegian and German, it seems:
http://www.oktober.no/Boeker/Pocket/Pocket-skjoennlitteratur/Armand-V.-Fotnoter-til-en-uutgravd-romanhttp://www.amazon.co.uk/Armand-Fussnoten-einem-unausgegrabenen-Roman/dp/3908777410
> In order to describe footnotes in HTML, we've been forced to
> separate the footnote reference (which is an inline element) from
> the footnote itself, as HTML frowns on placing complex block
> structures inside paragraphs. This is quite different from
> something like DocBook, where the content model allows a footnote
> element inside a paragraph, and that footnote can itself contain
> multiple paragraphs, etc.
In the past GCPM has sketched a solution where structured elements are
pulled in using the 'target-pull()' function -- much like
'target-counter' fetches the value of a counter from the end of a
link. You can see it here:
http://people.opera.com/howcome/2013/gcpm/06-27.html
> We'd typically code:
>
> <p>It was the best of times, it was the blurst of times.<span class="ref-footnote-rw">*</span></p>
>
> <div class="block-rw footnotes-rw">
> <p><span class="num-footnote-rw">*</span>Oh yes, but the telephone is so impersonal.</p>
> <p>I prefer the hands-on touch you only get with hired goons.</p>
> </div>
>
> Since we separate the footnote reference from the footnote, we
> can't use the built-in footnote handling in Prince (which I believe
> is very close to what is described in GCPM). So we suppress the
> ::footnote-call and ::footnote-marker pseudo-elements, and create
> our own counters.
>
> div.footnotes-rw { float: footnote; }
>
> div.footnotes-rw::footnote-marker {
> display: none;
> content: none;
> }
> div.footnotes-rw::footnote-call {
> display: none;
> content: none;
> }
>
> etc.
>
> So I'm concerned that a model where all the content of a footnote
> must be placed inline at the point of reference (as in all the
> examples in GCPM) will only work for the simplest cases.
Indeed, the current ED will only support simple, common footnotes; its
functionality has been pruned down to only describe what
implementation support. I'm open to adding more and pulling in
elements make sense to me. Would this code work for you?
To support legacy browsers, it is often better to make a link to the
note rather than including the text inline. This example shows how
to fetch the content of a note and place it in a footnote.
<style>
@media print {
.footnote {
float: footnote;
content: target-pull(attr(href url)) }
.call { display: none }
}
</style>
...
<p>A sentence consists of words<a class="footnote" href="#words"> *</a>.
...
<p id=words><span class="call">*</span> Most often.
When displayed in a browser, the asterix would be clickable and the
foonote would come up. When formatted with a footnote-aware UA, the P
element -- with all its style and structure -- would be placed in the
footnote.
> Some books (The Bible) have so many short footnotes that the
> footnotes themselves need to be displayed inline. Other books
> (Shakespeare) may have two separate streams of footnotes, requiring
> two footnote regions. Prince has implemented inline footnotes, with
> float: prince-inline-footnote | prince-inline-column-footnote. That
> reminds me that there's also the question of whether the footnote
> region is confined to a single column, or spans all columns. Again,
> Prince has float: prince-footnote | prince-column-footnote.
This differs somewhat from what GCPM ED proposes; rather than
describing the footnote area on the footnote elements, it proposes to
do so on the @footnote area:
These rules place the footnote area at the bottom of the page, spanning all columns:
@page {
@footnote {
float: bottom;
column-span: all;
}
}
If you prefer to have footnotes in columns, you could do:
@page {
@footnote {
float: bottom;
column-span: none;
}
}
Still, the spec doesn't say whether footnotes should appear in:
- one footnote area at the bottom of the first column, or
- footnote areas at the bottom of each column, possibly with
- flow from one footnote area to the next
Whether footnotes are block-level or inline must also be determined.
The previous ED said:
The 'display' property on footnote elements is ignored. Instead, the
value of the 'display' property in the @footnote context determines
if footnotes are block or inline elements.
http://people.opera.com/howcome/2013/gcpm/06-27.html
This still makes sense to me -- you wouldn't want to combine inline
footnotes with block-level footnotes, would you?
-h&kon
HÃ¥kon Wium Lie CTO Â°Ã¾eÂ®Âª
howcome@opera.com http://people.opera.com/howcome