First of all, thank you for EmojiPickerElement!

Next, I'd like to share a little problem with you, I have two pages, one page with an messaging system that uses emojiPickerElement with all emojis.
And I have a page with posts, on which you can react to posts with only about ten emojis.
What I do is I initialize the database and then EmojiPickerElement by giving them a JSON in dataSource with only the emojis I want and with the 'click' event I record the user's reaction on the post.

But here's the problem, if the user has been on the messaging page before going to the posts page, because of the cache, all the emojis are displayed and not only the ones from the dataSource (you have to reload the page so that the dataSource is taken into account instead of the cache). What can I do?

This is definitely an edge case, but if the user has set customCategory on their custom emoji, even if all custom emoji have a single category, then I think we should visually show it. Otherwise it's not clear to sighted users that the category may be something other than just the default ("Custom").

In a svelte component within a Sapper project, I am trying to add the picker:

<script>
  import { onMount } from "svelte";

  // https://github.com/nolanlawson/emoji-picker-element#within-a-svelte-project
  import Picker from "emoji-picker-element/svelte";

  let sidebar;

  onMount(() => {

    // Picker:
    const picker = new Picker({
      locale: "en",
    });
    sidebar.appendChild(picker);
  });
</script>

<div bind:this={sidebar}></div>

error:

const rAF = requestAnimationFrame;
            ^
ReferenceError: requestAnimationFrame is not defined

Any ideas or advice on how to get this running in sapper? Thanks!

For native (not custom) emoji, NVDA+Firefox reads the shortcode name twice when pressing up/down through search results. VoiceOver+Safari does not have this issue.

Not sure why; maybe it's the title? I don't plan on getting rid of the title, though.

Breaking changes we may want to make in v2:

• drop support for emojibase-data v5
• drop support for deprecated trimEmojiData()
• drop support for browsers that don't have ResizeObserver (there's fewer and fewer all the time)
• move to Svelte v4
• drop support for the :focus-visible polyfill (caniuse)
• rename data-source (?) (unfortunately, I remembered only after shipping it that data-* attributes have a special semantics, e.g. element.dataset)
• use container queries to automatically apply the mobile styles
• drop support for browsers that don't support logical CSS units

I guess it is hard to handle all these, but with GBoard I can search for Danish or Denmark and it will give me the Danish flag - here only Denmark works

Also 'pray' shows praying hands but not 'praying'. Also high fives on GBoard will give you praying hands :)

In browsers that don't support color emoji (e.g. KaiOS, Chrome on Linux without Noto color emoji package installed), we currently show an error message: "your browser does not support color emoji."

Another possibility is to just show the v1 emoji, even if there's no color. It may be better than nothing.

It's worth investigating how many browser/OS combos actually have this problem, and what non-color emoji they would support in that case. For now, I'm only aware of KaiOS and Linux Chrome.

Repro

If you click away to another section and then click back, it works. But it doesn't start on the right section.

So I have this svelte app inside which I do

import EmojiDatabase from 'emoji-picker-element/database'
…
const edb = new EmojiDatabase()
...
async function click(shortcode) {
    emoji = await edb.getEmojiByShortcode(shortcode)
}

And this fails for shortcode = 'smiling_face_with_3_hearts'. Maybe it has something to do with the number inside the short code?

Hey there!
Thanks for the awesome package, we really enjoy using it and we have implemented it as a tooltip in our vue project. However, we’ve noticed issues in our reporting tool piling up on Edge (EdgeHTML: 18.17763):

Expected identifier, string or number in picker.js  2011  13  currentSkinTone(...)

Backtrace:

