Emoji picker

[nolanlawson]

I don't know if this is the right venue to propose new layered APIs, but I really think an emoji input would be a good candidate for a layered API custom element.

Prior discussion on WICG: https://discourse.wicg.io/t/invoke-emoji-input/1030

Prior art: Discord, Slack, every chat and social media app ever

Justification: emoji support is spotty across different OSes (see: Linux, some Android keyboards, Windows 7). And even on OSes with a built-in emoji picker, users often don't know they exist. (Show a Mac user Cmd-Ctrl-space or a Windows user Win-; and watch their eyes light up.) The emoji standard is also always growing, meaning that the built-in system emoji on a user's device are almost always out of date.

So, many websites opt to include their own emoji picker. But these are heavy: an audit of the OSS social media app Mastodon shows that the emoji picker and emoji lookup total ~674kB of uncompressed JavaScript (coming from the emoji-mart library). Most of that weight is static JSON containing a list of all emoji, which has to be updated whenever new emoji come out.

It feels silly for every website to bundle its own emoji picker, especially given that the number of emoji is only increasing, and so that JS library size won't get any smaller. This would be a neat candidate for a layered API.

[littledan]

Interesting idea. I'm wondering how much of the download size is all those emoji names. CLDR has some data here, and it's even localized!

Would it make sense to expose the CLDR data on emoji names to JavaScript directly? We are working on exposing various other pieces of CLDR data as part of the Intl effort, especially the new DisplayNames interface (which is at a very early design stage).

Cc @mathiasbynens @sffc @gsathya

[tomayac]

Coincidentally Twitter just announced theirs: http://twitter.com/kaushlaks/status/1075563505753972742.

[nolanlawson]

@littledan Yep, the emoji data itself is the biggest chunk. Here's emoji-mart's data – the all.json is over half a meg.

I think including the names would very helpful, and I see some overlap with the Intl API. Another use case for this emoji data is autocompletion, e.g. you start typing :tongue and the app inserts 😛. This list would probably need to be augmentable though, for the case of custom emoji names (e.g. "hairflip" for 💁) or custom emoji (Discord, Slack, Mastodon).

Also to clarify: I'm not proposing that browsers simply invoke the system emoji picker (which doesn't even exist on e.g. Ubuntu), but rather have their own HTML-based picker. Perhaps this would even use a custom emoji font rather than the system emoji font. I know Firefox ships with Twemoji on Linux, so there is some precedent for this.

[littledan]

Yeah, exposing a lower-level API with the names would solve that "augmentable" problem.

Would you be interested in joining our Intl call to discuss the requirements for emoji name data? And/or, filing an issue in the DisplayNames repo to document it?

We're also thinking about providing data for pickers for timezones, countries, currencies, languages, etc., which to me feels somewhat analogous.

[sffc]

FYI

ICU ticket: https://unicode-org.atlassian.net/browse/ICU-12879

Most of the CLDR data for emoji are not exposed via ICU.

[nolanlawson]

@littledan Sure thing, let me work out the details with other TC39 folks at Salesforce, but I'd be happy to join the call. :)

[gsnedders]

Many sites, like Discord and Slack, allow per-channel (or per-server) emoji to be defined beyond the set that Unicode define. If we go as far as to define a high-level picker API, I think it's essential for adoption that we allow for extra emoji to be specified. That said, if we don't and just provide access through Intl to CLDR data then obviously that problem is avoided.