[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

[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: Accept what is in the draft

The full IRC log of that discussion

<emilio> Or could
<ntim> lea, emilio: This illustrates florian's concerns: https://jsfiddle.net/5mb7efou/
<lea> astearns: fantasai and I thought we were pretty close to consensus, florian had a concern about the *current* behavior, and it seemed like everyone else was in agreement to do this?
<ntim> (open in Safari)
<kbabbitt> chrishtr: there are two modes supported that I think are common in mobile browsers for what to do about the interaction between fixpos elements in the page
<kbabbitt> ...layout viewport and visual viewport
<kbabbitt> ...two values are proposed, resize-visual and overlays-content
<kbabbitt> iank_: and resize-layout
<kbabbitt> chrishtr: it used to be that android chromium browsers only supported resize-layout, and webkit/safari only supported resize-visual
<kbabbitt> iank_: resize-visual or overlay-content, I forget which
<kbabbitt> chrishtr: compat concern from web developers
<kbabbitt> ...research found an app that is more app like and document like benefits from previous chrome/android behavior
<kbabbitt> ...other pages benefit more from the other value
<kbabbitt> ...difference often happens to do with when you open visual keyboard, does the visual viewport move up or not
<kbabbitt> ...sometimes you want it to move up, sometimes not
<kbabbitt> ...conclusion chrome came to is both values have value and we should support both
<kbabbitt> ...in the itnerest of iterop and because documents are more common than applications, default shoul dbe same as safari/webkit
<kbabbitt> ...thjat's what's shipped in Chrome so we have interop
<kbabbitt> ...implemented but not shipped in Firefox
<kbabbitt> ...meta tag to switch between modes to support app like user interfaces
<kbabbitt> ...instagram or twitter prefer the other mode because they have these little bars that want to be above virtual keyboard
<kbabbitt> ...they prefer the way android/chrome used to be
<kbabbitt> ...those browser support both more
<kbabbitt> ...proposal here is to standardize the meta tag
<kbabbitt> q?
<iank_> the three values are `resize-content`, `resize-visual` and `overlays-content`
<kbabbitt> ...meta tag is in editor's draft, is that editor's draft okay?
<dholbert> Firefox's switch to "resize-visual" (on Android) is shipping in version 132 (currently Nightly) as of https://bugzilla.mozilla.org/show_bug.cgi?id=1916002
<kbabbitt> iank_: we've also seen quite a lot of sites change to the resize content behavior
<bkardell_> carousel
<kbabbitt> emilio: there was another way of changing this behavior, right?
<kbabbitt> ...the virtual keyboard api?
<bkardell_> s/carousel/?
<kbabbitt> flackr: yes there's a virtual keyboard api to opt into overlay's content behaviior
<kbabbitt> ...not the most useful but ???
<kbabbitt> ...also not supported across all browsers
<kbabbitt> iank_: we've seen far more people use the interactive widgets meta tag
<kbabbitt> ...to opt into old chromium behavior
<kbabbitt> astearns: other questions?
<kbabbitt> Proposed: Accept what is in meta tag with the three values iank_ put in chat
<kbabbitt> astearns: objections?
<kbabbitt> RESOLVED: Accept what is in the draft