This was previously discussed in https://github.com/whatwg/html/issues/4876 and given the last comment there I'm somewhat surprised it's now resurfacing here.

@annevk Looking at the explainer, this new behavior is opt-in

As this actually seems to touch two different areas - there are even two different explainers - we should probably split this up into two issues

I split up part of this into https://github.com/w3ctag/design-reviews/issues/507

There are a lot of good use-cases here: https://github.com/whatwg/html/issues/4876#issuecomment-541232517

I think these would be good to add clearly to the explainer

@snianu Given the feedback from @annevk above, is this proposal a conflict resolution request, or is there a misunderstanding and this review does not touch on the issue mentioned? Would be good to have a clarification.

Thank you everyone for all the feedback! @cynthia @annevk This issue specifically talks about inputMode attribute and this comment was about deprecating inputMode="none"'s special behavior of hiding the VK which we believe is conflating two different states and doesn't cover some of the scenarios mentioned in the explainer. This feature gives explicit control of the VK to the web authors. It also defines an attribute that differentiates between the custom (virtualKeyboardPolicy="manual") and default(virtualKeyboardPolicy="auto") VK behavior. When virtualKeyboardPolicy is "manual", inputMode ="none" 's hiding of the keyboard state is ignored, but the default VK layout is kept intact. Basically, with virtualKeyboardPolicy attribute, the web authors could control the VK behavior without affecting the layout of the VK which would be controlled by the inputMode attribute. These two states (visibility and layout of the VK) are kept separate in this proposal so web authors can use it to facilitate more complicated scenarios on their sites. The new API can be feature-detected by checking for the existence of the virtualKeyboard property on the navigator object.

@kenchris This section talks about the range-peeking scenario in Excel that sort of merges the two use cases that were mentioned in this comment, but I agree that we should explicitly mention that in the explainer. I'll create an issue in our repo and address that in the explainer.

@snianu from what Ryosuke stated it seems unlikely to change however, which is more relevant I'd think.

(@annevk's referring to this comment of @rniwa's from February.)

@rniwa could you please clarify your objection from this comment?

I believe you are objecting to any deprecation or change in behavior for inputmode=none.
This proposal doesn't suggest we deprecate inputmode=none.

