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

_...I'm a late to the party on this, but I'll share my thoughts anyways..._

As a web app developer, the virtual keyboard and it occluding content is unique/specific enough to warrant the functionality to be scoped to its own API, and `navigator.virtualKeyboard`/`navigator.virtualKeyboard.overlaysContent` makes sense for implementing associated scenarios in a web application.

In my mind, attempting to lump the functionality into with Visual Viewport does nothing but over complicate the the mental model for how to think about and approach scenarios related to virtual keyboard (which are very targeted and different from any other Visual Viewport interactions). Additionally, I think we also need be mindful of not trying to come up with a "kitchen sink" solution that solves for unrelated scenarios that don't exist today... doing this could lead to an over-engineered solution that ends up being too complicated for practical purposes.

As it relates to occluding content, I feel the `virtualKeyboard` API should encapsulate allowing web developers to have knowledge about its presence/dimensions (`overlaygeometrychange` and `boundingRect`) and be able to tell the browser to automatically occlude the content or not (`overlaysContent`).

I'm happy to discuss this in more detail.

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