[css-viewport] Add a meta viewport parameter to control ICB layout behavior for interactive overlays

[chrishtr]

On many devices, user agents have interactive overlay widgets to assist users when interacting with web pages. The most common is a virtual keyboard, which allows users on touch devices (mobile, tablet and touch-enabled laptops) to type input that is equivalent to that coming from a keyboard.

These interactive widgets typically overlap the web page's viewport, and hence there is a question of whether the viewport should resize to account for their presence.

Currently, most mobile browsers on Android (Chrome and Firefox in particular) resize the initial containing block (ICB) while the virtual keyboard is open. iOS browsers do not, and instead ovelay the virtual keyboard on top of the scrollable content of the web page without causing a change to layout. Chrome on ChromeOS has the same behavior as iOS. See here for many more details and a complete analysis of how it all works.

There are valid use cases for resizing the ICB (e.g. it provides a convenient way for mobile PWAs to keep informational/actionable bottom-bars or buttons visible on the screen while the virtual keyboard is open), and for not (in many cases, it's undesirable for UX or performance to not affect layout). Developers have also filed CSSWG (example) and browser bug issues (example) requesting both behaviors.

I propose we extend the viewport <meta> tag to opt into different behaviors. An example syntax would be:

<meta name="viewport" content="width=device-width, initial-scale=1.0, virtual-keyboard=resize-layout">

(resize-visual and overlays-content would also be options; the former is iOS and ChromeOS, and the latter aligns with behavior of the virtual keyboard API).

See here for more details.

We might want to pick a more general name than virtual-keyboard to be forward compatible with other interactive overlays that may be added in the future.

I think resize-visual should be the default.

[emilio]

cc @hiikezoe @theres-waldo

[hiikezoe]

Yeah, sounds reasonable. I suppose the spec needs to clarify where to (visually) scroll in each mode. So for example, if a text input at the very bottom of the scrollport (or the visual viewport), then in the resize-visual mode browsers want to scroll the input at the bottom of the resized visual viewport. And if the text input at the very top of the port, browsers want to scroll the input at the top?

I think resize-visual should be the default.

Is there any workarounds for the breakages on sites where it's supposed to be working with the current Chrome/Firefox behaviors (i.e. resize-layout)?

[chrishtr]

I suppose the spec needs to clarify where to (visually) scroll in each mode. So for example, if a text input at the very bottom of the scrollport (or the visual viewport), then in the resize-visual mode browsers want to scroll the input at the bottom of the resized visual viewport. And if the text input at the very top of the port, browsers want to scroll the input at the top?

This seems like something that would happen as part of the focus steps which lead to the keyboard showing, or if the keyboard is shown via the virtual keyboard API then it should be included in the steps there.

[bokand]

Is there any workarounds for the breakages on sites where it's supposed to be working with the current Chrome/Firefox behaviors (i.e. resize-layout)?

The work around if for those sites to add: <meta name="viewport" content="virtual-keyboard=resize-layout"> which will bring them back to the old behavior.

[bokand]

What do we think of renaming interactive-widgets as a replacement for virtual-keyboard? Open to other suggestions too.

[Schepp]

Open to other suggestions too.

What about dynamic-ui? That would be more generic.

I love the approach with the additional meta viewport parameter as it pretty much falls in line with previous usage of it. 👍🏻
And I'd very much love to see it in the browser sooner than later.

One thing I'd like to throw into the discussion is the question if desktop viewport scrollbars should not also be consired dynamic UI and if we could lump them into into this spec, too?

It happens quite often that they break my plans in regards to viewport related styling as documented here: #4691 (comment) (and it turned out that overflow: clip is not enough of a solution, but the non-standard overflow-x: -moz-hidden-unscrollable and overflow-y: overlay were)

Finally, probably overreaching the scope of this topic: can we make available currently active dynamic UI dimensions via env() function? Thinking of env(dynamic-ui-inset-top), env(dynamic-ui-inset-right), env(dynamic-ui-inset-bottom) and env(dynamic-ui-inset-left).

/fixed typos

[bramus]

Open to other suggestions too.

What about dynamic-ui? That would be more generic.

I think this term – along with interactive-widgets – could be confused with the “dynamic toolbars”, a term often used to name the “UA interfaces that are dynamically expanded and retracted” (which excludes the Virtual Keyboard).

What if we avoided this by not naming anything? We could use the key resize-behavior with the values shrink (= previous resize-layout), visual (*), none (= previous overlays-content).

But then again, this behavior is only affected by the virtual keyboard, so why aim for a generic term over virtual-keyboard?

(*) Might need a better word for this …

I love the approach with the additional meta viewport parameter as it pretty much falls in line with previous usage of it. 👍🏻 And I'd very much love to see it in the browser sooner than later.

Happy to hear!

One thing I'd like to throw into the discussion is the question if desktop viewport scrollbars should not also be consired dynamic UI and if we could lump them into into this spec, too?

It happens quite often that they break my plans in regards to viewport related styling as documented here: #4691 (comment) (and it turned out that overflow: clip is not enough of a solution, but the non-standard overflow-x: -moz-hidden-unscrollable and overflow-y: overlay were)

That‘s outside of the scope of this issue, and is being discussed in #6026

Finally, probably overreaching the scope of this topic: can we make available currently active dynamic UI dimensions via env() function? Thinking of env(dynamic-ui-inset-top), env(dynamic-ui-inset-right), env(dynamic-ui-inset-bottom) and env(dynamic-ui-inset-left).

The Virtual Keyboard API offers you some values for this, but only when overlaysContent=true. Or do you mean more generic values, to get the size of the “UA interfaces that are dynamically expanded and retracted”? You could calculate the latter manually by subtracting 100svh from 100lhv for example – but that only works for rectangular UIs/screens. Either way: definitely outside of the scope of this issue; sounds more like an extension to the Visual Viewport – feel free to file a new issue for this.

[theres-waldo]

This was merged in #7826, though I'm unclear on the process steps here (was there a resolution where this was adopted?)

Should this issue be closed?