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

> In the single screen world, I think `visualViewport.onresize` is equivalent to `virtualKeyboard.ongeometrychange`.

No I don't think so.  Resizing the visual viewport (without resizing the layout viewport) gives the user the ability to pan around the layout viewport within the smaller visual viewport.  You point that out later in your response.  If we aren't resizing the visual viewport (so no resize event) or the layout viewport, then you do need some event and/or CSS env variable to allow the author to relayout the page.  That's why we propose `geometrychange` and `env(keyboard-inset-*)` - because they will be applicable when `visualViewport.onresize` is not.

> It seems like the statement above presupposes the existence of only 2 and 3? Or am I misreading it?

I think it's fair to say that this proposal is only interesting on devices that have a visual viewport adjustment to compensate for the appearance of the virtual keyboard.

> FWIW we wanted to move Chrome Android to the second model but got blocked on an API to get back to the first.

One of my devs is on a thread with you and other Googlers now to figure out how to put Chromium on Android into category 2.  There are [new APIs on later versions of Android](https://proandroiddev.com/exploring-windowinsets-on-android-11-a80cf8fe19be) that seem promising and for older versions we're exploring extending some of the work you've done in the past.

>...we wanted an option between 1 and 2.  This provides an option between 2 and 3. But I think this may be equivalent, if you have the 3rd option then I think you can just transform everything up or shrink it by the keyboard-inset-height. Because the visual viewport isn't shrunk it remains unscrollable.

Yes I think our current proposal is what you are looking for :-)

>> Okay so then it goes back to my earlier point: the fact visual viewport is smaller doesn't matter. It's true that when the visual viewport gets smaller, then the user may be able to scroll the page but only if the page height's bigger than the new visual viewport size, right? If this page was smart enough to resize it so that the scrolling won't be possible, then whether visual viewport got smaller or not doesn't matter because the page isn't scrollable in the first place.
>>
>I don't think this is true. The visual viewport scrolls within the layout viewport. Making the content smaller than the layout viewport doesn't change the size of the layout viewport. e.g.

@rniwa What David is saying matches my experiments.  If you pull [this test page](https://bocupp-microsoft.github.io/VirtualKeyboard/fixed-top.html) up on your iPhone, you'll see that when the virtual keyboard appears you can still pan the input element up and out of the visual viewport.  It doesn't matter that there isn't any other content in the document below the keyboard.

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