Run on Chrome version that doesn't support import

[DrifterAtSea]

I would like to use your widget but I am running Electron, which uses Chromium version 56. The import statement is not supported in Chrome versions less than 60.

I was able to do the following:

var EmojiPicker = require("rm-emoji-picker");

var picker = new EmojiPicker.default();
const icon = mContent.find(".edtAccountAvatar")[0];
const container = mContent.find(".discMessageInputContTop")[0];
const editable = mContent.find(".edtEnableRatingChk")[0];

picker.listenOn(icon, container, editable);

There was no need for the import. The code runs without any issues but when I click on my icon, nothing happens. Nothing is displayed.

Any way to make this work on Chrome versions earlier than 60?

UPDATE:

The DOM hadn't finished loading. I added a delay to wait for the DOM update and then it worked.

[RobertMenke]

@JohannBlake Yes, there are a few ways. The EmojiPicker module is a UMD module, meaning that it can be loaded in a number of ways including globally in a script tag. https://github.com/umdjs/umd

Here are some ways you can use the module:

1. Use babel and/or webpack to transpile your code. I would highly recommend this approach for larger projects, but I understand if you don't want to get into a build system.
2. Include a script tag in your page and use EmojiPicker as a globally available variable

Let me know if you still have issues. Thanks for the question!

[RobertMenke]

Can you post the code you're using to instantiate the picker including where you're loading CSS and JS?

[DrifterAtSea]

I posted too soon. Found my problem and deleted the last post. However, the picker's icons on the header are not showing. They seem to be showing behind the picker. Attached is a png of what I am seeing: https://goo.gl/td89xJ

[RobertMenke]

@JohannBlake No problem. One thing I'd look at is that the icons in my readme are coming from fontawesome. If font awesome is not being loaded neither will the icons. You can use custom icons if you want by overriding the categories property in the object passed to the constructor.

[RobertMenke]

@JohannBlake Sorry for the confusion on fontawesome. I'm referring to this icon library that is very popular on the web http://fontawesome.io/. As I mentioned, you can use your own icons by overriding the categories property, but by default I'm assuming that the fontawesome cdn is included on the page given its ubiquity.

[DrifterAtSea]

In your docs I read:

I wanted a modern looking emoji picker that worked on all modern browsers (IE 9+), gave me the flexibility to control what happens when an emoji is clicked, came with support for contenteditable elements, and didn't deal with the horrible :colon: syntax we've forced on users that just want to see a smiley face!

You have indicated that you want users to avoid dealing with the colon. It wasn't clear whether this meant that after selecting an emoji in your picker whether the emoji image would show up in the input element or the colon text. At the moment, when I click an emoji, the colon text is copied to the input element. Is this because I don't have the awesomefont installed? If I install the awesome font, will the input field show the emoji image or just the colon text? I believe that html input fields only show text or Unicode emoji characters but it isn't clear what images your picker is providing. Are they providing colon text and/or unicode characters?

[RobertMenke]

@JohannBlake No, they're not providing unicode support. Html textarea elements do not support html. This library was designed with an emoji picker and editor that could support both textarea elements and contenteditable divs. If you want your emojis to appear without the :colon: syntax you will have to use an element like <pre contenteditable="true"></pre>.

Windows operating systems don't support emoji as characters period, so I'm inserting them as images into contenteditable elements the same way that the whatsapp web experience does.

[DrifterAtSea]

I don't have a problem sticking with colon text. Slack users are use to it. Eventually I will provide support for it. Thanks for the tip on how to do it.

Without diving into your code, are the emoji images pngs? I doubt that they are vector images. That means that they would not scale if I choose to set the image size. Well, they would scale but lose resolution. Scaling emojis may not be popular at the moment, but Google did release their chat app last year that does allow for resizing the emojis when pasted into a chat message.

[DrifterAtSea]

I installed the Fontawesome and it now shows. Thanks for the help.

One issue I notice is that if the picker is bound to a container that is at the very bottom of the browser, it will not show. It seems that you designed it to be used by input fields that are much higher up in the browser window where there is enough room below it to display the entire picker. Is that true?

[RobertMenke]

@JohannBlake Glad it's working for you now :). One limitation of my positioning library is that the container must be use position: absolute; or position: relative;. It doesn't matter where on the page that container is, but my positioning algorithm requires either one of those CSS properties at the moment. See https://github.com/RobertMenke/Tooltip-js.

[DrifterAtSea]

