- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Jul 2022 17:16:07 +0000
- To: public-css-archive@w3.org
> 1. This would alter the existing behavior of `position: fixed` on all iOS browsers + Chrome on CrOS. [This demo here](https://cdpn.io/pen/debug/eYMZEaV/addc16387bdd13083e05948afcbb8d63) – which mimics a bottom navigation bar – for example would no longer work as the author expected it to work. This will annoy authors. 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. Note that a developer could build the old behavior with `navigator.virtualKeyboard.overlaysContent = true` when iOS adds support for this. > 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. > 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. > 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? > * `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. > 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. > 3. Authors can also stick something against the Visual Viewport. Agreed, this is an independently useful feature - but not the best for bottom-bars. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7475#issuecomment-1183480887 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 17:16:09 UTC