Andre's Blog
Perfection is when there is nothing left to take away
Emoticons are not emojis - please stop helping!

For some inexplicable reason product owners are obsessed with auto-correcting emoticons with emojis, which was somewhat manageable via app configuration before, but now that there is a tendency to simplify configuration by taking away options, a la Apple way, auto-correcting emoticons is becoming more annoying then it was ever before.

Forced auto-correction, in general, is quite stupid for a number of reasons, but automatic emoticon replacement is really getting on my nerves, not only because it changes the meaning of what is being posted, but also because it often interferes with useful Unicode features, such as searching.

Not what I said

An emoticon is a simple and non-pretentious way to express a smile in the message narrative. It shows the same way on all ASCII systems and it does not shine from the middle of a message with whatever catchy image substitution some software is using. For example, I could write a message with a slightly apologetic feel like this:

Found a bug. I missed it a couple of days ago. My bad... :)

In MS Teams the same message would look like this:

Found a bug. I missed it a couple of days ago. My bad...

This grinning yellow beacon of happiness is the last thing I want to convey in a message like this.

Outlook does a better job and inserts an emoji character, which is slightly better in that there is a better defined way such character would look because it is implemented in system fonts to follow Unicode guidelines and not for some specific app or site, but it still catches the eye more than it should:

Found a bug. I missed it a couple of days ago. My bad... 🙂

If I typed an emoticon, this means I wanted an emoticon. Stop messing with my text. I'm happy your developers learned to match characters as they are being typed, but this is not where they should apply this skill.

Unicode vs. Images

Unicode Consortium is very elaborate in their design and guidelines in how emoji characters should be displayed and how they can be combined to form other characters. Sites that substitute Unicode emoji characters with their home-grown equivalents often mess up this logic.

For example, a thumbs-up emoji 👍 can be followed emoji modifiers 🏻🏼🏽🏾🏾 to produce thumbs-up characters with different skin tones 👍🏻👍🏼👍🏽👍🏾👍🏿. Similarly, a man emoji 👨 followed with a skin tone 🏽, combined with a school 🏫 emoji via a zero-width joiner character (U+200D) produces a male teacher with that skin tone - 👨🏼‍🏫. For one more, a man 👨, a woman 👩 and a child 👦 combined the same way produce a family 👨‍👩‍👦 emoji.

All of this becomes moot when emojis are replaced with images, unless site developers are ready to undertake a huge task of rendering an image for every possible emoji code point combination, like Facebook does it. Facebook wraps emojis in span elements, puts the actual emoji in the span and sets its background as an image for this emoji, like this:

<span style="background-image: url(&quot;.../1f44d_1f3fc.png&quot;)">👍🏼</span>

This allows Facebook to show consistent emojis throughout different operating systems and apps and works even for browsers that don't support modern emojis with skin tones, etc. A nice aspect of this approach is that all emojis on the page are still searchable on the page.

Other sites are not quite as clever in their emoji auto-correction. For example, Flickr just introduced emojis in their comment boxes on photo pages and replaces emojis with images, but they are doing a really bad job at it and simply throw away all emoji modifiers and render just base emojis as images, so 👍🏻👍🏼👍🏽👍🏾👍🏿 becomes 👍👍👍👍👍, rendered as SVG, like this.

thumbs up thumbs up thumbs up thumbs up thumbs up

Even if one ignores any technical shortcomings of this implementation, why would Flickr choose to drop skin tones in this day and age is beyond comprehensible. It is just bad product management.

As far as functionality goes, emojis should be searchable on the page and in text searches through each site and in search engines. That is just common sense - emojis are as much text as any actual text on the page and then some.

Page searches should be as simple as hitting Ctrl-F and typing a particular emoji character in the search box. This works for Facebook, but fails on Twitter and Flickr, which just replace emojis with images.

When emojis are replaced with images, at least the alt attribute for that image should be set to the original emoji, so search engines could index those emojis. Twitter does it with their images, but Flickr puts "thumbs up" in theirs, which is not quite the same because emoji search is supposed to work in all languages and not just some specific language a developer chose when they typed the alt attribute.

Coping with Auto-Correct

Given that is it quite unlikely that these we-know-better-what-you-want sites will ever listen, all we can do is to resort to home-grown hacks, where possible, which usually is either wrapping emoticons in some form of formatting or inserting a zero-length space between characters to avoid simple pattern matching often used in auto-correction code.

For apps that support source code formatting, like MS Teams, emoticons can be wrapped in ticks - `:)`, which is intended for code, but works nicely for emoticons because MS Teams renders their code spans with a light gray background, so it looks like this :) and is not too distracting. Other apps and sites may choose different color for code spans, which may grab more attention, but at least it grins the way you intended.

For sites like Facebook, I hit Ctrl-F12, go to the browser console and type a quoted string with a zero width space \u200b between key parts of whatever is between quotes, like this - ":\u200b)", which is rendered as :​), with a zero-width space between characters, so Facebook and many other sites leave it alone.

Facebook does a really good job and honors emoji text presentation selectors, which say that the emoji is expected to be rendered in its text presentation. For example, 🙂 followed by the text presentation selector (U+FE0E) produces 🙂︎. In the browser console the sequence "🙂\uFE0E" will produce a text emoji. Twitter, MS Teams, Outlook ignore presentation selectors and render emojis as if there wasn't one. Flickr drops the entire sequence as if there is no emoji in the text at all.

How a site deals with emojis typed as emojis is really up to the site product owner. I get that. May be except ignoring text presentation selectors. Those are in the standard for a reason. However, replacing emoticons with images or even emojis is not Ok because it changes the meaning of what was said and how it was said. I wish product owners would understand this simple concept.