Invoke emoji input

Since emoji has now been official added to the unicode 7 spec and has been named the worlds fastest growing language, would it make sense to introduce a standards way of invoking an emoji picker?

OSX currently allows the user to insert emoji into an input type text|email or a textarea (see screengrab) yet there’s no way (I’m aware of) to invoke this keyboard through code.

Several web services (Slack for example) implement their own versions of these emoji pickers. However, unicode 8 (released June 2015, but I’ve yet to see implement anywhere) introduced 37 new emoji and 5 new diversity modifers, unicode 9 (set for release next year) is already considering an additional 40 something emoji… Instead of web developers racing to keep up their own implementations of the spec it would make sense for this to happen on a OS and browser level no?

Without getting too sucked into implementation, perhaps this could be a boolean attribute like…

<input type="text" emoji>

Which could add some sort of button to the inout (similar to input type=number) which would then invoke the keyboard.

Furthermore, it would also be useful to be able to invoke this through javascript.

Why wouldn’t you want this to just be part of the browser functionality for every text input? Most/all text inputs are potential places you could put emoji.

From a UX perspective I think there’s definitely areas you’d want to encourage / discourage users inputting emoji.

Like the guestbooks of old. But if you take close note of the very input form, where we enter these questions and answers, then you notice a smiley at the end of the tab bar emoji import tool.

Something like this could also be added to single-line input fields (e.g., little icon behind input). To put it in a nutshell, I’m with Tab Atkins, that browser/OS input methods lack here, and in specific situations web devs can tailor better solutions, if need be.

You could turn it on by default, but I would prefer to have full control to turn it off. You shouldn’t need to use an emoji when typing a full name or something similar. Additionally, it can look unprofessional on some sites.

There are definitely cases where you would want to just accept just text, I’m not sure if the browser could just be smart based upon a combination of inputmode, type and pattern to disallow emoji.

Anyway I can see many use cases where a web developer would want to trigger the emoji tray be presented to the user. For example a [reaction] style button like you have on chat apps.

What about just <input type="emoji">? I think this would be great for when you want to limit the user to inputting an emoji and prompt the smart device to open an emoji only keyboard. It could even use the pattern attribute to limit what emojis could be chosen!

The issue here is that it’s rare you’d have an input where emoji are the only input allowed. I’d rather <input type="emoji"> (and the same for textarea) to be normal text but be a hint to the UA that emoji are wanted or expected. It’s then up to the UA how to offer an emoji picker along with the text field.

More interestingly would be a way to programatically request an emoji picker.

Imagine you have a reaction component that allows users to react with an emoji. You’d only want them to input an emoji. I’d imagine it would be more commonly used than <input type=colorpicker>.

Yes but such a component is where programatically invoking an emoji picker would make more sense. Especially as in these situations you’re going to be using JS to handle said input. What would a non-JS <input="emoji"> look like by default in this situation? Whereas using it as a hint to the browser to allow easier input of emoji in eg a forum post would work in a non-JS situation.

You’ve also got the issue that you wouldn’t be able to use it for validation purposes anyway as its an ever growing spec in unicode. A given browser might not have the latest list of emoji and therefore reject a valid emoji input.

There’s 3 use cases here I can think of…

1, text input with emoji 2, textarea with emoji 3, a single picker with no related text that could be used for things such as reactions

I think cases 1 and 2 could be handled by an attribute on the element, which maybe adds a button that will invoke the picker.

Case 3 could work more like the color input.

I also think the idea of being able to programmatically invoke it could be useful, especially when building more bespoke UI.

Perhaps for cases 1 & 2, have something alone the lines of <input type="text" emoji /> in the same way required is passed now. For case 3, <input type="emoji" /> should be sufficient.

In addition to input there some more issues surrounding emoji that would be nice to be handled at a browser level.

Emoji exist as both unicode code points and shortcodes. The shortcodes are language specific http://unicode.org/cldr/charts/dev/annotations/celtic.html#🤓 which creates quite a lot for app developers to stay on top of. What could be useful…

1, being able to get a list of all supported emoji shortcodes for a given language and their corresponding codepoint values (could be queried with javascript autocomplete) 2, being able to get/set the value of these input as either code point or shortcode

I agree we definitely need some better low level support here and it’s something I mentioned in the last emoji related thread.

Having a way to query unicode characters (by searching on names, shortnames, optionally limiting to named blocks) would enable character maps, emoji pickers, custom character input formats and would be the right approach to allow devs to build things such as the reaction usecase for a single emoji input in a way that fits a lot more with current thinking on new web features (I am all for type=emoji or an emoji attribute as an input hint to browsers for the other 2 cases).

I think a new value for inputmode attribute would be a perfect fit for this. And I think this is a real need for many use cases. Many websites implement their own emoji picker just because it’s not possible to show native one.

<input inputmode=“emoji”>

This attribute can be set programmatically to switch different modes while user writing a content.

Edit: I just realized I replied 6 years old thread. Because dates are not obvious in mobile UI . Maybe there is a more fresh discussion over this somewhere else.

Edit 2: I think this is the correct place to continue discussion now: JS API to invoke native desktop emoji picker · Issue #350 · w3c/editing · GitHub