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.
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.
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.
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
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.
emoji import tool.
would work in a non-JS situation.
. Maybe there is a more fresh discussion over this somewhere else.