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.

There is no confusion there.

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

Nor here.

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


I understand that's a scenario important on your platform (e.g. Surface), but that's wholly adequate on iOS and iPadOS. And what you're proposing isn't not gonna work on our platform because there is simply not a mechanism for user to control when a virtual keyboard will be shown, and override what a website is doing.

> 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 problematic for us either way since we make both the browser and OS. In general, we don't want user experience to degrade because there was an oversight by an author.

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

Again, we don't think permission is the right model for this. Users aren't going to understand what it means, and in cases where it works, it fatigues users of permission dialogs / sheets.

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