A (terrible?) way to do footnotes in HTML | Hacker News Reader

A (terrible?) way to do footnotes in HTML

shkspr.mobi

60 pointsedent41 comments

Adequately marked up <a href="..." epub:type="noteref"> footnotes (actually called endnotes) are rendered nicely in epub readers like the Kindle: clicking on one opens it in a scrollable modal. I've seen some desktop ereader software render them as page footnotes.

And since they are basic links, they work in a PDF and of course on a web page without any extra work on your part. Jumping isn't that great (and endnotes should always have a jumpback link) but it's not a bad baseline impl.

I think following the endnote + noteref epub spec is the way to go.

How they actually get rendered, like putting them inline, is then a trivial concern for the reader software.

I personally like the modal overlay approach that some readers do. It handles endnotes of unlimited length and lets them be arbitrarily complicated since the modal is basically just an inset page. For example, a downside of inline footnotes is what should be done when they are too long to fit on the remainder of the page? Do you scroll next-page until you finish reading it, then prev-page back to where you started? etc. Either way, seems ideal to leave that concern to the reader software.

You cannot use details inside p. Only phrasing content is allowed and details is not one of them. So, it would be valid for some rendering engines to implicitly closes the paragraph at this point.

See https://html.spec.whatwg.org/#the-p-element and https://html.spec.whatwg.org/#phrasing-content.

Yes - I have cheated with my markup by just putting the text inside the body without p. It is valid in a div. Like I say, this is a terrible way to do it!

> So, it would be valid for some rendering engines to implicitly closes the paragraph at this point.

Rather, it would be incorrect for rendering engines to not close the paragraph at this point.

(HTML parsing is defined exhaustively. If two browsers parse a given input string to a different DOM tree, at least one of them is buggy.)

I think XHTML allows to put anything inside anything. Not sure if it's legible, but DOM will be nested properly.

On the contrary, XHTML was stricter. If you put an element where it’s not supposed to be, the whole document would (probably?) not render.

But the point is moot: XHTML is completely dead, lacks newer HTML elements like <details>, and no browser includes an XHTML parser anyway—they’ll use the HTML parser.

I don't think you're correct about that.

Here's simple test.xhtml:

    <!DOCTYPE html>
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
      <head>
        <meta charset="UTF-8"/>
        <title>XHTML</title>
      </head>
      <body>
        <p>
          <details>
            <summary>Summary</summary>
            Details
          </details>
        </p>
      </body>
    </html>

It's rendered properly in Chrome. If some XML is wrong, it'll error. So at least Chrome supports XHTML with strict XML validator. And <detail> tag works as expected and it's even nested inside tag in DOM.

That XHTML won't pass validator.w3.org (<details> can't be inside ), but Chrome does not care.

Huh, I thought the XML serialisation of HTML had been evicted from all the browsers, but you’re right, and Firefox behaves the same way. https://html.spec.whatwg.org/#html-vs-xhtml describes briefly what is expected to occur (though that section is non-normative). Also given that I know that browsers can successfully load XML documents with XSLT (I’ve seen one or two web pages that actually do this), and that I know that the XML parser is accessible via DOMParser (this can be useful for some kinds of markup sanitisation), I’m not sure why I thought XHTML was completely dead in this way. Something’s niggling at the back of my mind, but I can’t place it.

I believe browsers would be quite within their rights to do DTD validation and consequently reject such a document as this, but they don’t actually do so. (Even if the DTD is specified correctly for XHTML 1.0 Strict, nothing changes.)

Thanks for correcting me. I have updated my mental knowledge repository.

> I’m not sure why I thought XHTML was completely dead in this way. Something’s niggling at the back of my mind, but I can’t place it.

Browsers were always non-validating XML processors. Maybe you're thinking about the Well-formedness constraints? These constraints check if an XML document follows the XML metasyntax and any XML processor is required to fail [1] on errors in these contraints. And browsers do that.

[1] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-conforman...

In practice most well-formedness violations were nesting errors like missing start or end tags, common when generating XML via text concatenation or templates, which in the dark times a lot of people do, even when they shouldn't . [2] That's why the HTML5 parsing algorithm is so complex and almost unimplementable. It's the ambition for error correction: It tries to generate a DOM out of any well-formed and unwell-formed documents.

[2] https://hsivonen.fi/producing-xml/#nottext

This doesn't sit well, to me. I think it makes more sense to use ``s and `<a href>`s that point to `<a id>`s inside a `<footer>`. I think this conveys the meaning better.

That's not to say the displayed technique is "wrong". It's interesting, clever, and a great exploration of the semantics.

Yup - that's how most ePubs do it now. Currently, eReaders handle that inconsistently. Some jump you down to the footnote and others display it on the same page.

href footnotes are a usability disaster in my experience. Many (most?) don't have a jumpback link, and when the link is too close to the edge of the page it gets overridden by the prev/next page control. I've ended up giving up on reading footnotes in ebooks. If it weren't for coronavirus library closures, I would read a small fraction of the ebooks that I read right now.

This is exactly why I built this. Some eReaders handle it well, others demonstrate the behaviour you describe.

