- From: Bo Cupp <notifications@github.com>
- Date: Wed, 23 Sep 2020 21:40:16 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/498/698107446@github.com>
@rniwa Thanks for the quick reply.
>>In contrast, if navigator.virtualKeyboard.overlaysContent = true, then the visual viewport should not change when the virtual keyboard is shown or hidden.
>>
>I don't see how this will be a meaningful distinction if you're truly talking about the the visual viewport as described in https://wicg.github.io/visual-viewport/. Such a concept is only observable via JavaScript. Why would be useful to not change this value?
It isn't just a value only visible to JavaScript; the difference can be perceived by the user.
Consider this markup...
```html
<!DOCTYPE html>
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
body {
margin: 0;
font-family: sans-serif;
font-size: 40px;
}
.top, .bottom {
position: fixed;
width: 100vw;
padding: 20px;
display: grid;
place-items: center;
}
.top {
top: 0;
background-color: blue;
}
.bottom {
bottom: 0;
background-color: green;
}
input[type=text] {
font-family: sans-serif;
font-size: 40px;
padding: 10px;
}
</style>
<div class="top">TOP FIXED</div>
<div class="bottom">BOTTOM FIXED <input type="text" placeholder="put focus here..."></div>
```
When the virtual keyboard is displayed:
1. the height of the visual viewport is reduced
2. the focused element is scrolled into view (which scrolls a portion of the page that was visible in the layout viewport out of the visual viewport)
3. the user can see the "slop" created by the offset between the visual viewport and the layout viewport by panning around
It looks like the image below:
AFAICT this is the same type of behavior I see on my iPhone: [test page](https://bocupp-microsoft.github.io/VirtualKeyboard/fixed.html).
Now consider this markup which per our proposal would cause the visual viewport to not resize:
```html
<!DOCTYPE html>
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
body {
margin: 0;
font-family: sans-serif;
font-size: 40px;
}
.top, .bottom {
position: fixed;
width: 100vw;
padding: 20px;
display: grid;
place-items: center;
}
.top {
top: 0;
background-color: blue;
}
.bottom {
bottom: env(keyboard-inset-height, 0);
background-color: green;
}
input[type=text] {
font-family: sans-serif;
font-size: 40px;
padding: 10px;
}
</style>
<div class="top">TOP FIXED: virtual keyboard overlays content</div>
<div class="bottom">BOTTOM FIXED <input type="text" placeholder="put focus here..."></div>
<script>
navigator.virtualKeyboard.overlaysContent = true
</script>
```
In this example, because the author set `navigator.virtualKeyboard.overlaysContent = true`:
1. the visual viewport is not resized when the virtual keyboard appears
2. the author updates the layout of the document using proposed CSS (`bottom:env(keyboard-inset-height, 0)` ) to ensure the input element is visible
3. the user can't pan the content; it stays "glued" to the viewport
It looks like the picture below:
As an aside, I can see that running script to opt the document into `overlaysContent` behavior is inconvenient when the rest (for this simple case) can be handled in CSS. I'll file an issue in the MSEdgeExplainers repo to offer a declarative mechanism.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/498#issuecomment-698107446
Received on Thursday, 24 September 2020 04:40:29 UTC