Michel Fortin wrote:
Le 30 oct. 2006 à 15:33, Ian Hickson a écrit :

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.

Would the title attribute be suffisent? I don't think so. The main problem being that an attribute cannot contain any markup (links, emphasis, paragraphs?).

+1

I'm all for a syntax for footnotes (and sidenotes, and endnotes).

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.

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>

This seems to have a poor backward compatibility story - in a non-supporting UA the note ends up in the flow.

2. Some syntaxes meant to be written directly by humans, like Latex,

(we should consider HTML to be such a language)

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.

This seems structurally rather similar to case 3 (below) albeit with a non-HTML syntax.

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. +1 on this general idea -1 on the precise markup, in particular the <div><ol> structure for the list of notes (this should be a new element, if possible) and the use of <sup>. It would also be nice to reduce some of the excess baggage on the <a> element, if possible.


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. For example in paged media the footnote should typically be placed at the end of the current page, whereas on-screen, the end of the section is usually more appropriate.

* 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.

Yes, the positioning and counters should be tied to the enclosing sectional 
element.

* 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.

+1

--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Reply via email to