Support for Emojis

[JoshyPHP]

Having consistent emoji is very expensive in development and maintenance. Here are some of the reasons.

First off, every operating system, device or browser has its own way to display emoji. It can be as a nice color image, a slightly less nice black-and-white image, or even not an image at all with a character such as �. On top of that, the exact representation of an emoji may differ from a user to another and alter its meaning. For instance, someone may think they are threatening to splash someone with a water gun without suspecting that the recipient will see it as a firearm, potentially turning a joke into a death threat.

That's why normalizing the representation of emoji is generally a good idea. That's on the presentation side, where replacing text with images isn't very difficult. On the input side, things get harder.

Textareas cannot contain images so emoji will be rendered via the native font renderer. It causes the same water gun/firearm inconsistency but at least the only person it affects is the poster, which IMO is the lesser of two evils.

One way to display emoji in a textarea is to use a special font file. Unfortunately, there is no color font file format with widespread support. Color font files are also pretty big, several megabytes and they'll keep growing as more and more emoji are being added to the standard.

Another way to make emoji consistent on the input side is to use a rich text editor which, unlike textarea, accepts images in its content. The issue is that RTEs come with their own inconsistencies. A number of styles and extensions would need to be reworked to be compatible with a RTE.

In summary, getting emoji to work consistently across devices is complicated and labor intensive.

[3Di]

At the end of all, what to do? If the admin disables the smilies then also the emojis are disabled.

About the CDN, is not bloated by trackers, apparently. At least Ghostery and UBlock Origin do reveal nothing.

It seems to me too much a do for really no value, here... thoughts?

[GanstaZ]

I think that with the right event turning off emoji plugin is possible, but is it needed i don't know. I agree & only thing that is still up & floating is license question.

[JoshyPHP]

On the topic of emoji, I noticed today that GitHub have recently replaced their emoji with Noto's. GitHub's PNG is on the left, Noto's SVG on the right:

[3Di]

Yeah, I like those https://github-emoji-list.herokuapp.com/

https://api.github.com/emojis

[martti]

I got reply from EmojiOne:

Hi Martti,

I appreciate your patience on this response. I've talked with my team and we've decided this is a case where adding attribution in the footer would satisfy the attribution requirement. I hope that helps!

Cheers,
Lisa
EmojiOne | JoyPixels

[3Di]

Let someone then open a ticket about it. So that someone else can take care of it. Yes I know, sounds like rounding in circles, but...

[martti]

Let someone then open a ticket about it. So that someone else can take care of it. Yes I know, sounds like rounding in circles, but...

I've created a ticket.

[martti]

Here is a related discussion on the nodeBB community forum on using a public CDN.
The point the OP is making:

• Users being tracked.
• Being dependant on external service.
• Might be slower due to extra DNS lookups.

Other users in the thread report that some public DNS services are slow in some parts of the world.

[CHItA]

I guess we could just replace EmojiOne with twemoji or Noto. I think we can just overwrite the template for the textformater's Emoji plugin, and pull in the twemoji SVGs or PNGs instead, I assume that would be a quick fix (and it is CC-BY 4.0). Not sure what we would need to do for Noto.

For serving emojis from your webserver I guess you should create an extension. It shouldn't be too difficult.