I think the root of the confusion is that inputmode=none has some overlap with the VK APIs (but isn't a replacement) so at one point it was suggested that we could deprecate inputmode=none since we would have the more capable VK API. @rniwa is saying that wouldn't be acceptable as inputmode=none has been promoted and is being used to dismiss the keyboard in some scenarios.

We therefore abandoned the idea of deprecating inputmode=none (in response to @rniwa's comment), but that doesn't mean we don't need the VK API. The VirtualKeyboard interface and the virtualKeyboardPolicy attribute provides authors with the ability to:

1. Request that the keyboard be hidden
2. Request that the keyboard be shown
3. Handle an event for when the keyboard changes its visibility and adjust to the size and position of the keyboard
4. Prevent the visual viewport from being resized due to the appearance of the VK

inputmode=none only addresses the first of those capabilities and comes with side effects that are discussed in the same github issue (see here).

Hope that helps clarify things. I don't believe there is any conflict here.

I've been on a medical leave. Hopefully @whsieh can clarify our position here.

Given the comments from @BoCupp-Microsoft above, we'd like to hear if there is still strong objection with regards to the new proposal, as we don't find it as controversial as we initially thought. Can @whsieh or someone else comment on the objection points?

Sorry for the delay; I have a couple of questions below:

For (3) — it wasn’t totally clear to me why the visual viewport API isn’t already sufficient for this purpose. Is it because the VisualViewport API isn’t compatible with devices with multiple screens, when the software keyboard only takes up space in one of the screens?

For (4) — I would like a bit more clarity on what it means to prevent the visual viewport from being resized due to the appearance of the virtual keyboard. Does that mean the visual viewport should be “pushed upwards” (and retain its size) when the virtual keyboard is brought up? Or that the visual viewport should overlap with the bounds of the software keyboard?

For (4) — I would like a bit more clarity on what it means to prevent the visual viewport from being resized due to the appearance of the virtual keyboard. Does that mean the visual viewport should be “pushed upwards” (and retain its size) when the virtual keyboard is brought up? Or that the visual viewport should overlap with the bounds of the software keyboard?

The latter. The visual viewport will overlap with the bounds of the virtual keyboard when the author sets navigator.virtualKeyboard.overlaysContent = true.

For (3) — it wasn’t totally clear to me why the visual viewport API isn’t already sufficient for this purpose. Is it because the VisualViewport API isn’t compatible with devices with multiple screens, when the software keyboard only takes up space in one of the screens?

Philosophically the visual viewport API isn't sufficient because when then the keyboard overlays the content the visual viewport remains unchanged. IMO the visual viewport API should not describe events that don't affect the size of the visual viewport.

Additionally, as you mention, the visual viewport describes a rectangular viewport, which is problematic for virtual keyboards on dual screen devices because those would create an L-shaped visual viewport if we don't want to waste space as shown in this explainer.

For (4) — I would like a bit more clarity on what it means to prevent the visual viewport from being resized due to the appearance of the virtual keyboard. Does that mean the visual viewport should be “pushed upwards” (and retain its size) when the virtual keyboard is brought up? Or that the visual viewport should overlap with the bounds of the software keyboard?

The latter. The visual viewport will overlap with the bounds of the virtual keyboard when the author sets navigator.virtualKeyboard.overlaysContent = true.

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.

For (3) — it wasn’t totally clear to me why the visual viewport API isn’t already sufficient for this purpose. Is it because the VisualViewport API isn’t compatible with devices with multiple screens, when the software keyboard only takes up space in one of the screens?

Philosophically the visual viewport API isn't sufficient because when then the keyboard overlays the content the visual viewport remains unchanged. IMO the visual viewport API should not describe events that don't affect the size of the visual viewport.

That ship may have sailed already. Multiple websites including GSuites and Microsoft Live 365 seem to rely on visual viewport API to detect the currently visible region of the content. We had to do a lot of work in iPad OS 13 to make that work.

Additionally, as you mention, the visual viewport describes a rectangular viewport, which is problematic for virtual keyboards on dual screen devices because those would create an L-shaped visual viewport if we don't want to waste space as shown in this explainer.

Ah, ok. We also have a split keyboard on iPad OS so we have a similar issue there. Now, there is a bit of an issue with regards to fingerprintability if we were to expose the exact size & location of keyboard because these split keywords can be dragged up & down by the user and stays there.

@bokand I think you should be aware of this discussion and maybe pitch in

Should we find a slot to discuss this during virtual TPAC?

@mustaqahmed is probably the best person from the Blink side

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.

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

Should we find a slot to discuss this during virtual TPAC?

@cynthia I think that's a good idea. Could someone suggest a forum?

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?

@rniwa Thanks for the quick reply.

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?

It isn't just a value only visible to JavaScript; the difference can be perceived by the user.

Consider this markup...

<!DOCTYPE html>
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
    body {
        margin: 0;
        font-family: sans-serif;
        font-size: 40px;
    }
    .top, .bottom {
        position: fixed;
        width: 100vw;
        padding: 20px;

        display: grid;
        place-items: center;
    }
    .top {
        top: 0;
        background-color: blue;
    }
    .bottom {
        bottom: 0;
        background-color: green;
    }
    input[type=text] {
        font-family: sans-serif;
        font-size: 40px;
        padding: 10px; 
    }
</style>
<div class="top">TOP FIXED</div>
<div class="bottom">BOTTOM FIXED <input type="text" placeholder="put focus here..."></div>

When the virtual keyboard is displayed:

1. the height of the visual viewport is reduced
2. the focused element is scrolled into view (which scrolls a portion of the page that was visible in the layout viewport out of the visual viewport)
3. the user can see the "slop" created by the offset between the visual viewport and the layout viewport by panning around

It looks like the image below:

AFAICT this is the same type of behavior I see on my iPhone: test page.

Now consider this markup which per our proposal would cause the visual viewport to not resize:

<!DOCTYPE html>
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
    body {
        margin: 0;
        font-family: sans-serif;
        font-size: 40px;
    }
    .top, .bottom {
        position: fixed;
        width: 100vw;
        padding: 20px;

        display: grid;
        place-items: center;
    }
    .top {
        top: 0;
        background-color: blue;
    }
    .bottom {
        bottom: env(keyboard-inset-height, 0);
        background-color: green;
    }
    input[type=text] {
        font-family: sans-serif;
        font-size: 40px;
        padding: 10px; 
    }
</style>
<div class="top">TOP FIXED: virtual keyboard overlays content</div>
<div class="bottom">BOTTOM FIXED <input type="text" placeholder="put focus here..."></div>
<script>
    navigator.virtualKeyboard.overlaysContent = true
</script>

In this example, because the author set navigator.virtualKeyboard.overlaysContent = true:

1. the visual viewport is not resized when the virtual keyboard appears
2. the author updates the layout of the document using proposed CSS (bottom:env(keyboard-inset-height, 0) ) to ensure the input element is visible
3. the user can't pan the content; it stays "glued" to the viewport

It looks like the picture below:

As an aside, I can see that running script to opt the document into overlaysContent behavior is inconvenient when the rest (for this simple case) can be handled in CSS. I'll file an issue in the MSEdgeExplainers repo to offer a declarative mechanism.

In both cases, the visual viewport size is changing, right? 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. 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.

So it seems to be more fundamental thing you're really proposing is that the browser doesn't try to reveal the focused element when the software keyboard comes up.

Anyway, thanks for that example. It clarifies what you're really proposing. I'd go back & solicit more feedback based on this new understanding of what you're proposing.

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

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

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 and floating keyboard 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 where and how the dimension of such a keyboard can be measured totally up to UA or have a website figure it out 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.

Let me add this: in my experience working with Safari on iPad for desktop sites is that the visual viewport becoming smaller and making the page scrollable once software keyboard is up isn’t the issue. The biggest issue we experienced was that when the browser decides to bring up software keyboard, it would start scrolling the page before it can notify the page that the visual viewport size has changed and it had the chance to shrink itself or some other means to prevent scrolling. In fact, if I recall correctly, there was even a site with a pretty big blank space at the end of the page for some reason and it always allowed scrolling via scripts.

Another example is a website that uses hidden content editable. We had to add a bunch of heuristics to avoid scrolling to reveal the focused element in such cases.

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.

This means that the content under the keyboard is effectively unreachable unless the keyboard is dismissed, right?

VisualViewport was meant to address exactly this kind of scenario (along with position: device-fixed which IIRC Edge/IE implemented) but unfortunately didn't foresee the multi-screen use case.

I recall discussing it at some point but is the multi-screen model documented somewhere? Is it that the two screens effectively form one big rect as far as the page and layout is concerned? i.e. visual viewport reports one bigger screen?

This means that the content under the keyboard is effectively unreachable unless the keyboard is dismissed, right?

Yes, unless the author uses the proposed CSS env(keyboard-inset-*) variables or geometrychange JS event to update the layout of the page.

VisualViewport was meant to address exactly this kind of scenario (along with position: device-fixed which IIRC Edge/IE implemented) but unfortunately didn't foresee the multi-screen use case.

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?

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.

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

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

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.

I may have misspoke above. In talking with @snianu he reminded me that whether you have layout and visual viewport adjustments (category 1) or just visual viewport adjustments (category 2) there's still benefit in letting the author opt-in to not adjust either (category 3).

The dual screen scenario on foldable devices where the keyboard appears only on one screen is still a major beneficiary of not adjusting either viewport regardless of whether it was originally category 1 or 2.

@rniwa following up on one of your earlier points which I didn't respond to yet:

On iPad, we have split keyboard and floating keyboard 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.

Yes the height would be 0. We wrote something about floating keyboard UI in the explainer under the non-goals section. In short, we don't want the author to compete with the user when the user is in charge of positioning the keyboard.

Do we want to have a virtual F2F discussion on this topic? I'm willing to meet up just with the people on this thread or at a larger venue during virtual TPAC. Let me know if anyone has suggestions for a venue.

Also, I think we're trending towards agreement. I'm interested in finding collaborators that would like to co-author a spec. Please let me know if your interested. Past experience writing specs would be a big plus. :-)

It seems worth discussing this as a breakout session: https://www.w3.org/wiki/TPAC/2020/SessionIdeas

Sounds like this discussion is going to happen at TPAC. That's great. Please let us know if you want someone from the TAG to join. I'll bump this issue until after TPAC and we can pick it back up then.

@rniwa @torgo @kenchris @snianu @cynthia @whsieh @bokand I've proposed a breakout session here called Virtual Keyboard Control. Right now I have the session marked so that it will be scheduled during the 2pm UTC golden hour that was suggested on either Wednesday, Thursday or Friday of the breakout week. Hopefully that will work for anyone that would like to attend. If not, let me know and I can always just schedule something outside of TPAC.

@BoCupp-Microsoft Can you post a summary of the relevant discussion at TPAC?

Meeting minutes: https://www.w3.org/2020/10/30-editing-minutes.html Summary of the discussion: We discussed about the VirtualKeyboard APIs and how it affects UX on both dual and single screen devices. The presentation was mainly focused on describing the problems faced by web authors while dealing with virtual keyboard(VK) on touch devices where the VK is the primary source of text input for users. We showed a demo of the VK APIs and how the authors could use it to provide a much better UX experience on their sites. Demo page: https://bocupp-microsoft.github.io/VirtualKeyboard/geometrychange.html Slides: https://cuppfamily-my.sharepoint.com/:p:/g/personal/bo_seattlecupps_com/EVoI7Hp5An1HokezOTE3hK0BLMT2UsL1k7-ryO8-8efv6w?e=EplB9S

Issue discussions:

• Concerns about VK APIs being abused and sites behaving poorly because of that: We currently have sticky user activation and active document as a requirement to restrict showing the VK. VK APIs are also an opt-in mechanism where authors have to explicitly indicate that they would like to control the VK behavior. Currently the show/hide behavior can be abused by using inputMode property.
• Is navigator the right place? We didn't get a chance to discuss this in detail, but I haven't seen any objections in this issue after the latest response.
• Relationship with the VisualViewport API and concerns in general regarding creating a separate API to handle overlaying of content in response to VK show/hide: We had extensive discussions on this issue. We generally agree that having a separate event describing the overlay property and geometry of the VK helps the authors make better decision as to how to position specific parts of the webpage in response to VK occluding the content of the webpage.
• Have VK show/hide APIs return a promise We all agreed that returning a promise when authors call show/hide helps to test the APIs and also make decisions when the calls failed to show/hide the VK. This needs more discussion as we are not entirely sure that returning an error code helps the authors in a meaningful way.
• We are also looking for collaborators to write a spec for these APIs. @BoCupp-Microsoft Please let me know if I missed anything.

I also saw that you added support for using CSS environment variables for the geometry in addition to the JS API :+1:

Based on the discussions above - we took this up in the plenary call this week and decided we're happy to see this move forward. Thanks for bringing this to our attention!

Hello TAG,

Based on the comment from @cynthia here, could you update the labels on this issue to include Resolution: satisfied?

Thanks for your help on this! Bo

Tagging a couple other members so this comment gets seen: @atanassov @kenchris

Done!