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.
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.
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.
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.
2, being able to get/set the value of these input as either code point or shortcode
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.
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.