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

At least on iOS, handwriting keyboards are still considered keyboards. And on any platform/browser that allowed inline handwriting speech entry, I would not expect this API to suppress it. Beyond the mobile touch UI model, I'm not sure this API actually generalizes. 

(I'm not clear enough on the intended use case for suppressing dictation UI; I haven't personally seen elaborate UI like that.)

And in any case, I think naming after the most obvious/common use case helps in API just as it does in issue titles. After all, this issue is not titled with "a way to control input panel" b/c it would't be obvious what that means.

One other terminology note: "onscreen keyboard" seems more precise than "software keyboard", even if it's just a description and not in the API name. There can be such a thing as a keyboard totally driven by software which is not on the same screen as the content and which therefore should not be suppressed.

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