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.

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. What I'm saying is that if a web page is smart enough to know there could be a software keyboard & be able to adjust page's content to reflect that state, then I don't see why the fact we don't allow scrolling by not adjusting visual viewport is important. The website is so sophisticated that it can reveal the newly focused editable part of the page on its own. Surely, it knows how to make it not scrollable.

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

Yeah, I get it. But to me, a more important part is not scrolling. I get that in the specific example you're talking about where page's height is already 100%, what you're proposing will do the trick but in general, there are many other cases where scrolling to the newly focused element to bring up software keyboard is problematic and causes a stutter. Imagine apps that necessarily has the main scrollable area that's higher than the viewport.

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

I meant to say "I would" in the sense of "I will" :)  I think some mechanism to avoid scrolling when brining up software keyboard will be useful. We've had many issues when we made Safari on iPad load desktop sites.

While I go back & gather feedback on my end, I'd like to bring up a couple of edge cases to consider. On iPad, we have [split keyboard](https://support.apple.com/en-us/HT207521) and [floating keyboard](https://support.apple.com/en-us/HT210758) both of which are keyboards that simply overlays on top of the app / web content. Presumably in these cases, `keyboard-inset-height` would be 0. We also have a sort of a toolbar that shows up at the bottom of the app when a hardware keyboard is connected.

Finally, the height of keyboard will depend on what kind of keyboard will come up, and that's dependent on the context as well as user's preferences. Leaving what kind of keyboards can show up and how the dimension of such a keyboard to a website seems dangerous to me. We had a lot of trouble making Safari on iPad work with Google docs and Microsoft Office 365. We don't want to make the situation worse by forcing web developers to make assumptions about how software keyboard work.

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