I've almost got it to work. See the attached image: https://goo.gl/Bo79hQ

I'm using a div at the bottom the browser that extends from the far left all the way to the far right. I set the picker's container to that div. Notice that the picker is moved way over to the far left and most of it is cut off. I did set the div to relative and that did make a difference as you have indicated. Interestingly, when my div is at the top of the browser, the picker does show to the far left but is not cut off. Any idea what could be causing this. The button that the user will click on to show the picker will be at the bottom far right.

[DrifterAtSea]

I was able to get it to work at the bottom right. I did have to add the icon that you click on to show the picker. Using just the div as shown in the image would not work.

[DrifterAtSea]

The only bug I see at this point is that some emojis are showing the male/female symbol next to them and are not actually part of the emoji: https://goo.gl/9yH8Ux

I suspect that some of these symbols have a property that indicates whether they are male or female and somehow your code is missing that information and male/female symbol gets shown.

[RobertMenke]

Interesting, which operating system are you on and which font are you using on your web page?

[DrifterAtSea]

I'm using the latest MacBook Pro running Sierra 10.12.2. My app is using Roboto:

@import url('https://fonts.googleapis.com/css?family=Roboto:300,400,500');

What font is your app using?

I have attached an snapshot showing devtools inspecting the emojis in the picker. You'll notice that the gender symbol is being created by a second character next to the emoji which has this (Note: I had to put a space after the & for it to show here in Github's comments. In the real code, there is no space):

& zwj;♂️

You can see this text on the line for the Police Officer emoji. Apparently this is called a "zero-width joiner": https://en.wikipedia.org/wiki/Zero-width_joiner

Interestingly, the Wikipedia article states:

When a ZWJ is placed between two emoji characters, it can also result in a new form being shown, such as the family emoji, made up of two adult emoji and one or two child emoji.

All the other emojis don't have this. Here's some important info on emojis, ZWJ and gender:

http://www.unicode.org/L2/L2016/16181-gender-zwj-sequences.pdf

Here's the snapshot of my devtools:

https://goo.gl/5sAVjX

If you view your EmojiPicker.js file and search for "male-police-officer", you'll notice the gender symbol is part of the data.

[neverthemachineforever]

Just on the original issue, I'm considering using this library on an existing project which is a few years old and unfortunately isn't set up for transpiling.

I'm a bit unfamiliar with webpack but what I've done for now (locally) is modified webpack.config.js to expose the output on the window object:

    output   : {
        path    : './dist/',
        filename: '[name].js',
        library: 'EmojiPicker',
        libraryTarget: 'var'
    },

and also had to modify the case of the jquery external as a requirement

    externals: {
        "jquery" : "jQuery"
    }

Do you think it's worth considering outputing two dists one for 'umd' and one for 'var' for users with older setups?

Great work on this project by the way 💛

[RobertMenke]

@neverthemachineforever Ya I think that would be worthwhile. In my last PR I cleaned up the webpack files significantly. I can throw something together for people that want to use script tags and load EmojiPicker as a global variable.

[RobertMenke]

@JohannBlake I would imagine that is due to the font being used. In my example examples/index.html I did not see that same behavior.

For now, I'm just using the emoji characters on computers that support emoji natively. In the future, to enforce consistency around these font issues I'll likely just convert all of the emojis to images all of the time. This would also open up support for choosing which style of emoji you wanted.

[DrifterAtSea]

@RobertMenke I'm sure that it does not have anything to do with the font being used as I removed references to all my fonts and used whatever the default font is. This appears to be how well the browser supports this. If I run your example, it shows correctly in Chrome version 59. But my Electron app is using Chrome 56 and it doesn't work there.

[RobertMenke]

@JohannBlake I think the only real solution then is for me to rely only on the image representation of the emojis. I'll have to get a PR ready for that.

Thanks for catching this and bringing it up. I'll leave this issue open until I get that PR ready.

[DrifterAtSea]

@RobertMenke I think using the unicode emojis makes more sense because of the significant reduction in bandwidth transmitting these over the Internet. Chrome normally updates itself regularly, although I just updated mine from 59 to 60. Electron though tends to lag behind several versions and it's not used anywhere at the same level as Chrome.

[RobertMenke]

@JohannBlake Good point. Perhaps I'll add a setting as part of the object passed to the constructor. Something like use_unicode_when_possible : boolean would work fine.

The issue is that I do want to support the selection of different emoji styles like twitter, emojione, google, etc which does require using images only.