fireEvent(“emoji-click”, {
--
2010 | emoji,
2011 | skinTone: currentSkinTone, <---
2012 | ...skinTonedUnicode && { unicode: skinTonedUnicode },
2013 | ...emojiSummary.name && { name: emojiSummary.name }

Any ideas how this can be resolved? Perhaps, it is a really old version of the browser, if so, is there a way to detect and maybe hide the picker? Some more context about our use case:

• We use the element inside a vue component alongside popperjs and we listen for the emoji-click which then emits another event that we use outside of the component.

Thanks for your time!

Just making a note here so I don't forget.

I've been trying to update typedoc, but the latest version has plenty of breaking changes, including one that I'm not sure how to work around. For the Picker and Database constructor options, it just renders __namedParameters which is ugly and unhelpful. In the old version is actually rendered each of the named parameters in a table.

I can rename it using this plugin but that only partially solves the problem.

I don't see any way around this from looking through the typedoc open issues and stackoverflow questions, so I'm just sticking with the old version for now.

Abandoned attempt: https://github.com/nolanlawson/emoji-picker-element/tree/try-to-update-typdoc

It seems that Firefox for Android blocks using canvas in a cross-origin iframe for measuring text. I noticed it because the emoji picker can't load in the CodePen posted in this blog post: https://css-tricks.com/awesome-standalone-web-components/

Not sure there's anything I can do about this. But maybe if canvas fails, we should just show all the emoji, even if they're broken? Probably better to show some �s than to not show the emoji picker at all.

Please authorize bundlesize to see its reports.

https://github.com/siddharthkp/bundlesize#build-status-for-github

1. Tab to the skintone dropdown
2. Enter
3. Press Esc

It should close the listbox and select the dropdown button, but instead it enters a weird state where the listbox is still open but you can tab around to other stuff.

The skin tone selector does not work on my Firefox 77 / macOS. For some reason, there's no activeElement on the focusout event when I click on a skin tone button.

Firefox currently does not allow interacting with IndexedDB in Private Mode (meta issue here), so emojis fail to load in this scenario.

Tested in FF 77.0.1 / macOS Private Mode.

Looks like emojibase-data v6 has been released, with several breaking changes that affect emoji-picker-element: https://github.com/milesj/emojibase/blob/master/packages/data/CHANGELOG.md#600---2020-09-11

Luckily we are not broken by default, because I had the foresight to make the default URL https://cdn.jsdelivr.net/npm/emojibase-data@5/en/data.json.

It's come to my attention that the event names skin-tone-change and emoji-click may be problematic in some cases. It looks like some frameworks may not be able to use anything but lowercase, non-hyphenated event names, because that's what's supported in the DOM. E.g.:

<emoji-picker onemojiclick></emoji-picker>

but not

<emoji-picker onemoji-click></emoji-picker>

The second one looks like of bizarre anyway, so we should probably just support the non-hyphenated version, and maybe remove the hyphenated version in a major update later.

Note this would only apply to declarative usage not imperative usage. element.addEventListener() should work in all cases.

Given #10 (comment), this seems like a sensible feature.

Travis is cutting us off, so it's time to jump ship. Circle CI is nice.

Your current custom styling section can probably be replaced with CSS ::part(), which has great browser support now.

    const picker = new Picker()
    picker.setAttribute('data-source', 'my-data-source.json')
    document.body.appendChild(picker)

This will actually issue a request to jsdelivr rather than my-data-source.json.

Given that React is apparently not launching custom element support in React 18, maybe we should have our own React wrapper, or at least document in the README how to do this.

This is a new thing in Node.js: https://nodejs.org/api/esm.html#esm_package_entry_points

We could use this to formalize the .cjs versus .js versions in some of the APIs.

I don't know which versions of Node actually support this, though.

Right now my goal is to keep the minified size under 40kB. Intuitively the size right now just feels way too big, but most of it is in the Svelte code so I don't have much direct impact over it. Still, if I can buy us some more kilobytes, it makes me less nervous about implementing new features.

I've been sort of dogmatic about only supporting native emoji, but it is extremely frustrating how slowly OSes and browsers are rolling out Emoji v13.

Also I noticed an interesting way someone is using the project: they're using the Twemoji font and overriding the built-in font list: hedgedoc/react-client#664

This could be made an official API. For instance, you could set picker.customFont = 'myFont', and it would just set that as the font and ignore all the logic to try to figure out whether Emoji v13 is supported or not. (I think we could safely assume that if you're using a custom font, then it's probably because it supports all the emoji, so there's no need to try to sniff out unsupported emoji.)

Feature: being able to swipe left or right (e.g. on a touchscreen) to change tabpanels in the picker.

This would be neat to implement, although I think it would be very technically challenging. I would like to do something like react-swipeable-views, where it mimics the momentum of native implements. Either that, or we could use something more like a horizontally-scrolling carousel.

The main challenge is that I implemented the picker in such a way that the list of emoji is basically the same DOM node, and we just swap the list of emoji in and out. This is great for performance, because Svelte only has to do a keyed list update, e.g. when changing tab panels or searching in the search box. But for swipeable views to work properly, we would probably at least have to have a "preview" to the left and right of the current results.

Alternatively, we could just allow swiping left and right to show blank space on either side, and then once your finger lets go, we actually make the call to IndexedDB and show the emoji. This would be less nice-looking but probably a lot easier to implement.

I've already started to receive some contributions for translations for emoji-picker-element. I wasn't planning on including these in the emoji-picker-element repo, but I admit it's not clear where else to put them.

On the one hand, it's a bit wasteful for everyone using emoji-picker-element to write their own translations (assuming they internationalize). But on the other hand, managing a lot of translations in one repo could be a heavy maintenance burden.

Maybe I should rather look into some kind of service for managing translation files. In any case, opening this issue so I can noodle on it.

First off, this library is absolutely amazing, I've yet to find an OSS UI component that I feel is as well done (inside and out) as this one. Hats off!

When using the Database to search emojis, I noticed that the results include emojis that the current os/browser does not support. This makes sense, I guess, as the Database is a pure JS thing that doesn't depend on the browser at all, but it does make it hard to use your excellent native-emoji-filtering code in scenarios where you don't want to show the entire picker.

I've been thinking a bit about what approaches there might be that keep with the spirit of your design. One might be totally extracting the emoji support detection and filtering into a third exported class (besides Picker and Database). But that feels a bit over-engineered somehow - especially since it'd need to do all the init and browser setup code that the Picker also does.

A simpler option might be to maybe have the Picker class expose some of the same methods that Database does, eg getEmojisBySearchQuery and getEmojisByGroup. Then, any user who wants the browser-curated version of the emoji database can just instantiate a Picker and call it from there. But it feels a bit quirky too, with the Picker instance being a DOM node and and these functions influencing the DOM node's behavior whatsoever. What do you think?

I'd happily provide a PR, as I guess most solutions aren't hard per se. But many solutions would mess up your code in ways you'd likely prefer not to accept, and suppose there's more fun to be had than arguing with contributors about why their code is too shitty to make it in. So I figured I'd ask you for your thoughts first.

Right now the algorithm for detecting emoji support is:

1. Go through a representative emoji from each version, check if it's rendered in color
2. Filter out any emoji versions greater than the version detected by the above
3. When rendering any emoji, if it has a ZWJ in it, check that is rendered width is within a certain threshold relative to the width of a baseline emoji

The problem is with emoji versions like 13.1, which only have ZWJ additions. So there's no good color emoji test available. This means that if a device supports 13 but not 13.1, we will do a width check on every single emoji from 13.1 rather than testing one and skipping the others.

This is just a perf improvement, but it could be a big one (maybe). My concerns:

1. Extra complexity in the code for an as-yet unknown perf benefit
2. Potential blocking by UAs when reading the width of emoji via canvas (I'm already nervous about using canvas at all given fingerprint-blocking, although so far I haven't heard any complaints)

https://github.com/nolanlawson/emoji-picker-element/blob/master/src/picker/utils/requestAnimationFrame.js#L1

While this may make the bundle size smaller, it'll make the compressed size larger.

Currently, custom emojis are limited to single image files. It would be great though if one can use custom non-image "emojis". This is especially useful if you want to support icons from icon-fonts such as FontAwesome or material-icons.

My idea how to realize this looks as following:

• Custom emojis get a new optional property html
• If the html-property is not set, the emoji will be rendered as an image with the defined source (url)
• If the html-property is set, the url-property will be ignored and instead the html code will be rendered instead of the image

This allows setting e.g. <i class="fa fa-home"></i> as html.

If such an approach sounds reasonable, I'd like to help implement it.

The background for this issue: I'm one of the devs of @codimd. We're currently re-building our app and want to include your emoji-picker as it performs quite well. As we allow users to insert ForkAwesome icons, we wanted to integrate that into the picker without the need for single image files.

Hello there, first of all, amazing work here.

How I can set the Picker as a Button with floating overlay such as datepicker?

Here my code

<a id="emojiPicker" class="btn btn-primary" type="button">Emoji</a>

        <script type="module">
            let picker = new emoji_picker.Picker();
            let style = document.createElement('style');
            style.textContent = `
            .picker {
    z-index: 1;
    position: relative;
    width: auto;
}
            `
            picker.shadowRoot.appendChild(style);
            let emojiPicker = $('#emojiPicker');
            emojiPicker.click(function() {
                $('#emojiPicker').after(picker);
            });

            const pre = $('#pre')
            const onEvent = e => {
                console.log(e)
                pre.html(`Event: ${JSON.stringify(e.type)}\n\nData:\n\n${JSON.stringify(e.detail, null, 2)}`);
            }
            picker.addEventListener('emoji-click', onEvent);
        </script>

I'm not that good in JS and JQuery that i can exactly describe the wanted behavior.
On Datepicker Plugin, if you click into an input field for example it will show a nice "overlay" popup
https://jqueryui.com/datepicker/

Is it posible to do that for this project?

Looks like Svelte has changed how mounting/unmounting works for custom elements, so I can remove some of my hacks: sveltejs/svelte#4522

This won't affect users of the normal version of emoji-picker-element, but it could affect users of emoji-picker-element/svelte when Svelte releases this update. (It might be a breaking change, not sure.)

Steps to repro (jsfiddle):

import { Picker } from 'https://cdn.jsdelivr.net/npm/[email protected]/index.min.js'
const picker = new Picker()
document.body.appendChild(picker)
document.body.removeChild(picker)
document.body.appendChild(picker)

It shows a blank element instead of the picker.

I'm not sure how important this use-case is (you can always just call new Picker() instead and insert that), but maybe this should be supported?

It's not the job of this library to explicitly manage storage, but I should at least surface this particular error so that users can respond to it. https://web.dev/storage-for-the-web/#over-quota

Error if it is not used in body element.

import 'emoji-picker-element';
<emoji-picker></emoji-picker>

picker.js:2403 Uncaught TypeError: Cannot set property 'scrollTop' of null
at eval (picker.js:2403)

rAF(() => { // reset scroll top to 0 when emojis change $$invalidate(6, tabpanelElement.scrollTop = 0, tabpanelElement); });

For keyboard and screenreader users, it would be nice to have a faster way to get to the favorites bar. They're supposed to be easily-accessible, which they are for mouse and touch users, but keyboard/screenreader users may have to tab through a lot of content to get to the favorites.

Something like skip links but for the favorites bar ("Skip to favorites"?) could work, although I need to do some research first to see if this is a generic pattern that would make sense for an emoji picker component.

Apparently jsdelivr treats package@1 differently from package@^1 – the second is more likely to be fresher. So we should fix this in the default data source and in the documentation.

Some emoji pickers are now able to select multiple skintones for those emoji that support it (e.g. 🤝 and 🧑‍🤝‍🧑).

I'm a bit worried that this feature would require complicating the interface quite a bit, and increase the bundle size. Also it's not clear to me what the support is across all platforms. E.g. apparently Microsoft supports 52,000 family combinations.

Still, it's a necessary feature to be able to pick all the emoji.

Right now custom emoji assume that there is one image file for each custom emoji, but presumably some people are using spritesheets. Even in the age of HTTP/2, there is some argument for doing so, since a single PNG compressed better than many small ones. It seems reasonable to support.

Having the ability to add extra tags to use when searching for custom emoji would be neat.

One use-case I can think of is that Mastodon marks some emoji as "not shown in the picker," because they are intended only for autocomplete searches. E.g. the same PNG may have two shortcodes: :foo: and :foobar:, but we don't want to show duplicates in the picker. In this case, a user of emoji-picker-element could take the non-shown emoji and add its shortcode to the tags of the other emoji.

Using title is the easiest option, but it has a few drawbacks:

• doesn't work for keyboard users
• can't display rich data, only text

I think there's a case to be made that we should add some kind of custom tooltip. It could show things like a larger version of the emoji, the shortcodes, the annotation, etc. Using a pattern like this, we could even make it accessible to keyboard and screen reader users.

The main downside is increasing the bundle size and adding complexity. Also either way, it's not going to be accessible to mobile touchscreen users (although this could be said of title as well).

When the skin tone dropdown is expanded and the user focuses somewhere else, it should automatically collapse.

This was already implemented in v1.0.0. However it didn't work properly cross-browser and cross-OS (see #14 and #15), so it needs to be carefully implemented if we want to bring this behavior back.

This is a best practice and doesn't seem super hard to support, although unfortunately web-component-analyzer doesn't seem to really work well for us.

Example custom-elements.json

Hi,

I've installed the repo using npm install emoji-picker-element and imported it via import 'emoji-picker-element';. But when I try to use <emoji-picker></emoji-picker> in my component, these console errors shows up:

Uncaught TypeError: each_value_2 is undefined
create_each_block_1 picker.js:1045
...
Uncaught TypeError: tabpanelElement is undefined
update picker.js:2402

Everything is working fine if I import it as a <script> tag instead of using npm

<script type="module" src="https://cdn.jsdelivr.net/npm/emoji-picker-element@^1/index.js"></script>

I'm on FireFox 89.0.2, haven't tested with other browsers.

Hello Team,
I am trying to use it in angular application when I add in html its asking add as a angular component.
But I don't see any module exposed in library

It feels like this should work:

 <emoji-picker
  dataSource="https://example.com/data.json"
  locale="en"
></emoji-picker>

...but currently it doesn't. Maybe it should?

Open question is how we would handle i18n or customEmoji, or the case sensitivity of dataSource, but it seems worth investigating.

Both the WAI-ARIA tabs example and collapsible dropdown example recommend using Home/End to jump to the start/end of the list, but I did not implement this.

Where this would apply:

• skintone dropdown (listbox)
• search results (listbox)
• tabs

By default, custom emoji categories are sorted alphabetically. I wish to pin/put certain categories over others.
I don't see a current way to do this, is this something that could be added? Maybe let me provide a custom sort-function?