Prevent content from being hidden underneath the Virtual Keyboard by means of the VirtualKeyboard API

~

The Problem

The current behavior on mobile devices in Safari on iOS is that as the keyboard gets shown, the Layout Viewport remains the same size but the Visual Viewport shrinks. Because layout items with position: fixed; bottom: 0; get anchored to the Layout Viewport, these items can become hidden underneath the Virtual Keyboard (or bleed out from the top in case they use top: 0;). To counter this, Safari offsets the Layout Viewport so that the focussed content remains in view.

Layout Viewport and Visual Viewport Behavior when the Virtual Keyboard gets shown (src).

Once once you start scrolling the page upwards again, the whole Layout Viewport will move position, and thus the item-at-the-bottom will be hidden underneath the keyboard again.

On Chrome on Android, the Layout Viewport will shrink when the keyboard gets shown, matching the height of the Visual Viewport. Chrome, as of version 108, mimics what iOS does.

~

A Theoretical Solution

To deal with this non-resizing you could use the Visual Viewport API and manually offset items once the Virtual Keyboard gets shown.

let pendingUpdate = false;

function viewportHandler(event) {
	if (pendingUpdate) return;
	pendingUpdate = true;

	requestAnimationFrame(() => {
		pendingUpdate = false;
		
		// Stick to top
		document.querySelector('[data-stickto="top"]').style.transform = `translateY(${ Math.max(0, window.visualViewport.offsetTop)}px)`;
		
		// Stick to bottom
		if (window.visualViewport.offsetTop >= 0) {
			document.querySelector('[data-stickto="bottom"]').style.transform = `translateY(-${Math.max(0, window.innerHeight - window.visualViewport.height - window.visualViewport.offsetTop)}px)`;
		}
	});
}

window.visualViewport.addEventListener("scroll", viewportHandler);
window.visualViewport.addEventListener("resize", viewportHandler);

Having played with it, I found this approach to be impractical and lacking:

• Extra Math needed to deal with overscrolling
• iOS: Only updates after scroll has finished
• Android (Emulator): Scrolling becomes glitchy

~

A Proper Solution

As mentioned in The Large, Small, and Dynamic Viewports there’s a new kid in town that can help us out here: the VirtualKeyboard API.

With the API you can programmatically — e.g. via JavaScript — trigger the Virtual Keyboard and get its dimensions, but what I find more interesting is that it also provides some CSS environment variables:

• keyboard-inset-top
• keyboard-inset-right
• keyboard-inset-bottom
• keyboard-inset-left
• keyboard-inset-width
• keyboard-inset-height

The keyboard insets are six environment variables that define a rectangle by its top, right, bottom, and left insets from the edge of the viewport. Default value of the keyboard insets are “0px”

By default all these variables have a value of 0px. When the keyboard gets shown the value for keyboard-inset-height will change to reflect the height of the Virtual Keyboard. You can then use this as the bottom-margin on an element that’s anchored to the bottom of the Viewport:

.bottom-box {
  position: fixed;
  bottom: 0;
  margin-bottom: calc(20px + env(keyboard-inset-height));
}

In the new behavior the both the Visual Viewport and Layout Viewport will not shrink as the Virtual Keyboard gets shown. As a developer you now have to manually take the keyboard dimensions into account to position items.

In a layout that uses CSS Grid, you can easily take this value into account to create a bottom-zone where nothing may be placed:

body {
    display: grid;
    height: 100vh;
    grid-template:
      "messages"  1fr
      "input"     auto
      "keyboard"  env(keyboard-inset-height, 0px);
}

The Grid Area named keyboard with either be 0px high or take up the size of the Virtual Keyboard, thus pushing the input Grid Area upwards as the keyboard gets shown.

~

The catch

To enable this new behavior, you need this little JS snippet:

if ("virtualKeyboard" in navigator) {
  navigator.virtualKeyboard.overlaysContent = true;
}

Personally I find this JS-requirement a shortcoming of this API. An extension to the meta name="viewport" (or perhaps a new CSS at-rule or property on <html>?) to control the behavior seems like something handier.

Something like this:

<!-- Proposal -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, virtual-keyboard=overlays-content">

Or this:

/* Proposal */
html {
  virtual-keyboard: overlays-content;
}

(Names to be bikeshed but you get the point)

<meta name="viewport" content="width=device-width, initial-scale=1.0, interactive-widget=resizes-content">

~

Browser Support

The VirtualKeyboard API is shipping with Chromium 94. Other browser vendors have not signalled any interest in it yet. Relevant Issues:

• Gecko/Firefox: Issue #1730568
• WebKit/Safari: Issue #230225

~

More Info

There’s a good post up on web.dev that goes into more detail on the JavaScript interface I quickly mentioned. Be sure to give a read if you want to use the VirtualKeyboard API with your JavaScript-based apps. It also taps into the virtualkeyboardpolicy attribute you can use along with that.

~