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

> I think there are more scenarios than just multi-screen that make device-fixed unsuitable. How would you implement the canvas spreadsheet scenario mentioned in the explainer?

The original intent behind the visual viewport was to allow us to give the "overlay" style behavior (for both keyboard and pinch-zoom) while letting apps accommodate to it if they put in the effort. The events on `visualViewport` provided a programmatic hook while `position: device-fixed` would have allowed some declarative layout.

In the single screen world, I think `visualViewport.onresize` is equivalent to `virtualKeyboard.ongeometrychange` and could be used to solve this use case. Granted, it doesn't extend naturally for non-rectangular viewports as happen in multiple screens.

Reading the explainer:

> An author must first opt-in to the new behavior (i.e. opt-out of visual viewport changes in response to visibility changes of the virtual keyboard)

The current behavior as I understand it falls into one of the following buckets:

 1. Resize the layout viewport (and implicitly the visual viewport. Also cause the page to reflow). This happens on Chrome Android 
 2. Resize the visual viewport but not the layout viewport. This happens on ChromeOS and iOS 13+(IIUC)
 3. Resize nothing (@rniwa can correct me if I'm wrong) I think this was the iOS behavior prior to 13 and is the opt-in proposed here.

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

FWIW we wanted to move Chrome Android to the second model but got blocked on an API to get back to the first. In some apps, you really do want the window/layout viewport to resize so that the result isn't scrollable in the visual viewport. e.g. a messenger app where the message history is scrollable but the input box should stay fixed to the bottom.

i.e. 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.

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

```html
<style>
  html {
    width: 50%;
    height: 50%;
    background-color: red;
  }
  body, div {
    width: 100%;
    height: 100%;
    background-color: green;
  }
</style>
<html>
  <body>
    <div></div>
  </body>
</html>
```

The red area will remain scrollable when keyboard comes up or the user pinch zooms in and there's no way for an author to prevent this if we don't resize the layout viewport (point 1 above). Or does Safari behave differently?

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

Received on Thursday, 24 September 2020 22:29:15 UTC