Re: [w3ctag/design-reviews] VirtualKeyboard API - show/hide policy (#498)

> > For (4) — I would like a bit more clarity on what it means to prevent the visual viewport from being resized due to the appearance of the virtual keyboard. Does that mean the visual viewport should be “pushed upwards” (and retain its size) when the virtual keyboard is brought up? Or that the visual viewport should overlap with the bounds of the software keyboard?
> 
> The latter. The visual viewport will overlap with the bounds of the virtual keyboard when the author sets `navigator.virtualKeyboard.overlaysContent = true`.

Ah, okay. Reading https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md clarified this. iOS's software keyboard always behaves as if `navigator.virtualKeyboard.overlaysContent = true` unless on a website with 100% fixed height when a hardware keyboard is attached (this is a bit of compatibility quirk). We don't change the size of viewport at all. Instead, we change of the visual viewport which is exposed to Web as of iOS 13 / iPad OS 13.

> > For (3) — it wasn’t totally clear to me why the visual viewport API isn’t already sufficient for this purpose. Is it because the VisualViewport API isn’t compatible with devices with multiple screens, when the software keyboard only takes up space in one of the screens?
> 
> Philosophically the visual viewport API isn't sufficient because when then the keyboard overlays the content the visual viewport remains unchanged. IMO the visual viewport API should not describe events that don't affect the size of the visual viewport.

That ship may have sailed already. Multiple websites including GSuites and Microsoft Live 365 seem to rely on visual viewport API to detect the currently visible region of the content. We had to do a lot of work in iPad OS 13 to make that work.

> Additionally, as you mention, the visual viewport describes a rectangular viewport, which is problematic for virtual keyboards on dual screen devices because those would create an L-shaped visual viewport if we don't want to waste space as shown in [this explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md#motivation).

Ah, ok. We also have a [split keyboard](https://support.apple.com/guide/ipad/use-a-split-keyboard-ipad997da62f/ipados) on iPad OS so we have a similar issue there. Now, there is a bit of an issue with regards to fingerprintability if we were to expose the exact size & location of keyboard because these split keywords can be dragged up & down by the user and stays there. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/498#issuecomment-672399332