Unicode Variation Selector-15 and some of my tears

From my phone, I noticed that my website was displaying footnote backlink glyphs as emoji in my RSS reader. It had not always been this way. I opened the same page from a desktop browser and saw what I expected to see: a text-like pictograph, in my article body’s font face. No emoji to be found. I checked the HTML document source:

<a href="#fnref:1" class="reversefootnote" role="doc-backlink">
  &#8617;
</a>

The RSS feed XML contained the same. So, that can be presented as either text or an emoji? &x8617; is an HTML representation of the Unicode codepoint U+21A9, Leftwards Arrow with Hook. This led me to many relevant threads, pastes, and blog posts¹ in which others had observed similar issues with Leftwards Arrow with Hook and other, similar navigation-decoration characters. We were all reacting to U+21A9 as rendered without a Unicode standardized variation sequence specified. So it’s up to whatever program is rendering U+21A9 to decide what to do. Which version, the text or the emoji, should U+21A9 render.

I found the correct solution and some less correct solutions to this issue. Before I describe them, I want to explore a slightly larger problem introduced by variation selectors.

The downstream effects

For meta-ish content characters like backlink glyphs, the way forward is clear for people who are technical: fix and/or configure the thing that builds your web pages. Or complain in the direction of the people who can fix and/or configure the thing.

For many of the other characters, it’s more complicated. Many of these characters are used in body content to be expressive. Rendering the text presentation instead of the emoji presentation, at worst, could be a mistranslation. The technical standard (see the emoji-data links, and specifically emoji-data.txt) lists over 1,000 Unicode codepoints that have both text and emoji presentations.

There is no obvious, cut-and-dry user experience for writers here. Pictographs and emoji are regular text as far as most programs are concerned, and variation selectors remain invisible unless you go looking. Did the author mean to present an umbrella ⛱︎ or an umbrella ⛱️ ? We don’t know what their writing tool presented to them during editing. They don’t know that we don’t see what they think we see when we’re reading the thing. In a perfect world, all software knows about and inserts variation selectors for the user. In reality, we know that software is bad.

I found documentation that indicates that the Unicode Technical Committee is aware that variation selectors are complicated,² and maybe weren’t the best strategy.³ But what’s done is done and can’t be undone when it comes to the Unicode Standard.

The most correct solution

You can specify, in your source document, which version you want rendered. You do this by combining the variation selector codepoint with the preceding codepoint you want to render. In my case, that’s U+FE0E, Variation Selector-15. Using my source document’s backlink HTML markup as an example:

<a href="#fnref:1" class="reversefootnote" role="doc-backlink">
  &#8617;&#xFE0E;
</a>

And, if I wanted, I could do the opposite: force the emoji presentation, using U+FE0F, Variation Selector-16.

So, I can fix this issue for myself. I’m fortunate that I build the software that generates this website; and I’m fortunate that the library I use to generate HTML from my Markdown source documents (Kramdown) has a configurable footnote backlink glyph. There are authors using the Mistune library (for example, via the Bear blogging platform),⁴ or perhaps some other niche content rendering library, that don’t have the same luxury as of this writing.

Some less reliable solutions

If you’re in a position where you don’t control the software that builds HTML from your source documents, and, for some reason, it’s not possible to insert a variation selector character where you want it, there are some other things you can try. (At least for applications that use CSS for document presentation, like web browsers.)

font-variant-emoji

The font-variant-emoji CSS property is not currently supported in Safari. Hopefully it will be soon. It allows you to specify the preferred presentation of unicode characters for which ever DOM elements you like:

<article style="font-variant-emoji: text;">
  <span>Umbrella &#x26F1;</span>, or
  <span style="font-variant-emoji: emoji;">umbrella &#x26F1;</span>.
</article>

But I don’t think this can ever be a foolproof solution. Even wide web browser support doesn’t fully account for web content being presented by non–web browser applications like feed readers, and so on.

font-family: monospace

If you want an even less reliable solution, setting the font-family CSS property to the value monospace sometimes works:

<article>
  <span style="font-family: monospace;">Umbrella &#x26F1;</span>, or
  <span>umbrella &#x26F1;</span>.
</article>

But this only forces emoji-presented characters to be text-presented characters. And monospace is a generic font specifier that may look different from device to device.