[Virtual Keyboard API] A declarative mechanism to enable overlaycontent?

[travisleithead]

Porting over from MSEdgeExplainers repo MicrosoftEdge/MSEdgeExplainers#416

@snianu filed:

Since we already have CSS env variables for keyboard insets, should we also have a declarative mechanism to enable overlaycontent? Something like a meta tag?

[bramus]

As suggested in #13 (duplicate):

An extension to meta name="viewport" (or perhaps a new CSS at-rule or property on ) to control the behavior seems like something handier.

Something like this:

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

Or this:

:root {
  virtual-keyboard: overlays-content;
}

(names to be bikeshed but you get the point)

[andruud]

Meta viewport would work, but the CSS approach could create contradictions or loops, e.g. say you do this while the keyboard is open in a non-overlay-by-default browser.

@media (height < 900px) { /* True, because the open keyboard makes the viewport/ICB small */
  :root {
    virtual-keyboard: overlays-content; /* Applying this resizes the viewport/ICB, making the MQ 'false' */
  }
}

[snianu]

@BoCupp-Microsoft FYI..

[andruud]

virtual-keyboard=overlays-content

BTW, what would we call the opposite value? (Considering that overlays-content may be the default).

[flackr]

virtual-keyboard=overlays-content

BTW, what would we call the opposite value? (Considering that overlays-content may be the default).

So I was just testing this and it seems that this overlaysContent API is very different from the way that the virtual keyboard overlays content on chromeos or iOS.

The demo is https://output.jsbin.com/cosopok/
On ChromeOS and iOS, the layout viewport does not change when the keyboard shows, and you can scroll to the bottom of the page with the keyboard open (seeing both the input element at the bottom and the bottom of the measuring bar on the left).

However, when overlaysContent is enabled, you can never scroll to the bottom of the page, meaning you can't see what you're typing into the bottom input.

So unless we change the overlaysContent behavior, this is a different orthogonal feature and will likely never be the default.

[snianu]

@flackr overlaysContent when set to true, prevents resizing of both layout and visual viewports when the virtual keyboard shows up. Resizing the visual viewport (without resizing the layout viewport) gives the user the ability to pan around the layout viewport within the smaller visual viewport. If we aren't resizing the visual viewport (so no resize event) or the layout viewport, then you do need some event and/or CSS env variable to allow the author to relayout the page. That's why the VK API has geometrychange and env(keyboard-inset-*) so the web authors can adjust just the input control where the user wants to type that gets hidden behind the keyboard without affecting the layout of the entire page. On iOS, the visual viewport is resized, but not the layout viewport. This comment has an example and discussions between us and Apple devs which might be relevant to your question.

[bokand]

However, when overlaysContent is enabled, you can never scroll to the bottom of the page, meaning you can't see what you're typing into the bottom input.

From the explainer, I think this is intended - it's meant for cases where the app will reposition elements itself and IIRC was to prevent resizing the visual viewport on dual-screen devices where the keyboard only occupies half the (dual-screen) viewport.

It'd be nice if we could choose behavior, i.e.

virutal-keyboard: resize-layout        // Changes ICB size, causes reflow

virtual-keyboard: resize-visual        // Changes visual viewport size, no reflow but obscured
                                       // content can be scrolled into view

virtual-keyboard: overlays-content     // Doesn't resize anything, content must adjust itself

[bramus]

To add/clarify:

• virtual-keyboard: resize-layout = Current Android behavior
• virtual-keyboard: resize-visual = iOS/CrOS behavior

[flackr]

I think it may be simpler if we change android to match iOS / CrOS, and then if developers want resize-layout behavior they can effectively get it with overlays-content + a simple style which excludes the keyboard area such as the grid example in the spec.

[bokand]

Ah, yup, an app can fairly easily simulate resize-layout so I agree changing default to match iOS/CrOS and overlays-content covers all the cases

[css-meeting-bot]

The Web Editing Working Group just discussed declarative mechanism to enable overlay content?.

The full IRC log of that discussion

topic: declarative mechanism to enable overlay content?
github: https://github.com//issues/3
snianu: mutliple issues here
.. overlayContent was set on VK (in JS) via the navigator object...
.. from TAG review, they requested an env variable for inset (for geometrychanged event), then these CSS variables can be used to understand occluded content.
.. there was some addition concern--if we have CSS env variables, then why set overlayscontent in JS?
.. perhaps there should just be some HTML declarative thing?
.. (that's the recap)
.. was a suggestion to never resize the visual viewport (on overlays content set)
.. (today on Windows we change both layout & visual viewport)
.. then the overlays content would only control the layout viewport
.. (looking up some examples to share to help explain the details)
https://github.com/w3ctag/design-reviews/issues/498
snianu: I think we can discuss this async...
johanneswilm: Are you seeking input on seeing if making the suggested (or some other proposal)?
.. or are you asking for agreement on the suggested syntax?
.. not sure if Safari is planning to implemented overlayscontent, and if so, what the behavior should be?
.. should it adjust layout + visual viewport.
.. currently only chromium supports.
travis: whenson, do you have any feedback on the declarative mechanism?
whsieh_: The behavior would apply to any element that is a focusable target for the keyboard to appear?
.. should the behavior "descend" into other elements? e.g., with iframe?
snianu: currently we're excluding iframes.
whsieh_: My intuition (for like messanger) might be useful in the main chat box... but in search field is may not be as appropriate (or in some other view).
snianu: ex: on dual-screen examples, you can split screen into two. On one screen you have a search element. Current behavior: keyboard covers both screens.
.. with overlayscontent flag it doesn't affect the layout of the whole page, just the element in question.
.. that was the original scenario that inspired the flag.
.. ex: in messager, w/ VK, you might want to adjust just the textbox and not the entire layout.
whsieh_: for a meta tag, does the web engine need to respect dynamic changes?
.. for declarative mechanism they may need an attribute on an element.
.. whsieh_ the flag on the navigator... object already offers this flexibility.
.. stepping back, I'm curious what the declarative mechanism (on the meta tag) would offer?
.. if we did add a declarative, I would be more in support of an attribute (i.e., like inputmode or similar)
Travis: I don't like meta tag for cases where the state will dynanically change (meta is usually for set-and-forget states), which this doesn't seem like it's really static...?