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

Yes, the work continues.  We have an implementation behind a flag in Chromium browsers which matches our explainer and will turn our explainer into a spec sometime soon.

I reopened this issue (https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/389) for now while our discussion continues.  Apologies for closing it prematurely.

> But what we see is the actual occlusion still inside the virtualKeyboard object.

Yes.  We describe how a docked, overlaid virtual keyboard object occludes the layout viewport via the VirtualKeyboard interface.

I made an argument in the issue linked above as to why the virtual keyboard seems like a special case when compared with other examples like picture-in-picture or windows that overlap with the browser in a desktop OS.  Here's the relevant bit:

> In general I don't think we want to report all the things layered over top of the visual viewport. I wouldn't want web pages updating their layout as I ALT+TAB to another application that overlaps my browser, or have a web page fight me as a drag around a floating keyboard or a picture-in-picture window.
>
>The "docked" virtual keyboard is a special case. When it appears, users do expect to be able to see what they're typing, but authors may not want the experience we offer by default. L-shaped viewports aside, adjusting the visual viewport means we'll be creating the "slop" I describe above and jumping part of the page out of the visual viewport to ensure the user can see the blinking caret. If I'm an author that has created a web application whose UI fits in 100vw x 100vh, I might rather adjust the height of one of my subscrollers rather than "unglue" my UI so that the user can start panning it around.

So with regards to this comment:

> it's still unclear how the user is supposed to enumerate these occlusions.

My answer is that I don't want authors to be able to enumerate other arbitrary occlusions.  If there are some specific occlusions that make sense, then I'd like to consider those when we have the specifics.  I'm not aware of any customers asking to relayout their UI while other application windows are being moved around or the user moves the floating keyboard or the user repositions picture-in-picture.  If there were such requests, I would still be skeptical whether exposing that information would really enable better user experiences.

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