Unicode Variation Selector-15 and some of my tears

# Unicode Variation Selector-15 and some of my tears Source: [https://benjaminwil.info/weblog/variation-selector-15/](https://benjaminwil.info/weblog/variation-selector-15/) 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](https://codepoints.net/U+21A9)\. This led me to many relevant threads, pastes, and blog posts[1](https://benjaminwil.info/weblog/variation-selector-15/#fn:0)in which others had observed similar issues withLeftwards Arrow with Hookand other, similar navigation\-decoration characters\. We were all reacting to`U\+21A9`as rendered without a Unicode[standardized variation sequence specified](http://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-23/#G19053)\. 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](http://www.unicode.org/reports/tr51/)\(see the[`emoji\-data`](http://www.unicode.org/reports/tr51/#emoji_data)links, and specifically[`emoji\-data\.txt`](https://www.unicode.org/Public/17.0.0/ucd/emoji/emoji-data.txt)\) lists over 1,000 Unicode codepoints that have both text and emoji presentations\. CodepointGlyphAs text \(\+`U\+FE0E`\)As emoji \(\+`U\+FE0F`\)`U\+00A9`©©︎©️`U\+00AE`®®︎®️`U\+2328`⌨⌨︎⌨️`U\+25B6`▶▶︎▶️`U\+2603`☃☃︎☃️`U\+2620`☠☠︎☠️`U\+267B`♻♻︎♻️`U\+1F310`🌐🌐︎🌐️`U\+1F312`🌒🌒︎🌒️`U\+1F37C`🍼🍼︎🍼️`U\+1F441`👁👁︎👁️`U\+1F509`🔉🔉︎🔉️`U\+1F590`🖐🖐︎🖐️`U\+1F635`😵😵︎😵️`U\+1F636`😶😶︎😶️**Table 1**A small sampling of the 1,000\+ Unicode codepoints that have both text and emoji presentations\. The*Glyph*column may look different to you, depending on the application you're using to read this article\. I would hope the the*\+`U\+FE0E`*and*\+`U\+FE0F`*columns*do*render the same way for everyone\. 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,[2](https://benjaminwil.info/weblog/variation-selector-15/#fn:2)and maybe weren’t the best strategy\.[3](https://benjaminwil.info/weblog/variation-selector-15/#fn:3)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](https://codepoints.net/U+FE0E)\. 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](https://codepoints.net/U+FE0F)\. ↩︎ **Fig\. 1**The pictogram via`U\+21A9 U\+FE0E`\. ↩↩️ **Fig\. 2**The emoji via`U\+21A9`alone, next to the emoji rendered via`U\+21A9 U\+FE0F`, where`U\-FE0F`,Variation Selector\-16coerces the glyph to use its full\-colour emoji variant\.  **Fig\. 3**Here's the image of the pictogram version and the iOS emoji version as rendered via`U\+21A9`alone\. As I've already mentioned, which variant you see sans\-selector can differ per application\. So, I can fix this issue for myself\. I’m fortunate that I build[the software that generates this website](https://github.com/benjaminwil/lifer); and I’m fortunate that the library I use to generate HTML from my Markdown source documents \([Kramdown](https://kramdown.gettalong.org/)\) has a configurable footnote backlink glyph\. There are authors using the Mistune library \(for example, via the[Bear](https://bearblog.dev/)blogging platform\),[4](https://benjaminwil.info/weblog/variation-selector-15/#fn:1)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](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/font-variant-emoji)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](https://css-tricks.com/text-that-sometimes-turns-to-emojis/): ``` <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\. CodepointSolutionGlyph\+`U\+FE0E`\+`U\+FE0F``U\+26F1`none⛱⛱︎⛱️`U\+21A9`none↩↩︎↩️`U\+26F1``font\-variant\-emoji: text`⛱⛱︎⛱️`U\+21A9``font\-variant\-emoji: text`↩↩︎↩️`U\+26F1``font\-variant\-emoji: emoji`⛱⛱︎⛱️`U\+21A9``font\-variant\-emoji: emoji`↩↩︎↩️`U\+26F1``font\-family: monospace`⛱⛱︎⛱️`U\+21A9``font\-family: monospace`↩↩︎↩️**Table 2**A table demonstrating the less reliable solutions\.