- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 15 Dec 2008 16:38:52 -0600
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 acceptable). > 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 [1], edited by our own Ian Hickson) to do so. Browsers aren't likely to implement one any faster than the other. 1: http://www.w3.org/TR/css3-content/ ~TJ
Received on Monday, 15 December 2008 14:38:52 UTC