Re: [w3ctag/design-reviews] VirtualKeyboard API - show/hide policy (#498)

> In both cases, the visual viewport size is changing, right? 

No.  In the second example the browser window (meaning the OS window), the browser's visual viewport size, and the browser's layout viewport size are all unchanged.  `bottom: 0;` for the bottom fixed element refers to a position under the virtual keyboard.  

In contrast, in the first example, `bottom: 0;` refers to a position that might be under the keyboard or maybe above the keyboard.  Because the visual viewport has a reduced height, the user can pan to move the bottom of the layout viewport around so that it can be shown in different locations.

> When the keyboard is shown, the visible part of the web page is literally smaller unless you're talking about overlaying the software keyboard atop the web page. 

Yes.  I'm talking about overlaying the virtual keyboard atop the web page contents.  That's why the property is `virtualKeyboard.overlaysContents` :-).  If the keyboard were translucent, and if the author left the bottom fixed element positioned using `bottom:0;` then you would see the element showing through beneath the keyboard.

The [dual screen example](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md#repositioning-content-on-foldable-devices) in the explainer should help make that clear since the virtual keyboard only overlays half of the viewport, which lets the user see the other half.  Allowing the visual viewport to resize in this case would be detrimental because as the user pans around there would be a blank space below the `locations-list` sub-scroller (which has its height set to 100vh).  That would look something like the picture labeled "not ideal UX" in the [explainer's motivation section](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md#motivation).

> The fact the user can't scroll the page is incidental in that it's the result of the page resizing itself to view visual viewport's height.

No.  As I mention above the page did not resize itself; in both examples, the layout viewport remains unchanged - so it's the opposite of what you're saying: not resizing the visual viewport (and leaving it as the same size as the layout viewport) is what prevents the user from panning.

> I'd go back & solicit more feedback based on this new understanding of what you're proposing.

Did you mean to write *I'll* go back and solicit more feedback - meaning that you'll go back and solicit feedback from Apple folk based on your new understanding?  Just making sure you aren't saying that if you were me, you'd go back and get more feedback based on this better explanation.  :-)

Thanks again for the quick responses!
Bo

-- 
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/498#issuecomment-698156073