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

I hiding the keyboard without showing it produces a near-equally-bad experience everywhere, then it likely doesn't have the specific hazard of accidental misuse. It would be nice if it was more clear that it's a feature for experts who are doing things manually. I could imagine having it controlled by script, since the attribute almost certainly should not be respected when JavaScript is disabled.

Additional note: why does the Virtual Keyboard API need to provide metrics for the size of the keyboard? [Visual Viewport API](https://wicg.github.io/visual-viewport/) should already be a way to find out how much space is taken up, whether by the keyboard or other things, including events to monitor it. A number of sites already use it in this capacity, to the point that we implemented it last year so that iPad could better support desktop sites. Seems unnecessary to have two ways to do it.)

(BTW, I prefer "onscreen keyboard" to "virtual keyboard" or "software keyboard", it's more clear about what it actually is. You could imagine a keyboard being "virtual" or software-driven in some way without actually ever appearing on the same screen as content, which is the relevant consideration for these types of features.)

-- 
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-610813934