- From: Kenneth Rohde Christiansen <notifications@github.com>
- Date: Tue, 23 Mar 2021 01:36:10 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/507/804719637@github.com>
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
Received on Tuesday, 23 March 2021 08:36:23 UTC