- From: Luuk Lamers <notifications@github.com>
- Date: Mon, 20 Mar 2023 10:07:36 -0700
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/350/1476620035@github.com>
If you just open the picker with the JS API you don’t need to track whether the picker is there because at least on iOS an macOS, the picker is just part of a normal input method: So the switching happens the way switching of keyboards can happen in native apps: by clicking the emoji button/“abc” button. The desktop counterparts could work the same as they just input characters. The color and date inputs already work this way on many platforms so the thing that’s missing is an easy way to get there for special characters instead of having the user remember `CMD+space+.` Or tapping the `Fn` key on macOS, (`Windows`+Shift+. I think) There is a separate use case where you want strictly one character (solvable with attributes/JavaScript) and it HAS to be in a specific Unicode range (solvable with JavaScript, maybe somehow in HTML with attributes and regex). But the basis of that already exists. Showing the picker doesn’t. Met vriendelijke groet, Luuk Lamers On 20 Mar 2023 at 16:30 +0100, Murat Çorlu ***@***.***>, wrote: > > How would that work for a textarea with existing text where I want to add a special character/emoji? > I was considering just setting inputMode property via JS whenever needed, but I see the UX issues about returning to the previous inputmode. And I realized that native virtual keyboards don't allow to switch between inputmodes once we set it to tel for example. We need to have an event to track the user closed emoji picker so we can return back to previous inputmode. > But if the proposed JS API will just show the virtual emoji keyboard on mobile (as suggested in #350 (comment)) same UX problem stays there. How will the user close the emoji picker and return to the previous input mode? > > 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. > inputmode is just for setting virtual keyboard. inputmode=text covers every type of textual input including numbers, decimals, phone number, urls... But still we have those input modes. > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***> -- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/350#issuecomment-1476620035 You are receiving this because you are subscribed to this thread. Message ID: <w3c/editing/issues/350/1476620035@github.com>
Received on Monday, 20 March 2023 17:07:49 UTC