Devices with a touchscreen mostly offer a On-Screen Keyboard also known as the Virtual Keyboard.
The Virtual Keyboard API Specification has a section how the Virtual Keyboard affects a browser
The Virtual Keyboard (VK) is the on-screen keyboard used for input in scenarios where a hardware keyboard may not be available.
User agents respond to the presence of the VK, without any exposure of this information to web developers in the following way:
- Repositioning the user agent above the VK
- Reducing the size of the layout viewport so the VK doesn't occlude it1
- Reducing the size of the visual viewport and padding the layout viewport to ensure it can be shifted above the VK2
💡 The Virtual Keyboard API adds a fourth option to this list of behaviors.
💡 These findings are a textual representation of the test results table.
The effect of the Virtual Keyboard on the Layout Viewport is currently not interoperable, as some browsers resize the Layout Viewport when the Virtual Keyboard gets shown, while others do not resize it.
Because position: fixed elements are laid out against the Layout Viewport, that might mean that some of those elements get obscured by the keyboard
This latter behavior might be troublesome if authors want to keep an element positioned against the bottom edge, above the Virtual Keyboard when present.
💡 The Virtual Keyboard API has an option to opt-out of resizing the Layout Viewport in case the Virtual Keyboard is present.
Because the ICB is based on the size of the Layout Viewport, browsers that resize the Layout Viewport also resize the ICB.
This difference in resize-behavior has an effect on Viewport Units
The Visual Viewport resizes the the Virtual Keyboard gets shown. This is consistent across Mobile Browsers.
When an element that might get obscured by the Virtual Keyboard gains focus, some browsers auto-offset the Layout Viewport so that the input remains in view.
We are tracking issues using the label Virtual Keyboard