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

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

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

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