- From: Luuk Lamers <notifications@github.com>
- Date: Mon, 20 Mar 2023 06:36:30 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/350/1476249330@github.com>
> I think a new value for [inputmode attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) 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 between different modes while user writing a content. How would that work for a textarea with existing text where I want to add a special character/emoji? Any solution should also cater to that, and I think a javascript API that triggers the native picker to then add as many characters as you want would be best. If it also HAS to be an attribute we should keep the singular/inline-in-text case in mind: For a single emoji/special character selection: `inputmode=specialchar`. This would only add value for very specific cases I think. Also, `inputmode=text` already supports selecting special characters. For an addition into existing text the `inputmode=text` alteady does not exclude special characters. Adding an inputmode that does NOT allow for special characters could easily fall into a "discrimination" category. Because not all special characters are alike. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/350#issuecomment-1476249330 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/350/1476249330@github.com>
Received on Monday, 20 March 2023 13:36:42 UTC