[csswg-drafts] [css-viewport] interactive-widget=resizes-content - will that likely fix issues with fixed headers/footers and on-screen keyboards? (#10464)

SimonEast has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-viewport] interactive-widget=resizes-content - will that likely fix issues with fixed headers/footers and on-screen keyboards? ==
In short: I'd like to clarify whether the current proposed [`interactive-widget=resizes-content`](https://www.w3.org/TR/css-viewport-1/#interactive-widget-section) property is likely to solve issues like the following?

![ezgif-2-6a8f75a47c](https://github.com/w3c/csswg-drafts/assets/813734/c9402114-59c6-4053-987c-573a6d69059e)

In the animation above you'll notice that a typical 3-pane interface (a fixed header and footer, and a scrolling body) works great until the on-screen-keyboard (OSK) is launched and then the layout breaks quite badly:

* The header disappears off-screen
* The entire body becomes much larger than the [visual viewport](https://drafts.csswg.org/cssom-view-1/#visual-viewport) and even the original viewport
* There is now extra white-space underneath the footer
* Scrolling the screen becomes quite difficult as both the document and the center pane now scroll independently and it's possible to get "stuck"

I believe this is due to the _initial viewport_ now being larger than the _visual viewport_. 

I would instead expect to have a simple way to resize the layout, keeping the header and footer in view.

Link to example: https://simoneast.net/PERMANENT/coding-examples/fixed-issues.html
Browser: iPhone Safari 17.4.1

As I worked on this prototype, I tried many different variations (`position: fixed`, JS with `window.visualViewport`, `vh` units, `dvh` units, etc.) and was surprised to find that there is currently no easy, standards-based solution that currently works in Safari 17.4 (if there is, and I have merely overlooked it, please point me in the right direction).

So my main question is this: 
**If Safari correctly followed the `interactive-widget=resizes-content` property, would that alone resolve this kind of issue?** 
Or are there additional missing pieces to this that would need to be included in the standard? My hope is that a 3-pane interface such as this could be done cleanly and efficiently in HTML+CSS, without JavaScript.

Thanks for your time.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10464 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 18 June 2024 07:31:48 UTC