Mastodon: Native Emoji Support

Created on 1 Apr 2017  Â·  23Comments  Â·  Source: tootsuite/mastodon

Proposal: Mastodon should give users the option of using the EmojiOne emoji _or_ their operating system's native emoji. Some of us very much prefer the emoji their operating system is baked in with and would like to see them on Mastodon too.

suggestion ui

All 23 comments

This just means using the unicode characters, right?

Yes.. Though shortcodes like :weary: would still need to be converted into native utf through the emojione JS

So a presenter might look like

(configuration: object) -> (token: shortcode | unicode) -> unicode | image | font

?

I think that looks right. Presumably configuration is where you'd decide if you wanted native utf or images?

The front-end has some specific endpoints for saving web UI preferences, it's Redux-connected, so you'd need to connect that presenter to the store somehow.

This happened for a while (#404) but got reverted. It could very well be updated to support this behaviour.

I second this. Would love to be able to use Apple's native emoji set on macOS

We should probably switch to something like Twemoji too. Emoji One updated to the latest Unicode but isn't open source any more.

How weird would it be if we were using Twitter emojis? Even though they're MIT/CC-BY

Native emoji are 100% the way forward

Windows and Linux native emoji are garbage though.

And every single web app implementing custom emoji isn’t going to fix that :wink:

Windows 10 emoji is, for what it’s worth, actually pretty good™, I can’t speak for Linux, though.

Specially in the API. It's quite ridiculous to retrieve colon cherry_blossom colon when there is an Unicode character for that. The consequence is that you cannot display the API output in a plain Unicode environment (such as a terminal)!

On Slack, we can choose Emoji Style from Apple/Google/Twitter/EmojiOne styles.
I think this is best. but I don't know is it possible on Mastodon.

@clworld I don't ask for this sort of choices: Mastodon should send plain Unicode characters, and leaves the client decides how to display them.

Bumping this again: it would be very nice to have up-to-date emoji support. Twitter and Google emoji are primary FOSS emoji and we should probably pick which of the two we use. I'm in favour of Twemoji because Google's new updates are awful, and we want to continue to stay up to date with a good set.

“up-to-date emoji support” would be down to the user if we didn’t do this custom emoji nonsense 💅

The emoji in your github post is a custom one. Emojis in Discord are custom ones, same for Twitter. This is because native emojis suck on most platforms. If they don't suck on yours, you are lucky. Anyway: if an emoji is not supported by our library, it gets displayed as a UTF8 symbol, aka native. Unless you mean shortcodes, which are added by EmojiOne in the first place. I agree that we should replace shortcodes with UTF8 characters in transit whenever we can, but shortcodes are not native and need to be maintained anyway.

Replacing shortcodes to UTF-8 I feel is a separate issue that deserves its own issue; I'll open one.

This is mostly about changing the library that converts emoji to images, allowing the option to either turn it off or use better emoji.

it’s actually optionally-polyfilled, which is the actual correct approach to this

the problem with “if it’s unsupported it gets displayed natively” is that it doesn’t work with Unicode emoji sequences if _part_ of the sequence is supported by your code and the rest would otherwise work on the system

shortcodes should absolutely become UTF-8 for storage and transit as they’re potentially ephemeral whilst Unicode will remain consistent

sorry I’m just still bummed that you rolled back a change which literally implemented native emoji with a custom fallback which would’ve _actually_ solved this problem literally 6 months ago (#404)

sorry I’m just still bummed that you rolled back a change which literally implemented native emoji with a custom fallback which would’ve actually solved this problem literally 6 months ago

I feel like I will literally die if there's another controversy about something like this, but I don't like the suggestion to make the UX worse for everyone who doesn't own expensive Apple hardware

@Gargron Considering the turmoil this seems like an excellent topic for a mastodon blogpost. I'm sure everyone would love to understand the full pains of social platforms supporting emoji in a non-destructive or taxing way.

Supporting emoji is trivial: they are in Unicode for a long time. No need to add custom libraries.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

marrus-sh picture marrus-sh  Â·  3Comments

flukejones picture flukejones  Â·  3Comments

ccoenen picture ccoenen  Â·  3Comments

svetlik picture svetlik  Â·  3Comments

thomaskuntzz picture thomaskuntzz  Â·  3Comments