- From: Bramus! via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Jul 2022 21:34:25 +0000
- To: public-css-archive@w3.org
> You proposed no longer resizing the ICB on Android (without this reinterpretation), which would have the opposite effect of annoying authors who are currently expecting the bottom bar to stay visible wouldn't it? We will be annoying some group of users when we align the keyboard behavior, right? Do you think that users who wanted the bottom / top bar sometimes obscured by the keyboard will be greater in number / more annoyed than the users who didn't? My expectation was that more devs would have expected fixed pos elements to stay visible (the Android behavior) and that changing the default fixed behavior to no longer do that would be more annoying.
By changing the ICB behavior on Android we will already annoy authors as `100vh` will behave differently in case the OSK gets shown when compared to the current behavior. Sites that rely on Viewport Units – wether they use `position: fixed` or not – will be affected by this. Thanks to this ICB change, though, we can achieve interop between browsers and platforms. This is good for authors, as they can from then on reliably know that their code will behave similarly on all browsers and platforms _(both `100vh` and `position: fixed`)_
By then adjusting how `position: fixed` is interpreted – which is proposed in Option 5 _([PosFixedViewport](https://flackr.github.io/web-demos/viewport/#behavior=fixed-viewport))_ – we would break the just-achieved interop. This seems like a step back, especially since authors can’t easily know wether the browser that’s being used, uses the old or the PosFixed behavior. We would also require all other vendors to implement this change, which might not happen.
Therefore I suggested another route to get to the same result. One where the existing behavior `position: fixed` remains in place _(which is: lay items out against the LVP)_, but where we extend `position: fixed` with a few new options.
> Note that a developer could build the old behavior with `navigator.virtualKeyboard.overlaysContent = true` when iOS adds support for this.
This assumes that browsers adopt both the adjusted `position: fixed` behavior and ship the VirtualKeyboard API, and preferably land these at the same time for author convenience.
If the VirtualKeyboard API does not land, then the adjusted `position: fixed` would make positioning something against the Layout Viewport bottom impossible _(without any hackery)_
```css
/* Assumes adjusted behavior from Option 5 */
.fab {
position: fixed;
bottom: 0; /* Above the OSK */
}
.bottombar {
position: fixed;
bottom: ???; /* How can this be positioned against the Layout Viewport? */
}
```
Looking at https://github.com/WebKit/standards-positions/issues/16 and https://github.com/mozilla/standards-positions/issues/531, there seems to be little excitement for the VirtualKeyboard API.
> > 2. Authors cannot easily feature detect wether the new or old behavior is being used. Therefore they cannot predict how the site will look with the OSK shown. This will annoy authors as well.
>
> If we launch this change in coordination with no longer resizing the ICB, there will generally be no visual change for developers. Whereas if we don't, there will be. This does risk annoying developers on iOS / ChromeOS but they would also currently be annoyed by the Android behavior. The `navigator.virtualKeyboard.overlaysContent` allows developers to design their own consistent behavior though it is admittedly not yet supported on iOS.
The “no visual change” you mention would only affect Android. There would still be a difference between Android and non-Android, where we would be dependent on other vendors to achieve interop.
My main concern here was to give authors an easy way to detect wether the current browser has the old or new system implemented. With easy feature detection I mean something like an `@supports()` rule. No JS.
By introducing the Fixed Viewport this is not possible. By introducing extensions to `position: fixed` it is as easy as this:
```css
@supports(position: fixed / fixed) {
/* Yay, new position mechanism available! */
}
```
As the alternative proposal aligns all browsers initially, and authors can detect the new behavior, they know for sure where which elements will appear.
```css
.fab {
position: fixed;
bottom: var(--bottom-bar-height); /* Above the bottombar */
}
.bottombar {
height: var(--bottom-bar-height);
position: fixed;
bottom: 0; /* At bottom of LVP */
}
@supports(position: fixed / fixed) {
.fab {
position: fixed / fixed; /* Lay me out against the Fixed Viewport instead of the Layout Viewport */
}
}
```
In this snippet, the FAB will be obscured by the OSK on platforms that do not support the new mechanism _(cfr. what iOS already does)_. Authors also know it will be above the OSK in case the browser supports the new behavior. It’s about predictability, instead of being reliant on the progress browser vendors make implementing it.
> > 3. This does not provide a solution for authors to stick something against the Visual Viewport, something that might come in handy for Floating Action Buttons or Toolbars which do need to stay above the zoomed content.
>
> Presumably this is the device-fixed (option 3) in the above list, right? I.e. not changing with zoom. I do think that this is valuable. My main concern is that device-fixed is not the right behavior for bottom-bars, so even if we add it, it does not solve the bottom-bar issue. I do think `device-fixed` may be independently valuable even though it does have accessibility concerns.
I’m thinking of Option 4 _([scaled device-fixed](https://flackr.github.io/web-demos/viewport/#behavior=device-fixed-scaled))_ here. A side-effect of this option is that these elements might obscure content of the page as the user pinch-zooms in. To limit their “zoomability”, the Visual Viewport Units can be used: by applying something like `max-height: 20vvh; width: 100vvw;` the element will take up the whole width and at most 20% of the visual viewport height as you pinch-zoom.
I initially considered Option 3 _([device-fixed](https://flackr.github.io/web-demos/viewport/#behavior=device-fixed)), but found it a bad idea as it’s hard to grasp the sizing.
- Say you have a regularly positioned element that has a width of `100vw` and you then pinch-zoom in. That element will have grown visually. A `position: device-fixed` element with the same width set however won’t have grown. Seeing two elements with the same declared width but a different rendered width is pretty confusing.
- Applying a width of `100vvw` a `position: device-fixed` element would also be pretty confusing: when pinch-zooming in the Visual Viewport shrinks, so those elements would also shrink as you perform the pinch-zoom.
> > Could we solve this differently? Instead of overloading the position property with new values – such as `device-fixed`, `visual-viewport-fixed`, … – could we extend its syntax and provide the viewport as an extra argument? I’m thinking of:
> >
> > * `position: fixed / layout` = current behavior, would be the same as `position: fixed`)
> > * `position: fixed / visual` = fixed against the visual viewport, also when zoomed in
>
> To be clear, is this option 3 or option 4?
Option 4 _([scaled device-fixed](https://flackr.github.io/web-demos/viewport/#behavior=device-fixed-scaled))_
> > * `position: fixed / fixed` _(* lacking a better name)_ = the proposed behavior from Option 5 _([PosFixedViewport](https://flackr.github.io/web-demos/viewport/#behavior=fixed-viewport))_
>
> > 1. The behavior of `position: fixed` would not be changed, making the adjustments backwards compatible
>
> We will be changing the position: fixed behavior with the no longer resizing the ICB change, which is not backwards compatible on Android without an update to their behavior.
As mentioned earlier main perspective on this is an interop one, so that we can make things consistent and predicable for authors.
> > 2. Authors can feature detect the new behavior and act upon that
>
> You could feature detect this when the keyboard is shown by comparing the height of 100% fixed to the viewport. Alternately the virtualKeyboard API lets developers opt into alternate treatments.
This feels complicated and hacky. A pure CSS solution – using `@supports()` – is a much nicer solution.
> > 3. Authors can also stick something against the Visual Viewport.
>
> Agreed, this is an independently useful feature - but not the best for bottom-bars.
The use-case I had in mind are interfaces that sport floating toolbars that need to stay in place as the user zooms in on the content. Sizing and positioning those toolbars using the Visual Viewport Units would make them unzoomable _(or give them a limited zoom)_
--
GitHub Notification of comment by bramus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7475#issuecomment-1183700871 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 July 2022 21:34:28 UTC