Re: [w3c/editing] inputPanelPolicy as a way to control software keyboard (#225)

We are not worried about a website doing this maliciously. Then the website just sucks, and no one uses it.

We are worried about a website doing this accidentally, because they only test on other platforms that always have a way to manually bring up the keyboard, and not on iOS/iPadOS, which do not have such a button.

inputMode=none doesn’t seem the same issue because it says to never show the keyboard, not to put it under manual control.

Permissions don’t address this because the permission is not likely to be comprehensible and it will just contribute to alert fatigue.

Adding a browser-specific button to show the keyboard seems like it is fighting the OS design of not having such a button. Users would be puzzled why this is a thing only in the browser. It’s basically changing the design of iOS to match other platforms that have manual control of the keyboard.

This may well be a solvable problem but none of solutions proposed here seem workable so far.

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