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

This is my personal take as there is not full consensus in the TAG at this point.

I believe virtual keyboards are special enough to warrant a specific API instead of a generic occlusion API. If such a generic API could be created it would be perfect, but I am wondering if there are strong enough use-cases to drive the development of such an API. Example occlusions:

* Other windows
* Picture in picture
* Emoji picker
* Virtual keyboards (even split ones)

I am happy that you included CSS environmental variables as that makes it much easier to use this feature from CSS.

I am also fine with this not being integrated with the Virtual Viewport API given its state of development.

I am a little bit concerned about `navigator.virtualKeyboard.overlaysContent` as it might not be clear that it is a setter, but that is nitpicking. I am more concerned that I as a developer can set it to false, but if the user is using a split keyboard, it is going to overlay content anyways. Maybe it should be an enum like `preferredMode`: `overlay | docket`.

As overlay keyboards are used on existing platforms, supporting them out of the box seems quite important and that is also what I am hearing from @cynthia - This requires the supporting at least two bounding boxes. This also requires additions to the CSS support @atanassov 

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