If you prefer sidenotes: https://www.gwern.net/Sidenotes

beautiful! thanks for sharing!

I don't know about using it for footnotes, but this seems a great way to handle spoilers natively in movie/tv related sites with user generated content.

Thanks for sharing the link!

I don't like this, I'm afraid.

I feel we should not have carried over superscript formatting from print to CSS/HTML/ePub. It makes no sense to create such tiny links that are difficult to click or tap. (It's fine to keep the semantic meaning of the tag, but format it so that is not so small.)

Size of visual cue and size of hit target should not be conflated. In terms of visuals, it is a good idea for the marker to be presented as unobtrusively as possible.

To me footnotes/endnotes exist as the least bad way of working with supplemental information within the constraints of the _printed_ page (i.e. it can't be dynamically re-rendered).

I want my electronic documents to do it better, with true re-rendering and inline/overlay display on demand. But it is partly a matter of taste, and there is also something to be said for a degree of skeuomorphism.

In the example, only the second footnote should even be a footnote - the other two should be endnotes. Citations should be endnotes, while asides, parentheticals, and other bits that someone might actually care to read should go in footnotes.

Unfortunately, few styles actually dictate this. I remember one anthology from my undergrad days which handled things perfectly: side notes for vocabulary notes (it was an anthology of older English literary texts), footnotes for commentary, end notes for text source notes (there weren't really citations per se so much as indications about where the anthologized text came from and choices about which edition/manuscript was followed for the text).

I love using footnotes and sidetone in my writing and I have had this frustration myself.

Part of the problem with footnotes is that they must be rendered in completely different ways depending on the device. It is annoying that there really isn't a good way of expressing that something should be a footnote attached to a particular piece of text in HTML. Depending on the stylesheet, this should be rendered as an expandable in-line span, a floating block off to the side, or a footnote at the bottom of the document or printed page (for printouts or PDFs).

My website uses a modified version of the tafte.css project, which meets _some_ of requirements in a sort-of hacky way.

I was toying with the Tufte ones too recently: https://codepen.io/daars/pen/dyXaGdy

This looks way better than my implementation. I may steal it.

In e-text, jumping down to read a footnote, then back up again is a hilarious anachronism that gets old really fast. Ted Nelson groan.

The tack that Wikipedia has taken ... hover over the note# and a floating box reveals the note (and any links) ... IMO is state-of-the-art. I hate wasting time making stuff 'pretty print' - time that could have been much better spent improving the content instead of mere aesthetics.

While the world catches up with WPedia, this 'details' method has a lot going for it.

I had no idea there was a native be [open] CSS selector. It's the first time I hear about details too. Idk if that's a useful was to do footnotes, but I learned something today

Only the details element has the open attribute so you wouldn't hear about using it in CSS without hearing about it. BTW, you can use JavaScript to expand/collapse the element by setting and removing the attribute.

A downside to details/summary for footnotes is you can't find the footnote text in page using Cmd/Ctrl+F.

"Disclosure widgets" are a common pattern on the web so it's good that there's an HTML-native form of them. Two reasons why they're not used more is 1) they're HTML5 so IE didn't support them (neither did Edge before Chromium) and 2) the transition isn't currently animatable.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/su...

https://m8y.org/tmp/testcase490.xhtml Animation.

Thanks, I was just going by the note on the MDN page.

I tried changing your example to have the transition be on the <detail> element itself instead of the child but it didn't work, maybe that's what the MDN note is about.

https://m8y.org/tmp/testcase491.xhtml transition on <detail> And, yeah, the main "trick" is that it's tough to animate a height when the content is variable height. Thus the max-height and tweaked animation curve trick. But for many cases you'd probably want fixed height with scroll anyway.

Just be sure to use a keyframe to turn off the scroll when animating or it looks awful.

I’ve noticed that excessive use of <details> can cause a pretty big hit to page performance

interesting. Is that browser-specific maybe? (something to do with how the html is parsed)

Included by reference: https://news.ycombinator.com/item?id=23974212

Why not just the tag and html anchors?

https://jsfiddle.net/jvuywL5k/

As I attempted to explain in the linked blog post - different eReaders render these sorts of links differently. Some link to the bottom of the page, some don't provide backwards navigation, some pop-up modals, some modals overflow.

This was designed to be an experimental way of doing in-line notes.

As per the title, it isn't a particularly great way of dong it. But I thought it was interesting.

This is clever, but it seems to require the use of a mouse or other pointing device. I prefer to use keyboard navigation (like vimperator, etc.).

It does not require the use of a pointing device. The details element is keyboard selectable. On my browser, both space and enter work to toggle it.

Ahh, I guess I should have been more specific. I can also select the footnote toggles by tabbing, and toggle them with the keyboard. But can’t select them in a random-access way with link hinting (I mentioned vimperator), because they are not links nor something else, such as an input field, that gets a hint. So that's a slight advantage on the side of using some kind of link for the footnotes. But really, this just shows me that link-hinting systems should include detail toggles as targets.

Oh, that's an interesting use-case I hadn't considered.

I hate footnotes. They should have no place in modern publishing, especially on the web.

why?

Reply on news.ycombinator.com