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

Hi @alice and @cynthia,

Thanks for your questions.  

@alice, we're in support of using css environment variables but haven't written a proposal for it yet.  @snianu, could you make an update to the explainer?  Note we think the geometrychange event is necessary even if we have them since an author could want to scroll an element into view, which can't be done with CSS alone.

@cynthia regarding your meta-question, we don't believe that authors want to respond in the same way to all content obstructions.  In the [explainer] (https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/VirtualKeyboardAPI/explainer.md) there are examples that position a searchbox above the keyboard.  The searchbox should likely not be repositioned above a browser dialog or picture-in-picture UI.  For that reason we want to explicitly describe changes in the visibility and position and size of the virtual keyboard.

Responses to your further questions below:

Regarding point 1, we [propose](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/VirtualKeyboardAPI/explainer.md#non-goals) that the author's ability to adjust the site in response to geometry changes for the virtual keyboard is limited to docked virtual keyboards.  That prevents the site from trying to reposition its content while the user is trying to explicitly position the keyboard.  In the image you referenced, I believe that is a floating keyboard.  I don't think there's a docked version of it, is there?

Regarding point 2, related to the answer above, we don't have any known cases where docked keyboards result in multiple obstructions.  

I do realize both of my answers to points 1 and 2 are basically dodging the question by claiming there aren't any current cases that require considering multiple obstructions.  If we do decide we need to develop for that case, I think we could define the existing boundingRect property of the geometrychange event to be the rectangle that bounds all parts, and define an additional sequence of rects representing each part individually.  I would expect sites developed against the current proposed API shape to behave well with a future docked, split keyboard, as there's no requirement to flow content through a split keyboard.  And this future API extension would allow sites that want to be docked, split keyboard-aware to do something more complicated with the new rect sequence.  So in short, we haven't designed for this case, but we see a clear path to solving that case if the need arises.

Regarding point 3, I think my answer to the meta question shows that we don't expect there to be one generalized API to handle all obstructions.  If that was the approach we wanted to take then there is a [Visual Viewport API](https://wicg.github.io/visual-viewport/index.html) which would be the best candidate.  

Note the Virtual Keyboard API's relation to the the Visual Viewport API has been [discussed here](https://github.com/w3c/editing/issues/225#issuecomment-614902156).  I think at least @othermaciej feels differently, but my current thinking is that the API surface of the VirtualKeyboard interface is not limited to just describing the rectangle of how the feature intersects the content: there are hide and show APIs and a property that indicates whether the author has opted out of having the Visual Viewport resize when the virtual keyboard is shown.  IMO its more natural to group these APIs together, under a namespace related to their common purpose, instead of putting APIs to control visibility on one interface, and events that generically describe change to the viewport geometry (that may not relate to the appearance of the virtual keyboard) on the Visual Viewport interface.

Hope that helps.




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