We have a petition to remove emoji support from the core, which I support. It was originally created due to GDPR and performance reasons. Right now emoji support was slated to be removed from the core and moved into a core plugin for version 2.
TinyMCE v5 has support for browser emoji. This means there are no GDPR issues and no performance hits because nothing is loaded in the front-end. Here’s an example using Twentyseventeen theme with a child theme (I did disable built-in emoji support):
TinyMCE loads emoji plugin ~8k of JS in the backend (according to @anon71687268):
Since TinyMCE v5 will be moved into core, we need to re-think emoji support. A few options to consider:
We continue with a core plugin for emoji, but update the code to enable TinyMCE v5 support which adds a menu selector with emojis to the editor. I don’t see a reason to continue using emojis that rely on twemoji.maxcdn.com. But this leaves us with a core plugin to continue supporting.
Completely drop emoji support and no core plugin. Browser emoji are already supported. You can use them now, just copy and paste them. This is the leanest option and requires no extra work in the future. A developer can create a plugin to enable TinyMCE v5 emoji support.
Since TinyMCE v5 emoji have no performance hits in the front-end, only loading a little bit of JS in the backend for the popup menu, we could bring back an old option that WP used to have under Settings > Writing. This would be disabled by default and users could enable it if desired:
I disagree. The community has already spoken on core emoji support. And, while the new editor would not pose any GDPR implications, there’s simply no need for it. I am strongly in support of honoring the petition to remove emoji from core, and for not including emoji at all in the updated editor.
Emojis are moving to the core plugin (as I was told). I simply want to save us unnecessary work supporting old Twemoji (GDPR and performance issues) when TinyMCE gives us a different option - if the core plugin is still desired (option 1).
This is a discussion, not a poll. I just laid out things to consider.
It’s extremely unlikely that the new editor will include emoji. Users would still be able to copy and paste them into the editor, but, an interface wouldn’t exist for it.
I think it’s worth mentioning the drawbacks of removing all options for standardized emoji support (i.e. displaying the same set of emoji on all platforms, as WP/CP do today). These are reportedly the same emoji from different vendors:
As you can see, these don’t convey nearly the same meaning. There are many other examples of this phenomenon but this is the most drastic one I’ve seen.
Emoji support across platforms has gotten much better since this was originally shipped in WP, but it’s still not universal: Linux users do not see most emoji at all.
For many people this won’t be an issue, but for those who want to use emoji to convey meaning in their content, it will be.
Discourse also supports emoji using a standardized set, it looks like for much the same reasons: Emoji and Discourse
See, that’s why I like discussions. Smarter people than me have information and ideas I haven’t thought about. If standardization is important, that is definitely a good reason to keep it.
However, I haven’t thought about this because browser emojis are becoming the standard everything - email marketing platforms, social media platforms, etc. Simply because browser emoji have better, more universal support, and people are used to them.
Since the petition to remove emoji had so many votes, I think that could be used as a good reason to not introduce the core plugin and leave it for plugin developers to maintain. Less work for the core team.
So you do agree. The option I prefer too.
