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

I think there is some confusion here. Show/Hide APIs that is on VirtualKeyboard interface, is just a way to explicitly trigger VK. Calling show/hide when `virtualKeyboardPolicy="manual"` is not required to raise/dismiss VK. Web authors could also switch from `virtualKeyboardPolicy="manual"` to `virtualKeyboardPolicy="auto"` dynamically without explicitly calling Show/Hide APIs if they wanted the VK to appear on maybe next tap on the edit control when the initial state of the VK was hidden. We propose Show/Hide APIs to let authors have some explicit control over the VK behavior when they want to handle more complicated scenarios (described in the explainer) that couldn't be achieved without these APIs.
Currently `inputMode="none"` is used to suppress VK, but we investigated that this attribute value doesn't cover all the scenarios that are needed by the sites that require more than 
just suppressing the VK on the initial tap. Moreover, inputMode controls the layout of the VK and doesn't provide an explicit control of the VK without affecting the layout 
(This is what we were trying to convey in [these ](https://github.com/whatwg/html/issues/4876) discussions about changing the definition of what this value does, but I guess 
we decided on keeping it as it has compat problems). 
There are also cases where the sites need to know the geometry of the VK in order to properly layout its contents when parts of it are occluded by the VK. The [VirtualKeyboard](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/VirtualKeyboardAPI/explainer.md) interface has APIs that address this issue too.

Re permissions: VirtualKeyboard is a feature provided by the OS (Text Input service on Windows to be more precise) and not the Browser. If the VK doesn't work on a platform, then 
the user most likely would blame the OS and not the Browser (as seen from user studies that we've done internally). This is why we provided an option to let users have a say as to 
when the VK should be controlled by the site vs the browser default behavior. If the site is malfunctioning due to the policies that affect the VK behavior, then at least users have an
option to deny the VK permissions and let Browser control the VK and ignore the policies mentioned by the site. This is just an option that we thought would be helpful to address
some concerns regarding abuse of these APIs by the web authors.

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