On 2011-12-06, Rob Oakes wrote: > On Dec 6, 2011, at 4:39 PM, Richard Heck wrote:
>> I wonder if we'd be better just outputting footnotes as endnotes >> all the time. The inline version we now use is cool, but maybe it's too >> cool for it's own good. > I actually think that would be a really good thing. It makes everything > much easier to work with. (Or at least, that's what I think.) IMV, we should make the placement of footnotes in HTML configurable. Sensible options include a) inline (as "tooltip" via CSS :mouseover:) b) in the footer for page-based output (e.g. print from HTML or ePub) c) endnotes (before/after other concluding sections and listings?) d) per chapter/section/subsection e) author-specified position via an inset A simple interface would be a "footnotes-inset" that triggers the output of all footnotes with footnote-references between the start of the document or the last "footnotes-inset" and its position. It can be used for all options above if set by the document author accordingly: a) no "footnotes-inset" b) no "footnotes-inset" and CSS rules for page-based media c) one "footnote-inset" at the position the endnotes shall appear (similar to the toc and bibtex-references buttons). This could also be used for LaTeX output together with foot-to-end. d) one "footnote-inset" at the end of each chapter/section/subsection ... e) "footnote-inset" whereever the footnotes shall appear (below a list, paragraph, table, ... To accomodate e) and common behaviour in minipages and floats, the idea of "all footnotes ... between ..." could be augmented with "scopes" - a footnote-inset inside a minipage or float would only apply to footnotes defined in the same object. If there is user-request, the default case (no footnote-insets) could be made configurable (inline vs. end vs. section-level) but I don't know if the complication is needed, as in most cases the actual placement of the endnotes requires author control anyway. >> That suggests the idea of "collecting" the footnotes along the way in >> some kind of structure, and then emptying it when it comes time to >> print them, which could then be at any time. Yes. >> Second, I've been thinking recently about introducing some sort of >> chapter splitting capability. Not so important for e-books probably, but >> useful for the good old web. > And very useful for eBooks as well. Due to the way that ePub works, at > least, smaller HTML files load faster. Actually, it should be an option not only for chapter splitting but also for other sectioning level. Again, one yould argue that mapping a parent/children document set on a one output file per input file basis is sufficient. Thanks for your work, Günter
