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

> > Ah, okay. Reading https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md clarified this. iOS's software keyboard always behaves as if `navigator.virtualKeyboard.overlaysContent = true` unless on a website with 100% fixed height when a hardware keyboard is attached (this is a bit of compatibility quirk). We don't change the size of viewport at all. Instead, we change of the visual viewport which is exposed to Web as of iOS 13 / iPad OS 13.
> 
> @rniwa Sorry for the slow reply, but the comment above I don't think is true. On my iPhone, when the virtual keyboard is shown, the height of the visual viewport is reduced while the layout viewport remains at the same height. It sounds like you agree that's what happens from your last sentence.

The height of the virtual viewport is, but not the viewport's. I think there is some kind of terminology confusion here. Basically, when the software keyboard comes up in iOS, there is no change to the root box's height. Meaning that it won't cause the content to resize to its new height of the viewport that's visible to the user. Instead, the logical size of the viewport used to layout the page stays the same regardless of whether the keyboard is shown or not, and the software keyboard simply overlays atop the content as the proposal suggests.

> In contrast, if `navigator.virtualKeyboard.overlaysContent = true`, then the visual viewport should not change when the virtual keyboard is shown or hidden.

I don't see how this will be a meaningful distinction if you're truly talking about the the visual viewport as described in https://wicg.github.io/visual-viewport/. Such a concept is only observable via JavaScript. Why would be useful to not change this value?


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