- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 18:25:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `viewport positioning vs virtual keyboard`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: viewport positioning vs virtual keyboard<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7475<br> <fantasai> flackr: [presents the issue]<br> <fantasai> flackr: Developers want a way to position content that stays in view above a virtual keyboard as it slides into place<br> <fantasai> flackr: on iOS and ChromeOS this doesn't work today because the virtual keyboard that slides into place changes the visual viewport but not the layout viewport<br> <fantasai> flackr: You can seen an example here<br> <fantasai> flackr: the header/footer are clipped and slightly out of view<br> <fantasai> flackr: behavior on Android today is that we reisze the page<br> <fantasai> flackr: but this is something that we would like to not do<br> <fantasai> flackr: just that there has been strong demand for this use case<br> <fantasai> flackr: there has been a prior suggestion to have a position called device-fixed<br> <fantasai> flackr: my understanding of how it works is that device-fixed content is outside of pinch-zoom<br> <fantasai> flackr: and effectively part of the visual viewport<br> <fantasai> flackr: what we dislike about this is that it's not accessible<br> <fantasai> flackr: because you can't pinch-zoom this content<br> <fantasai> flackr: one alternative is scaling the content with pinch-zoom<br> <fantasai> flackr: but then such content starts massively intruding on the visual viewport<br> <fantasai> flackr: so what we'd like to propose doing<br> <iank_> its also quite common for the whole page/app to be within a position:fixed element.<br> <fantasai> flackr: is defining a viewport that just excludes the virtual keyboard<br> <fantasai> flackr: but is different from the layout viewport<br> <fantasai> flackr: so we don't have to do a global reflow when the virtual keyboard shows<br> <fantasai> flackr: this keeps your headers and footers in position<br> <fantasai> flackr: you can still zoom around<br> <fantasai> flackr: this is pretty similar to the effect on android right now with the exception of not changing the actual content layout size<br> <fantasai> flackr: so we think that it should be Web-compatible for the way that sites exist<br> <bramus> q+<br> <fantasai> flackr: unsure about iOS<br> <fantasai> flackr: I think bramus prefers to move towards iOS behavior<br> <Rossen_> q+\<br> <Rossen_> ack \<br> <Rossen_> q+<br> <fantasai> bramus: In general, of all these proposals, 5th is what Robert is suggesting<br> <fantasai> bramus: and I'm in favor<br> <fantasai> bramus: but I'm not in favor of changing how current position: fixed works<br> <fantasai> bramus: to counter that, I was thinking of extension to position:fixed<br> <Rossen_> ack bramus<br> <fantasai> bramus: where you can specify which viewport you are targetting<br> <fantasai> bramus: so default is fixed against the layout viewport<br> <fantasai> bramus: but you would also have options to lay out against the visual viewport<br> <fantasai> bramus: so that when keyboard is shown ....<br> <fantasai> bramus: third option is position fixed fixed, positioned against the unzoomed visual viewport<br> <fantasai> bramus: which is what robert described as option 5<br> <fantasai> flackr: that's developer optining into either 5 or 4<br> <fantasai> bramus: the main reason I'm thining along that line is that we wouldn't suddenly change something depending on which platform you're on<br> <fantasai> bramus: but main advantage to extension to position: fixed syntax is that you can feature-detect<br> <fantasai> iank_: What's the behavior on Android today?<br> <fantasai> bramus: what we do right now on Anrdoid is that the layout viewport gets resized when you show a virtual keyboard<br> <fantasai> bramus: demo on screen<br> <fantasai> iank_: there's a difference also between position:absolute into ICB vs position:fixed<br> <fantasai> iank_: what's the difference there again?<br> <fantasai> flackr: position:fixed lays out against the ??? viewport<br> <TabAtkins> fantasai: one problem i've often encountered is the heades and footers respond to the position of th ekeyboard, and i'm trying to type into something and i can't see it anymore, bc there's not enough space left<br> <TabAtkins> fantasai: I'd like for us to not have this problem happen by default<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I think visual viewport isn't what we're targeting; again pinch-zoom must not be responded to<br> <flackr> +1<br> <TabAtkins> fantasai: what we want is remaiing space after we remove virtual keyboard<br> <TabAtkins> bramus: rob has been using 'unzoomed virtual viewport'<br> <TabAtkins> flackr: suggested calling it fixed viewport<br> <TabAtkins> fantasai: hard not having webkit here, but i recall explaining this as two ways to handle virtual keyboard<br> <bramus> s/virtual/visual/<br> <flackr> qq+<br> <TabAtkins> fantasai: one the keyboard takes up space, another it floats over the content<br> <TabAtkins> fantasai: i think they follow the floating model<br> <TabAtkins> fantasai: so the way keyboard interacts is probably affected by that choice<br> <TabAtkins> fantasai: i think having a special 'fixed viewport' for when you want to attach something to the keyboard or remaining space is reasonable, but i dont' think it shoudl be default<br> <Rossen_> ack flackr<br> <Zakim> flackr, you wanted to react to fantasai<br> <fantasai> flackr: The first behavior I demoed, keyboard floating overtop content, is iOS keyboard<br> <TabAtkins> flackr: the behavior i demo'd is the behavior iOS has, where effectively the keyboard is floating. it does shrink visual viewport but otherwise doens't affect anything<br> <fantasai> flackr: option 5 is the same, except you have a viewport that is remaining space<br> <iank_> q+<br> <Rossen_> ack Rossen<br> <fantasai> bramus: and not affected by pinch zoom<br> <fantasai> Rossen_: Generally speaking, 2 main use cases are iterated have to do with in-page UI that wants to behave more or less close to the way external host UI appears or disappears or behaves<br> <fantasai> Rossen_: whether this is a keyboard or navbar or search bar<br> <fantasai> Rossen_: these various permutations are places we want to target<br> <fantasai> Rossen_: and to push the use cases a little further<br> <fantasai> Rossen_: as the UI animates in and out, you want to make sure that your stuff animates smoothly with it<br> <fantasai> Rossen_: this is where device-fixed ideas came in the past<br> <fantasai> Rossen_: we had a prefixed implementation of this back in the Edge platform where we used position:fixed for UI in PWAs and web apps<br> <fantasai> Rossen_: in windows<br> <fantasai> Rossen_: That worked pretty well, but it had the flaw pointed out that they don't zoom in and out with the page<br> <fantasai> Rossen_: which is exactly what you want, because you're trying to behave closer to the way this native UI behaves<br> <fantasai> Rossen_: pushing things slightly further, we proposed at some point as part of a larger proposal<br> <fantasai> Rossen_: a different way of dealing with this which was to expose an environment variable for where the folds are, the top or the bottom folds of the device<br> <bramus> s/and not affected by pinch zoom/and its sizing not affected by pinch zoom/<br> <fantasai> Rossen_: I recall a discussion in IIRC Coruña that was extending this further<br> <fantasai> Rossen_: maybe it was presented by jensimmons at the tme<br> <Rossen_> https://github.com/w3c/csswg-drafts/issues/4736<br> <fantasai> Rossen_: that proposal to me was the one that was solving a lot of what was being described here<br> <fantasai> Rossen_: my question is, there has bene a lot of work and thinking happening here over past 3-4 years<br> <fantasai> Rossen_: and yet, i'm surprised we're going back to trying to reinvent this<br> <fantasai> Rossen_: rather than collecting all of the thinking and getting a path forward<br> <fantasai> Rossen_: Rob or Bramus, was this approach considered or considered and not deemed appropriate or...? what happened?<br> <Rossen_> q?<br> <fantasai> flackr: In WICG there's an overlays flag<br> <fantasai> flackr: you get an environment variable for the size of the keyboard<br> <fantasai> flackr: the developer is picking up the complexity of where the keyboard should be<br> <fantasai> flackr: up to them to do the right thing in response to keyboard showing<br> <fantasai> Rossen_: that seems another permutation of what we're discussing<br> <fantasai> flackr: that is something shipping in Chrome but not any other browser<br> <fantasai> flackr: but has complexities because, e.g. you can't scroll to the bottom of the page<br> <fantasai> flackr: because the keyboard is not considered in your page layout at all<br> <fantasai> flackr: unless you look to see, how much of the page is my keyboard obscuring<br> <fantasai> bramus: it also doesn't resize the visual viewport<br> <fantasai> flackr: that's a bug<br> <fantasai> Rossen_: I think we should also consider the other discussion of some of the environment variable sand how they play<br> <fantasai> Rossen_: desire to account for scrollbar etc.<br> <fantasai> flackr: I have considered some of this, and the initial thinking was that it is complex to do the right thing<br> <fantasai> flackr: to take all of this into account as a developer<br> <fantasai> flackr: we wanted to have an easy thing for devs to use, to handle most of the use cases<br> <fantasai> Rossen_: every time we want to expose a new unit, that's a last step<br> <fantasai> fantasai: we already rejected that<br> <fantasai> fantasai: that's not the discussion here<br> <fantasai> flackr: what's being proposed here is either new positioning scheme or re-intepreting 'position: sticky'<br> <fantasai> fantasai: sticky?<br> <fantasai> flackr: we would need to also address sticky, ensure those are still in view<br> <fantasai> fantasai: I understand wanting that to work... but also... I see so many pages that assume there'll be enough space left and there isn't space to see what I'm typing into<br> <fantasai> Rossen_: This is why my preference is for this environmental awareness is better expressed in environment variables which you can add to your calc() expressions<br> <fantasai> Rossen_: and then can improve UI clutter depending on how much space you have left<br> <fantasai> Rossen_: with positoin, you have to work backwards to see how large it lays out, and then if you don't like it go back and remove it<br> <fantasai> Rossen_: much heavier option<br> <flackr> Something like position: fixed; bottom: env(keyboard-height); ?<br> <fantasai> Rossen_: would much rather do a conditional on a calc() expression and do everything pre-layout<br> <fantasai> Rossen_: would prefer to do that pre-layout to decide if element continues to be there or not<br> <fantasai> Rossen_: for example, but can do more than that?<br> <fantasai> fantasai: Curious what Rossen means by "do more"<br> <fantasai> fantasai: but also, wrt that example, we would want insets from each edge of the screen, similar to the safe-area insets<br> <fantasai> Rossen_: what you just described. Need all 4 sides<br> <emilio> q+<br> <fantasai> flackr: One complication with that<br> <fantasai> flackr: right now adding keyboard inset to the bottom work, but I pan down it's at layout viewport plus keyboard height<br> <fantasai> bramus: if something is position: fixed; bottom: keyboard-height, it would obscure ???<br> <fantasai> bramus: because you aren't taking the offset of the visual viewport measured against the layout viewport into account<br> <fantasai> Rossen_: ...<br> <fantasai> iank_: One quick thing, rob, I'm assuming that any proposal<br> <fantasai> iank_: we're going to be compat-constrained on Android pretty heavily<br> <Rossen_> s/.../not if we are exposing the insets env values/<br> <fantasai> iank_: because ppl are relying heavily on our current behavior<br> <fantasai> flackr: we have a lot of interop differences, e.g. iOS vs Android<br> <fantasai> iank_: yes, but ppl know this and have written code to make it work on each platform<br> <fantasai> flackr: I suspect that's true<br> <bramus> q?<br> <fantasai> iank_: I just wanted to make one thing clear, we're in a very sucky position here<br> <fantasai> iank_: but I don't think that Android or Android webview would be able to change behavior here<br> <fantasai> iank_: same with iOS<br> <Rossen_> ack iank_<br> <Rossen_> ack emilio<br> <fantasai> (basically, we are doomed to non-interop?)<br> <fantasai> emilio: At a glance, from my phone, ?? behae like Chrome and Firefox<br> <fantasai> emilio: resizes and fixes stuff<br> <fantasai> emilio: the problem with iOS behavior is can you even see something at the bottom of the page?<br> <fantasai> flackr: when you pan, you're moving the visual viewport and can scroll to the bottom of the page<br> <fantasai> iank_: I think it's still true that there are various tricks ppl do to get it to autoscroll down into that position<br> <fantasai> flackr: When you focus an input, it scrolls into view, and that moves the visual viewport<br> <fantasai> iank_: but ppl exploit various tricks on iOS to get the visual viewport to scroll to the end of the layout viewport<br> <fantasai> bramus: tricks I've seen ppl use is to steer away from the behavior where the browser automatically tires to center the input into the visual viewport<br> <Rossen_> q?<br> <Rossen_> another relevant topic to review is https://github.com/w3c/csswg-drafts/issues/1693<br> <fantasai> flackr: the reason you can get to the bottom is the browser knows the size of the keyboard and shrinks the visual viewport by that amoutn so you can scroll that much extra<br> <fantasai> emilio: do stuff like ??? on iOS, on the keyboard, presumably their inputs fix to the top fo the keyboard right?<br> <fantasai> emilio: like Anrdoid is doing right now<br> <fantasai> emilio: On one hand I get that it's nice to not resize the layout viewport<br> <fantasai> emilio: but something like either your proposal, which is fine, or current android/chrome proposa, seems more towards what authors want<br> <bramus> q+<br> <fantasai> emilio: when is the iOS behavior preferable right now?<br> <flackr> +1<br> <fantasai> emilio: when you have iOS app, if it behaves like Android<br> <fantasai> Rossen_: you have to do all kinds of funky UA detection stuff<br> <fantasai> flackr: native apps behave like ???<br> <fantasai> emilio: they behave like Chrome/Firefox<br> <fantasai> flackr: option 5 was designed to be more like native app behavior<br> <fantasai> bramus: what I like about proposal is that it allows authors to have both behaviors<br> <fantasai> bramus: so if author wants bottom bar not affected by showing keyboard, can get that<br> <Rossen_> ack bramus<br> <fantasai> bramus: should they want android behavior, authors can also retain the existing behavior by doing feature detection<br> <iank_> does the proposal allow Android & iOS to keep the current default behaviour?<br> <fantasai> bramus: but would require landing both changes on Android at the same time<br> <flackr> qq+<br> <fantasai> bramus: so authors can choose to have something at the bottom bottom, or above the on-screen keyboard<br> <fantasai> iank_: does someone have an existing PWA, we're not changing default behavior?<br> <fantasai> bramus: Twitter app<br> <fantasai> flackr: what are you proposing the default is?<br> <fantasai> bramus: default would be to have position:fixed as before, lay out items against the outer viewport<br> <fantasai> bramus: that would be the iOS behavior<br> <fantasai> iank_: we can't do that<br> <Rossen_> q?<br> <Rossen_> ack flackr<br> <Zakim> flackr, you wanted to react to bramus<br> <fantasai> flackr: bramus brought about customizing behavior<br> <fantasai> flackr: the virtual keyboard overlays content behavior allows complete customization of the bheavior<br> <fantasai> flackr: if you're a site that wants to customize ythe behavior, you can do that<br> <fantasai> flackr: this is more about having sensible defaults that work well<br> <fantasai> Rossen_: So, let's figure out some next steps<br> <fantasai> Rossen_: most of the conversation seems to be circling around the option 5 that you proposed<br> <fantasai> Rossen_: we cna record that this is the current preferred method<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: bramus was suggesting there be various syntactic ways of opting into different behaviors<br> <TabAtkins> fantasai: i think this is something that, if we want to add it, it shoudl be an independently cascade property from position<br> <TabAtkins> fantasai: likely you'll think abuot how your stuff adapts at a different level from how it's laid out<br> <TabAtkins> fantasai: so it should be a different prop<br> <TabAtkins> fantasai: position:fixed, and a "fixed-to:whatever" prop<br> <fantasai> s/different/independently cascading/<br> <fantasai> Rossen_: do we need to take any resolution on these proposals?<br> <fantasai> flackr: We would like to get more feedback<br> <fantasai> Rossen_: seems we've clearly indicated favorable options, should be easier to page in next time<br> <fantasai> I also wonder if we want to do this *and* have the environment variables<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7475#issuecomment-1204324591 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 18:25:25 UTC