- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Jul 2022 22:47:31 +0000
- To: public-css-archive@w3.org
flackr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-position-3] Reinterpret viewport positioned (fixed, sticky) elements wrt virtual keyboard == Position [fixed](https://www.w3.org/TR/css-position-3/#valdef-position-fixed) is positioned and sized relative to a [fixed position containing block](https://www.w3.org/TR/css-position-3/#fixed-positioning-containing-block) which in the absence of no established container is the [viewport](https://www.w3.org/TR/CSS2/visuren.html#x1). The behavior today when a virtual keyboard is shown varies (see [demo](https://flackr.github.io/web-demos/viewport/) for interactive examples). In each screenshot, the left image is what the user would see, and the right is a visualization of the viewports with the blue outline being the size of the ICB / layout viewport / 100vh and the red outline being the visual viewport: 1. [iOS (and ChromeOS)](https://flackr.github.io/web-demos/viewport/#behavior=ios) shrink the visual viewport but keep the fixed position viewport the same size. As a result, elements which are fixed position to the top/bottom may be scrolled out of view (even while zoomed out). However, showing the keyboard does not affect layout in any way.  2. [Android](https://flackr.github.io/web-demos/viewport/#behavior=android) resizes the page to the height remaining after the keyboard is shown, changing the fixed position viewport as well as the ICB. This has the consequence of doing a relayout and potentially triggering different media query breakpoints, but also means that position: fixed elements are still fully visible while zoomed out.  We would like to unify the behaviors, and agree that not having a global resize is better, however one of the stumbling blocks when we tried to adopt the iOS model is that developers struggle with being able to create bottom fixed position elements, which has lead to various alternate proposals on top of the iOS model. Let's explore some: 3. [device-fixed](https://flackr.github.io/web-demos/viewport/#behavior=device-fixed) is a [proposed position]((https://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html#:~:text=the%20user%20interaction.-,position%3A%20device%2Dfixed,-Which%20of%20these)) to position elements to the fixed viewport regardless of zoom. This fixes the issue when the keyboard is shown as the element is shifted up, however when zooming `position: device-fixed` content remains the same size which raises concerns for accessibility as well as not preserving the relative size of content on the page.  4. [Scaled device-fixed](https://flackr.github.io/web-demos/viewport/#behavior=device-fixed-scaled) is an alternative which preserves the zoom scale but still treats the visual viewport rect as the fixed position rect. This allows you to zoom in on `position: device-fixed` content but this results in the content intruding more into the viewport.  5. I propose [excluding the keyboard from the position fixed viewport](https://flackr.github.io/web-demos/viewport/#behavior=fixed-viewport). This leads to a very similar behavior to the android one in that `position: fixed` content avoids the keyboard, except that it would not change the height of the ICB or viewport units. The only content which needs to relayout is that which is sized with respect to the fixed position viewport, and content which is not sized with respect to the viewport can be shifted on the compositor.  When you zoom in the same thing would happen as currently happens on android, the visual viewport would zoom in but leave the fixed position viewport size unchanged.  Another advantage of this option is that we could easily use the same adjusted fixed viewport as the scrollport for sticky position elements on the root, whereas options 3 and 4 would not implicitly add any support for sticky without adding e.g. device-sticky. TLDR; In order to close the interop gap while still allowing developers to position fixed position content above the keyboard I propose we adopt option 5. Each option links to a demo of that option which can be played with on a desktop browser. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7475 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 July 2022 22:47:33 UTC