- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Mar 2022 16:56:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overscroll] Whether to move position:fixed elements during overscrolling`, and agreed to the following: * `RESOLVED: fixed-position elements whose scroller is not their containing block do not participate in overscroll` * `RESOLVED: the former statement also applies to sticky element when stuck` <details><summary>The full IRC log of that discussion</summary> <emeyer> Topic: [css-overscroll] Whether to move position:fixed elements during overscrolling<br> <emeyer> github: https://github.com/w3c/csswg-drafts/issues/6299<br> <emeyer> ben m: A lot of browsers had fixed element not participating in overscroll, but two browsers have the participate and WebKit still has a bug open.<br> <TabAtkins> q+<br> <smfr> q+<br> <flackr> q+<br> <emeyer> …There are use cases to do both. Can we formalize this and get it in the spec?<br> <emeyer> astearns: Do we have any spec text asserting one way or the other?<br> <emeyer> ben: I didn’t find any.<br> <astearns> ack TabAtkins<br> <emeyer> TabAtkins: I don’t have a strong opinion here, both options seem potentially reasonable. Does anyone have overscroll on non-root situations?<br> <emeyer> Ben: Edge and Chrome don’t have overscroll on subscrollers.<br> <smfr> Apple platforms have overscroll on subscrollers<br> <emeyer> TabAtkins: It would be nice of non-root scroller behavior was similar to fixed-position and the root scrollers.<br> <emeyer> s/nice of/nice if/<br> <astearns> ack smfr<br> <emeyer> smfr: Apple platforms have overscroll on subscrollers, have shipped that for many years.<br> <emeyer> TabAtkins: What’s the abspos behavior?<br> <emeyer> smfr: If a scroll isn’t a container block, then the abspos will follow, meaning overscroll will apply.<br> <emeyer> …I think the rest here is that on the root, abspos will dissociate from the scorlling context.<br> <chrishtr> q+<br> <emeyer> …Potentially you can get negative offsets, depending on the implementation of scrolling.<br> <astearns> ack flackr<br> <emeyer> flackr: There’s no specification of what should be done for overscroll, and it can be quite different platform to platform. Maybe we should have guidelines.<br> <emeyer> …It would be awkward to reflect Android behavior. I realize this would result in developer-positioned things being out of alignment from positioned content.<br> <TabAtkins> Agree with flackr - overscroll shouldn't be reflected into APIs (or at least, not the normal ones; maybe we could produce specialized query APIs that reflect this). It's a transitory effect and UA-specific.<br> <smfr> q+<br> <emeyer> …Anything you’re trying to keep in alignment will often get out of sync during normal scrolling.<br> <astearns> ack smfr<br> <emeyer> smfr: I agree with a lot of what was just said. We consider overscroll as an unstable state. We’re willing to let things be not entirely correct.<br> <emeyer> astearns: flackr was saying overscroll is a stretch, not a translation.<br> <emeyer> flackr: On Android, content that’s at the top is still at the top, but it’s stretched by some amount.<br> <emeyer> smfr: So it’s like a rubber sheet that stretches more at the edge?<br> <astearns> ack chrishtr<br> <emeyer> flackr: Yep.<br> <emeyer> chrishtr: I agree we shouldn’t expose thing to developers during scroll. For overscroll on non-root scrollers, I would expect the right behavior to be that overscroll only applies to content that’s scrolled.<br> <flackr> q+ to mention sticky can be similar when it is still free to move<br> <emeyer> …Abspos is different than fixedpos because they have different containing blocks.<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to mention sticky can be similar when it is still free to move<br> <flackr> +1<br> <TabAtkins> On reflection, yeah, fixposes aren't fixed wrt the root scroller, but to the viewport, which is "outside" the root scroller; this is indeed consistent with the abspos behavior for subscrollers.<br> <smfr> q+<br> <emeyer> flackr: Under certain circumstances, stickypos feels very similar to fixedpos. This is the sort of case where we might want to exclude stickpos.<br> <astearns> ack smfr<br> <emeyer> smfr: I agree sticky should have the same treatment as fixed when it responds to the viewport.<br> <emeyer> …Do we want authors to be able to pick how overscrolls happen?<br> <emeyer> flackr: Fixed will not respect overscroll, is the proposal. We could add a way to opt out of that in the future.<br> <TabAtkins> Agreed when stickypos is sticky to the viewport that it should *remain* sticky to the viewport when the content is overscrolling, same logic as fixpos.<br> <emeyer> …Not reflected in getBound and clientRect.<br> <iank_> i wonder if that'd break existing apps that use fixed-pos as a sidebar.<br> <flackr> s/flackr/chrishtr<br> <emeyer> smfr: On Apple platforms, overscroll affects scroll position. My concern is that things could get more complicated.<br> <emeyer> flackr: On Chrome, we don’t have negative scroll position.<br> <TabAtkins> Letting overscroll be *detectable* makes sense; don't think it needs to be detectable *by the scrollOffset*<br> <TabAtkins> because it'll be UA-specific to do so<br> <flackr> +1<br> <emeyer> smfr: intersection observer might also be affected.<br> <emeyer> astearns: Do you want to look through those things before we resolve?<br> <TabAtkins> fixpos *and* stickpos that stick to the viewport<br> <emeyer> smfr: I’m okay saying UAs can choose what to do.<br> <iank_> how difficult is it to add a switch for this?<br> <emeyer> astearns: Sounds like you are suggesting merely a note about this interaction. I was hoping we could get something like overscroll is not defined, we do resolve that fixedpos do not participate in that behavior.<br> <emeyer> smfr: I think we also have to specify the client coordinate APIs.<br> <emeyer> flackr: We have to allow platofrms to diverge on how they represent overscroll.<br> <emeyer> iank_: How difficult would it be to add a switch to control this behavior?<br> <emeyer> …with regards to the fixedpos.<br> <emeyer> smfr: I don’t think it would be hard but we’d have to figure out what it applies to.<br> <emeyer> iank_: A global flag would be easier than per-element for you?<br> <emeyer> smfr: Yes.<br> <emeyer> iank_: People use fixedpos for different things. There’s clear use cases for if you want them to move or not. I worry we’ll make some subset of people unhappy either way.<br> <emeyer> smfr: Fixedpos layout should be defined is that it’s relative to the viewport. If you add alternate behaviors, you have to define a lot more.<br> <chrishtr> The proposed note will be compatible with sidebars, since it seems best for them not to overscroll<br> <emeyer> iank_: We already have this complexity with abs and fixed pos. They resolve against two different rectangles.<br> <emeyer> smfr: We certainly have code that only applies to sticky or fixed.<br> <emeyer> …It’s complicated and I’d prefer not to make it more complicated.<br> <emeyer> iank_: I can see circumstances where you want fixed pos to move with overscroll, and others where you don’t.<br> <emeyer> flMy high-level view is that things that move with scroll should be affected by overscroll.<br> <emeyer> (previous was from flackr)<br> <emeyer> astearns: We have WebKit considering it a bug that these things do move, do we have bugs on Firefox complaining that they don’t?<br> <emeyer> emilio: We used to have them moved, and we changed so they didn’t.<br> <emeyer> astearns: It sound like the only thing we can come to consensus on today is a non-normative note that browsers _may_ do what they like. I’m reluctant to do something that weak.<br> <chrishtr> q+<br> <emeyer> TabAtkins: I don’t think we have to be that weak. Simon’s asking for us to specify the non-moving behavior. Are there strong objections to us doing that, Simon?<br> <emeyer> smfr: Seems like it’s adding a non-consistency to the specs.<br> <emilio> q+<br> <emeyer> TabAtkins: We certainly wouldn’t be getting worse, since there’s no spec text right now.<br> <emeyer> astearns: I’d be reluctant to resolve without having gone through all the JS APIs. We don’t want to make things incoherent.<br> <astearns> ack chrishtr<br> <emeyer> chrishtr: Non-nomative note that says SHOULD as opposed to MAY?<br> <astearns> ack emeyer<br> <astearns> ack emilio<br> <emeyer> emilio: QA filed a bug mentioning things didn’t match between browsers.<br> <emeyer> …We certainly haven’t recieved complaints about the Chrome behavior.<br> <emeyer> astearns: Could do a non-normative SHOULD note.<br> <emeyer> fremy: Not sure of the point of making it non-normative if it says SHOULD.<br> <emeyer> s/fremy/fantasai/<br> <fremy> scribenick: fremy<br> <bmathwig> +1 to that<br> <fremy> chrishtr: when we make it non-normative, the practical result is that chromium considers changing the behavior<br> <fremy> astearns: the proposal is thus to add a normative should for this<br> <fremy> astearns: would anyone object to this?<br> <fremy> RESOLVED: fixed-position elements whose scroller is not their containing block do not participate in overscroll<br> <flackr> +1 support for sticky<br> <fremy> TabAtkins: also sticky<br> <fremy> astearns: any objection to adding sticky?<br> <fremy> RESOLVED: the former statement also applies to sticky element when stuck<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4549#issuecomment-1067389586<br> <dbaron> no, you want to fix the github back to the original<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/6299<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6299#issuecomment-1076552713 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 March 2022 16:56:50 UTC