Re: [w3ctag/design-reviews] Virtual Keyboard API - boundaries of docked overlay keyboard (#507)

We talked about this in our meetings this week.

Firstly, in terms of the specifics of this API:
- We would prefer if the bounding rect property lived on the `virtualKeyboard` object (as a "live" set of bounds), rather than requiring authors to capture it from the `geometrychange` event. Is there some reason this is infeasible or not desireable?
- It would be helpful to illustrate when the `geometrychange` event would be more useful than the CSS environment variables - the existing example seems like it would be better handled by the CSS environment variables. @kenchris noted that canvas-based UIs would be one example of where you'd need to set a position directly.
- Also, in that example it's not clear how the author knows that the search box is on the same side of the split-screen as the keyboard - could this be included in the example code?
- We had some doubts as to whether `navigator` was the right place for the `virtualKeyboard` object to live, as opposed to `window`. What was the reasoning behind this choice?

Secondly, in terms of solving the general problem of informing the web page about occlusions, it does seem like `VisualViewport` is trying to solve some of the same problems, but is extremely limited (for example, it assumes the visual viewport is a rectangle).

I'm a little lost as to whether `VisualViewport` is intended to account for whether or not the virtual keyboard is overlaying page content or not - to me it reads as if it assumes the keyboard is overlaying page content, since otherwise it will be the same as the layout viewport.

These comments of Maciej's strike a chord:

>  I think Visual Viewport API could be enhanced to report individual overlay rects. That way, authors who want to adapt to available screen space won't have to juggle two different APIs. And we won't need to invent still other new APIs for other forms of onscreen overlays, like PIP, or the iPadOS Universal Callout Bar which appears even with a hardware keyboard attached.

Indeed, the "geometrychange" event is very similar to the "onresize" event on `VisualViewport`.

It would be a shame to miss an opportunity to design a general purpose API for these various types of screen occlusions. I wonder whether `VisualViewport` could contain a collection of objects with a common interface, of which `virtualKeyboard` could be one.

-- 
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/507#issuecomment-665473068