Re: [w3c/editing] JS API to invoke native desktop emoji picker (#350)

There are two distinct use cases for emoji input:
- Long-form text that also benefits from emojis and needs a button to easily input emojis. This is the most common case, and it covers cases like emoji pickers like those on Facebook, Twitter, Slack etc.
- Input to specify an icon, which *only* accepts emojis.

Every declarative solution proposed so far would only cater to one of the two. `<input type="emoji">` or `inputmode="emoji"` primarily caters to the latter, which is far less common. It could be used for the former, but requires the author to jump through a fair bit of hoops (create a hidden emoji input, monitor changes to it, insert emoji in textarea), with a significant potential for breaking accessibility in the process.
A JS API can be used for either, and affords more flexibility about the UI to trigger the emoji picker.

> However, there isn't really an equivalent native API on iOS, since emoji picker UI is tied to the software keyboard there. I suppose the idea is that `.show()` would pop open the software keyboard to the emoji keyplane on iOS?

Yup.

> * On MacOS, there are two modes for the emoji picker window: a transient mode used while editing where it appears near the caret, and another where it appears in a persistent manner when not editing or when dragged away from the caret.  How should these two states impact the API?

I don't think the API should be fine grained to that point, since there is no equivalent on other platforms. *Anything* that opens *any* emoji picker should be acceptable. Once platforms converge more, we can add dictionary arguments to the method to customize what it does further, but it's too early for that now.

> * On some platforms like Linux, for example, an emoji picker may not be available.  Should there be an API to detect whether or not an emoji picker is supported so that the site could author other affordances if not?

I've listed several potential options [here](https://github.com/whatwg/html/issues/8358#user-content-not-available) but I think it makes far more sense for the browser to guarantee an emoji picker by polyfilling it when it's not available in the platform. That makes it more likely that authors will use this API instead of continuing to bundle their own emoji picker. To prevent this from increasing the browser footprint, it could be downloaded only when needed.

> * Virtual Keyboards on Windows have an emoji inputMode which is separate from the emoji picker.  Should there be an extension to the Virtual Keyboard API to specify an inputMode, e.g. `navigator.virtualKeyboard.show({inputMode: "emoji"})`.

Can't hurt, but this is orthogonal (see below).

> * On iOS I think the only emoji picker is the one built into the Virtual Keyboard.  Would that require the API enhancement to the VirtualKeyboard interface mentioned above or should that inputMode be what is revealed when the author invokes this new API to show the emoji picker?

The `showEmojiPicker()` API is higher level than the Virtual Keyboard API. All it guarantees is that a UI for picking emojis will be shown to the user, with no assurances as to what that UI would be. Whether that is a popup, a virtual keyboard, or something else is an implementation detail. 



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/350#issuecomment-1270159154
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/350/1270159154@github.com>