There are some Unicode characters that some browsers just decide they are going to turn into emojis for you. I couldn’t tell you why exactly, but here’s what I see:
Those text Unicode characters (▶, ↩, and, ❤) show up as text in Chrome, then iOS Safari turns them into emojis. Notice how when they are text, I have the ability to change their color, but not when they are turned to emoji.
Those characters above might turn into emojis for you also. They look like text in my WordPress editor. Shrug.
This came up for me because I was helping someone with their website and they didn’t like the “red diamonds” that were showing up. I didn’t seen them as red until I looked on my phone.
︎︎The “Text Presentation Selector”
A couple of people pointed out to me that if you use this (︎︎︎) before the character it will “request it to be rendered as text.” Here’s the spec on that. I couldn’t get it to work though.
Update! It’s not before, it’s supposed to be after! So like ❤︎︎. That does seem to work for me on iOS. Thanks David.
Here’s my test:
What I see on iOS:
I read in some sporatic threads that font-family: monospace would also prevent the emoji conversion, but that didn’t work for me either (although I’m told that it works specifically on iPadOS).
Let it be an emoji, but force the color anyway.
If you can select the element, even if the characters go emoji, you could force them to a color. Here’s an example from Andrew Walpolea:
Preethi Sam blogged that you can also use text-shadow to do the same:
The problem in my case was that there was no selector to use! The diamonds I was having trouble with were on hundreds of random posts in the database.
Screw it
I just gave up and ran a MySQL search/replace on the whole database (via Better Search Replace) to get rid of them.
Matias Singers has more on this in “Unicode symbol as text or emoji.”
Correction: variation selectors come after what they are to affect.
On iPad OS, the font-family: monospace trick works. I do see characters and not emojis on your codepen where you used it.
Make sure browser doesn’t bite you on the emoji!
Hi Chris,
The character order is important! I’m betting you didn’t try placing the appropriate Unicode Variation Selector after the emoji character, rather than before it.
When the variation sequence is formatted correctly, this effectively tells the browser to render the character as either emoji or text, depending on which variation selector is used:
Variation Selector-16
$#xFE0F;renders as emoji ❤️Variation Selector-15
$#xFE0E;renders as text ❤︎The basic rule? Immediately follow the emoji character with the variation selector – with no spacing between the two characters (otherwise, the emoji will render as text). For example, the variation sequence for the Unicode ‘Heavy Black Heart’ should be
❤️which tells browsers to render it as emoji. I have used html entities here, but the premise should be interchangeable with other Unicode formats.Plus, it works equally well with CSS pseudo-elements using the
content: "\2764\fe0f";syntax!As far as I know, this is the most reliable way to force correct rendering across all platforms. Perhaps you can update your pen showing the correct usage, plus an example without the variation selector.This can potentially help others see if their browser is affected by – lets call it the emoji rendering bug.
That’s all. Cheers.
On Chrome 89 (Windows), all of those show up as emoji for me. Same on Android. Firefox on Android does the right thing. I don’t have a desktop version of Firefox to test.
@shiv – If you followed your ’emoji’ character with the (FE0F) variation selector, for example
𧙊nd️straight after it, then yes, it would show as emoji. Use (FE0E) instead like this𧙏ollowed by︎, and it should show as text. If using html entities (as I did) don’t forget the;semi-colons (which I omitted because they mess with the comment markdown).These do work as described (I just double-checked on current Windows versions of Chromium, Firefox, Microsoft Edge, Opera and Vivaldi, though Chromium and Firefox is usually enough).
The example character I used was ‘Heavy Black Heart’ (2764) which still looks like a heart whether its rendered as emoji or text. The only difference with (2764) is that as emoji it’s red with a black border ❤️, and as text it’s just plain ❤︎.
This links to a PDF with many examples of Emoji Variation Sequences. It’s a bit dated, but a good Google search can likely reveal something more current.
As an appendum – There may be times when you want to use FE0F/FE0E directly in markup, rather than using html entities.
I found a convenient copy and paste method for both U+FE0F and U+FE0E on unicode-symbol.com which is a nice alternative to the otherwise inconvenient ‘alt+numpad’ method (Windows). Naturally utf-8 should be properly declared in markup, along with an appropriate doctype and a unicode-friendly font.
Keep in mind that these variation selectors are non-printing, or invisible characters (whatever you like to call them), so not only won’t you see them but they may not even take up a character space when pasted. To avoid the potential Murphy’s Law effect, I would just use the html entity anyway (to be sure, to be sure).