In short: I'd like to clarify whether the current proposed interactive-widget=resizes-content property is likely to solve issues like the following?
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 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
This prototype uses flexbox with html, body { height: 100% }, but I also 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 (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.
See also: Viewport vs Virtual Keyboard Resize Behavior, an early guide to this issue which fed into the CSSWG draft.
In short: I'd like to clarify whether the current proposed
interactive-widget=resizes-contentproperty is likely to solve issues like the following?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:
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
This prototype uses flexbox with
html, body { height: 100% }, but I also tried many different variations (position: fixed, JS withwindow.visualViewport,vhunits,dvhunits, etc.) and was surprised to find that there is currently no easy, standards-based solution that currently works in Safari 17 (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-contentproperty, 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.
See also: Viewport vs Virtual Keyboard Resize Behavior, an early guide to this issue which fed into the CSSWG draft.