Through the sidebar, I just happened upon this answer on [programmers.se].

If you look at the lower part of the answer, after the horizontal line, you’ll see that the text is smaller. Inspecting the DOM elements on the page as well as the contents of the post as written, this is done simply by using a <sup> (superscript) element. Since the limited subset of HTML we’re allowed here doesn’t really allow for a better method, that’s the same way I usually write footnotes to my answers, if there are any.

The difference is that on Travel, the line height is correct in Fiksdal’s answer (except the first line, before the quote), while here on ELU, all my footnotes have horrible, gigantic line spacing.1

The reason the first few lines of text are wrongly spaced in Fiksdal’s answer, but the rest isn’t, is that the following paragraphs are ‘Markdown paragraphs’ (i.e., blocks of text surrounded by double blank lines on either side), which means the parser encloses them in <p> (paragraph) in the resulting HTML. These are then nested inside the <sup>.

Paragraphs have a line height of 1.3 and a font size of 100%; sub- and superscripts have a font-size of 80% but retain their parent paragraph’s line height. Nesting a paragraph inside the superscript tag resets the font size to 100%, but calculated based on the 80% that the sub-/superscript has; since line height is calculated based on the font-size of the nearest flow-content container (the paragraph element itself, whose size is 80% of the general font size), line height is set to 1.3 of those 80%.

When I tried to fix one of my footnotes here on ELU in this way, however, I found that superscripts are handled differently here than on Travel:

  • On Travel, if you enter multiple paragraphs of text inside a superscript tag, it turns the ones surrounded by blank lines into paragraph tags nested inside the <sup> element, even though that doesn’t seem to be valid HTML. (At least in browsers which accept the non-standard formation and style it appropriately; I haven’t found any that don’t.)

  • On ELU, if you do the same, the output will be that the first ‘Markdown paragraph’ will be converted to a <p> element, and the <sup> will be a child of that element. Any subsequent ‘Markdown paragraphs’ (including ones wrapped in actual <p> tags) become paragraph elements with no <sup> child—that is, just regular paragraphs. In other words, ELU ignores the location of the ending </sup> tag if it comes after the end of the nearest flow-content parent element. This adheres more closely the spec, but it sadly makes for an eyesore of a footnote.

Would it be possible for us to adapt our Markdown parser so that it doesn’t automatically close <sub> and <sup> tags when it reaches the end of the nearest flow-content parent element?

Alternatively, if altering the parser to actually break the standard is not a route a place like SE is keen to go down, is there a way to allow the <small> tag on a per-site basis? The meta.SE suggestion to allow <small> (thanks to suməlic for digging that up) is over six years old and doesn’t seem to have borne any fruit…

(I would have thought something like that would a network-wide thing, but I guess not, if Travel works differently from ELU.)


1 Just look at this note, for example, which with a bit of extra waffling on to force the sentence to be long enough to break into at least two lines of text, will have a line height that looks like it’s about 40% bigger than it ought to be for the text to look harmonious.

  • 3
    Rather than trying to improve the appearance of a hack, it seems like it would be better to revive the proposal for allowing the "small" tag to be used.
    – herisson
    Sep 4 '16 at 16:21
  • @suməlic Good point—added that as a last paragraph. (I did mean to give a more semantic alternative, but got sidetracked and forgot—and I hadn’t found the old meta.SE thread.) Sep 4 '16 at 16:30

You must log in to answer this question.

Browse other questions tagged .