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

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

Is your specific concern that the developer will rely on the shell to let the user show/hide the keyboard and leave the input controls in manual mode because, e.g. the author prefers to not have the keyboard show up automatically?

I don't think this will happen as it would result in a very poor experience on Windows as well.  When a user taps on an edit control on a touch device (without a hardware keyboard attached) the user expects the VK to automatically appear - just like on iOS.  The touch keyboard button doesn't show up by default.  The user must customize the start bar to show it.  It isn't a prominent feature of the OS like, e.g. the back button is on Android phones.  Author's won't build sites assuming its presence - at least not based on the Windows experience.

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