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

[emilio]

Agenda+ to bring the draft change for review to the WG.

[css-meeting-bot]

The CSS Working Group just discussed [css-viewport] Add a meta viewport parameter to control ICB layout behavior for interactive overlays, and agreed to the following:

• RESOLVED: Leave open, bring back in the upcoming F2F

The full IRC log of that discussion

<fantasai> emilio: Added to draft, but never got WG review
<fantasai> emilio: DIscussed adding meta viewport to control effect of keyboard on layout / visual viewport
<fantasai> emilio: I recall Jen presenting use cases for different things.
<fantasai> emilio: There are use cases for resizing either layout or visual viewport.
<fantasai> emilio: That changes things like fixedpos
<fantasai> emilio: This viewport meta key allows you to configure that behavior, as well as via JS virtual keyboard API.
<astearns> changes we are discussing: https://github.com//pull/7826/files
<fantasai> emilio: The tl;dr is, there are use cases for different behaviors
<fantasai> emilio: existing meta tag seems like the right place to configure this
<TabAtkins> Looks good to me, personally.
<fantasai> emilio: Are people OK with this? Gecko is implementing, Chromium may have shipped awhile ago, unsure about WebKit status
<fantasai> fantasai: This is the first I'm hearing about it. Recall discussing the problems, but don't recall resolving on adding this feature.
<fantasai> iank_: We made a switch to iOS behavior, but had compat issues, and needed to provide a toggle for the various behaviors.
<fantasai> emilio: Gecko and Blink used to resize the layout viewport for the keyboard
<fantasai> emilio: and iOS didn't
<fantasai> emilio: but sometimes could e.g. in webview
<fantasai> emilio: for Gecko to align with WebKit and Blink, we are also looking at implementing this
<fantasai> emilio: because use cases for other behavior
<fantasai> emilio: so this seems like reasonable place to opt into this
<fantasai> iank_: It's served us pretty well when we did this change.
<emilio> fantasai: I can't represent WebKit's position on this
<emilio> ... from my perspective it's not amazing that somebody edited it without bringing it up and now everybody is shipping it
<emilio> iank_: we did bring it up for discussion
<emilio> fantasai: interactive-widget doesn't show up in the mailing list
<emilio> fantasai: Just saying, let's avoid that kind of situation in the future
<emilio> astearns: it sounds like there was discussion in the PR
<emilio> ... which isn't great
<emilio> ... three different things we could do I guess
<emilio> ... leave issue open, bring it back in the f2f
<emilio> ... (2) accept PR, belatedly, open new issues if needed
<TabAtkins> +1 to 1
<emilio> ... (3) ack that we didn't follow process, rip it from the draft and opt in again
<emilio> chrishtr: +1 to 1
<chrishtr> https://github.com/WebKit/standards-positions/issues/65
<emilio> RESOLVED: Leave open, bring back in the upcoming F2F