Tab Atkins Jr.
jackalmage at gmail.com
Mon Dec 15 14:38:52 PST 2008
On Mon, Dec 15, 2008 at 4:18 PM, Brenton Strine
<Brenton.Strine at citrix.com> wrote:
> Maybe after having a few months to think about it some better ideas will pop up?
> I'd like to see a dedicated way to do footnotes as well. I think it would be worth having the discussion again.
Well, as far as I can tell the issues are the same as last time, and
the solutions are the same as what Ian summarized. Any markup that
physically separates the footnote from the reference can be achieved
equally well with <a> and <ol> without an increase in markup, and with
perfect backwards compatibility. An explicit solution could make
things *slightly* easier, by auto-numbering the references and
requiring only a single #id (from the reference to the footnote,
rather than requiring ids on both to have links pointing both ways),
but it's not evident that this is enough of a benefit to justify an
entirely new element.
Any solution that keeps the footnote near the reference in the markup
and moves it away in the display is almost certainly best addressed
through CSS. Both CSS and HTML solutions are equal in
backwards-compatibility here (that is, both are *adequate*, in that
they keep the content near the reference, but neither is really
> From my point of view (working with wikis, and more specifically with the Xinha WYSIWYG editor) it's a use case I often run into for user-editable content. Right now, we do all sorts of lovely things to try and keep our "magic" in place (backlinks, numbering, classes, etc.). It would be much easier if there was semantic support for footnotes in the first place.
As far as I can tell, any "references and footnotes physically
separated in the markup" solution will require essentially the same
amount of effort to maintain the magic with or without explicit
support in the language. Keeping them together will almost certainly
require a lot *less* magic, but then it's more of a CSS issue, and
there are already proposals in motion (Generated and Replaced Content
Module , edited by our own Ian Hickson) to do so. Browsers aren't
likely to implement one any faster than the other.
More information about the whatwg