Open travisleithead opened 3 years ago
As suggested in #13 (duplicate):
An extension to meta name="viewport"
(or perhaps a new CSS at-rule or property on <html>
) 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)
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' */
}
}
@BoCupp-Microsoft FYI..
virtual-keyboard=overlays-content
BTW, what would we call the opposite value? (Considering that overlays-content may be the default).
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.
@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.
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
To add/clarify:
virtual-keyboard: resize-layout
= Current Android behaviorvirtual-keyboard: resize-visual
= iOS/CrOS behaviorI 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.
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
The Web Editing Working Group just discussed declarative mechanism to enable overlay content?
.
Porting over from MSEdgeExplainers repo https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/416
@snianu filed: