ICB/LVP vs Virtual Keyboard, and the effect on Viewport Units

[bramus]

When an input gains focus, some devices – mostly mobile devices – will expose a Virtual Keyboard. As found through testing, some browsers resize the Layout Viewport – and thus the ICB – when doing so. Other browser do not resize the Layout Viewport in that case.

Resizing the Layout Viewport affects where position: fixed elements end up. These elements get laid out against the edge of the Layout Viewport. By (not) resizing the Layout Viewport, they might end up in different places in different browsers

• The behavior where the Layout Viewport does not get resized, is handy for keeping Bottom Nav Bars at the very bottom.
• The behavior where the Layout Viewport does get resized, is handy for keeping out Floating Action Buttons above the VK

By resizing the Layout Viewport, the ICB also gets resized, as the ICB size is derived from the Layout Viewport.

Resizing the ICB in its turn has an effect on the calculation of Viewport Units.

Some questions to spark the discussion:

1. Do we/authors have a preferred behavior?
2. If we disallow resizing of the ICB, to achieve stable units, won’t we break many sites that rely on the “old” behavior on Android?
3. Should authors have control over this behavior?
   • If so: Only the ICB? Only the Layout Viewport? Both?
4. …

[bramus]

We covered this at the end of #20. Two-folded problem to tackle:

1. LVP/ICB Resize behavior

   • Various existing behaviors:
     • resize-visual = Resize only the Visual Viewport
     • resize-layout = Resize both the Visual Viewport and Layout Viewport
     • overlays-content (using Virtual Keyboard API) = Do not resize any viewport
   • There is no default behavior, and it really depends on which UA + Platform combo you are on
   • What if authors could opt in to a certain behavior?

2. Positioning of elements

   • Both scenarios have their use cases
     • Sometimes it’s feasible to have static layouts (e.g. App Shells) or to keep elements fixed at the bottom of the (not-resized) Layout Viewport (e.g. Bottom Navigation Bars)
     • Sometimes it’s feasible to keep elements just above the Virtual Keyboard (e.g. Floating Action Buttons) or have layouts that flex to the available space (e.g. Chat Applications)
   • Visual Viewport API won’t cut it here, as that’s:
     • JavaScript based
     • Requires manual calculation of the width + LVP offsets + ICB offsets + scale factor (when pinch-zoomed in)

👉 Input welcome at the CSSWG Issue that covers this: w3c/csswg-drafts#7475 (Definitely check out the demo with the various behaviors, as described in the issue: https://flackr.github.io/web-demos/viewport/)

---

Not marking this issue as Discussed just yet, as I would like to get answers to these two questions before we ask the CSSWG for resolutions:

1. Do we/authors have a preferred behavior?
   • … and do we want to request a default to be specced?
2. Should authors have control over this behavior?
   • E.g. a meta viewport meta-tag extension as proposed in [Virtual Keyboard API] A declarative mechanism to enable overlaycontent? w3c/virtual-keyboard#3 (comment)?

[bramus]

Relevant to this discussion: Blink Intent to Ship: Android OSK resizes visual viewport by default + opt-out

[bramus]

Spec Change PR for the viewport meta tag extension: w3c/csswg-drafts#7826