HTML footnotes: use VARIATION SELECTOR-15 Unicode to block iOS 'emojification' of back-link arrows

[gwern]

I learned from a reader today of a obscure & delightful iOS feature.

iOS (but apparently no other OS*) chooses to render a number of Unicode entities, including '↩', as big colorful emoji. This applies to all web pages, including ones which did not ask for it in any way. (This might also screw with any CSS modifications of footnotes one might do, but I'm not sure about it.)

Their screenshot example of this on gwern.net:

https://www.toohotforbeer.com/more-variation-selector-15-please.png

The backlink arrows in footnotes get turned into big blue boxes, which look nothing like my Source Serif Pro font's '↩' nor my entire site design, and it looks hideous.

There is, apparently, no way to disable this other than by the odd method of appending an obscure Unicode character, 'VARIATION SELECTOR-15'/'VARIATION SELECTOR-16', to every relevant Unicode character you do not want emojified, as any CSS override has been rejected by the consortium:

https://en.wikipedia.org/wiki/Variation_Selectors_(Unicode_block) http://xahlee.info/comp/text_vs_emoji.html https://meta.stackexchange.com/questions/261074/prev-next-triangles-rendered-as-emojis-on-ios-devices w3c/csswg-drafts#1144

My collapse-triangles in that screenshot can be fixed by making a CSS change (content: "\25C0"; to content: "\25C0\FE0E";) but the back-link arrows are trickier because Pandoc is hardwired to generate the Unicode arrow.
We are currently trying a workaround by runtime JS appending the Unicode, but would rather not rely on this:

/*     Guard against emojification of footnote backlinks.
       */
document.querySelectorAll(".footnote-back").forEach(backlink => {
       backlink.textContent += "\u{FE0E}";
});

(It would also be possible to insert it by directly editing the HTML with something like sed, or another Pandoc API plugin.)

This can be easily fixed in Pandoc by editing the writer to use an appended string as the return link, in src/Text/Pandoc/Writers/HTML.hs, something like this:

  let backlink = [Link ("",["footnote-back"],kvs)
                    [Str "↩"] ("#" ++ "fnref" ++ ref,[])]

  let backlink = [Link ("",["footnote-back"],kvs)
    -- NOTE: the Unicode return arrow has appended a 'VARIATION SELECTOR-15'/Unicode entity
    -- \FE0E to avoid emojification; see issue #TODO.
                    [Str "↩︎"] ("#" ++ "fnref" ++ ref,[])]

Unfortunately, this doesn't fix any of the other Unicode characters which iOS will apparently emojify - Xah Lee particularly notes 'U+2194: LEFT RIGHT ARROW ↔' which I did in fact use occasionally (but will now have to remove from all my pages because it looks just as ugly & totally out of place as the emoji version of the arrow) and perhaps other Pandoc users do too - and I don't know if it would be feasible for Pandoc to VARIATION-SELECTOR-15 left-right-arrows as well, but we can at least fix all Pandoc documents' footnotes (which is presumably many Pandoc documents).

Obviously, if there are any Pandoc HTML users which actually want their footnote backlinks turned into Fisher-Price blobs only on iOS, this will mean they don't get that. I suspect that such users are far fewer than those who want exactly what they get (and don't know about this or how to fix it), and they can figure out their own CLI/API/JS workarounds.

* and apparently Chrome on Github but not gwern.net‽ https://dl.dropboxusercontent.com/s/xusugjybkjwy4nw/Screenshot%202019-04-28%2020.20.24.png?dl=0

[jgm]

Confirmed by looking at pandoc.org/MANUAL.html on iOS. Why, iOS??

[mb21]

I'm guessing iOS is choosing to use a weird fallback-font for the glyphs that are not in the current font-family. If so, the proper work-around would be to set the proper font as in https://stackoverflow.com/a/27119852/214446.

But either way, it would be good for pandoc not to hardcode such characters... I believe there was already an issue about this somewhere? Possibly in relation to epub output...

[gwern]

If so, the proper work-around would be to set the proper font as in https://stackoverflow.com/a/27119852/214446.

I don't think that can be the issue. 'left arrow' or whatever is not an obscure or unusual character (which is why it works fine for Pandoc all these years pre-emojification), and it doesn't turn into an empty box when we use the SELECTOR-15 (it remains exactly what it should be, a little Unicode arrow). I already provide a good webfont (Adobe Source Serif Pro); iOS just overrides it anyway, and the override must be overridden.

But either way, it would be good for pandoc not to hardcode such characters...

Maybe, but there would still remain the question of setting the default arrow to avoid this even if the backarrows were customizable (since users should not be expected to know to prevent as arcane and dumb a behavior as this), and since that is unlikely to be implemented any time soon while this is a very simple easy fix (literally add 1 character + comments), let's not let the perfect be the enemy of better.

[mb21]

Even though it might be possible to override it with a font, I agree that your fix is a good solution for the default pandoc case...

[gwern]

I don't believe it is possible to override it with a font at all. I found no examples of any way to override it except by appending SELECTOR (or not using the replaced Unicode points at all).

[jgm]

Related: #3149, #4491

[gwern]

At least one Markdown library, https://www.npmjs.com/package/markdown-it , already implements this (we noticed that footnotes were correct on LessWrong2 which apparently uses this): https://raw.githubusercontent.com/markdown-it/markdown-it-footnote/master/dist/markdown-it-footnote.js

[jgm]

I've pushed a fix for the two characters you mention. If there are others, let us know.