[css-overscroll] Whether to move position:fixed elements during overscrolling

[hiikezoe]

As of now, Chrome and Safari move position:fixed element during overscrolling and Firefox does (since bug 1704503) to match their behavior. But WebKit thinks it's a bug.

[hiikezoe]

CC @smfr

[smfr]

One question is whether they move at all. The other question is whether that is detectable by the page (e.g. via getBoundingClientRect()).

[bmathwig]

Would it be possible to revive this discussion? The Microsoft Edge PWA team has a use-case where fixed position elements not being included in the overscroll effect would be beneficial.

[smfr]

We currently consider it a bug that WebKit moves fixed elements on over scrolling.

[bmathwig]

Edge will also treat it as a bug and fix accordingly. @atanassov Can we add this as an agenda item for resolution in a future WG meeting? It might be as simple as making a note in the spec about it.

[flackr]

One question is whether they move at all.

I think that is the main issue being questioned here. My opinion is that as fixed pos elements do not move with scroll they probably also shouldn't move with overscroll. However, this could make certain kinds of affordances challenging - e.g. if the browser wants to show some information at the top in the "revealed" part of the page the fixed pos elements may occlude this.

The other question is whether that is detectable by the page (e.g. via getBoundingClientRect()).

I don't have strong opinions, though it is important that on android we stretch during overscrolling which would be even more awkward to represent. I think overscrolling could be considered purely a UA effect with no developer visible effect - this is what Chrome does right now.

[chrishtr]

I don't have strong opinions, though it is important that on android we stretch during overscrolling which would be even more awkward to represent. I think overscrolling could be considered purely a UA effect with no developer visible effect - this is what Chrome does right now.

+1 that it shouldn't be developer-exposed.

[css-meeting-bot]

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

The full IRC log of that discussion

<emeyer> Topic: [css-overscroll] Whether to move position:fixed elements during overscrolling
<emeyer> github: https://github.com//issues/6299
<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.
<TabAtkins> q+
<smfr> q+
<flackr> q+
<emeyer> …There are use cases to do both. Can we formalize this and get it in the spec?
<emeyer> astearns: Do we have any spec text asserting one way or the other?
<emeyer> ben: I didn’t find any.
<astearns> ack TabAtkins
<emeyer> TabAtkins: I don’t have a strong opinion here, both options seem potentially reasonable. Does anyone have overscroll on non-root situations?
<emeyer> Ben: Edge and Chrome don’t have overscroll on subscrollers.
<smfr> Apple platforms have overscroll on subscrollers
<emeyer> TabAtkins: It would be nice of non-root scroller behavior was similar to fixed-position and the root scrollers.
<emeyer> s/nice of/nice if/
<astearns> ack smfr
<emeyer> smfr: Apple platforms have overscroll on subscrollers, have shipped that for many years.
<emeyer> TabAtkins: What’s the abspos behavior?
<emeyer> smfr: If a scroll isn’t a container block, then the abspos will follow, meaning overscroll will apply.
<emeyer> …I think the rest here is that on the root, abspos will dissociate from the scorlling context.
<chrishtr> q+
<emeyer> …Potentially you can get negative offsets, depending on the implementation of scrolling.
<astearns> ack flackr
<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.
<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.
<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.
<smfr> q+
<emeyer> …Anything you’re trying to keep in alignment will often get out of sync during normal scrolling.
<astearns> ack smfr
<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.
<emeyer> astearns: flackr was saying overscroll is a stretch, not a translation.
<emeyer> flackr: On Android, content that’s at the top is still at the top, but it’s stretched by some amount.
<emeyer> smfr: So it’s like a rubber sheet that stretches more at the edge?
<astearns> ack chrishtr
<emeyer> flackr: Yep.
<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.
<flackr> q+ to mention sticky can be similar when it is still free to move
<emeyer> …Abspos is different than fixedpos because they have different containing blocks.
<astearns> ack flackr
<Zakim> flackr, you wanted to mention sticky can be similar when it is still free to move
<flackr> +1
<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.
<smfr> q+
<emeyer> flackr: Under certain circumstances, stickypos feels very similar to fixedpos. This is the sort of case where we might want to exclude stickpos.
<astearns> ack smfr
<emeyer> smfr: I agree sticky should have the same treatment as fixed when it responds to the viewport.
<emeyer> …Do we want authors to be able to pick how overscrolls happen?
<emeyer> flackr: Fixed will not respect overscroll, is the proposal. We could add a way to opt out of that in the future.
<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.
<emeyer> …Not reflected in getBound and clientRect.
<iank_> i wonder if that'd break existing apps that use fixed-pos as a sidebar.
<flackr> s/flackr/chrishtr
<emeyer> smfr: On Apple platforms, overscroll affects scroll position. My concern is that things could get more complicated.
<emeyer> flackr: On Chrome, we don’t have negative scroll position.
<TabAtkins> Letting overscroll be *detectable* makes sense; don't think it needs to be detectable *by the scrollOffset*
<TabAtkins> because it'll be UA-specific to do so
<flackr> +1
<emeyer> smfr: intersection observer might also be affected.
<emeyer> astearns: Do you want to look through those things before we resolve?
<TabAtkins> fixpos *and* stickpos that stick to the viewport
<emeyer> smfr: I’m okay saying UAs can choose what to do.
<iank_> how difficult is it to add a switch for this?
<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.
<emeyer> smfr: I think we also have to specify the client coordinate APIs.
<emeyer> flackr: We have to allow platofrms to diverge on how they represent overscroll.
<emeyer> iank_: How difficult would it be to add a switch to control this behavior?
<emeyer> …with regards to the fixedpos.
<emeyer> smfr: I don’t think it would be hard but we’d have to figure out what it applies to.
<emeyer> iank_: A global flag would be easier than per-element for you?
<emeyer> smfr: Yes.
<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.
<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.
<chrishtr> The proposed note will be compatible with sidebars, since it seems best for them not to overscroll
<emeyer> iank_: We already have this complexity with abs and fixed pos. They resolve against two different rectangles.
<emeyer> smfr: We certainly have code that only applies to sticky or fixed.
<emeyer> …It’s complicated and I’d prefer not to make it more complicated.
<emeyer> iank_: I can see circumstances where you want fixed pos to move with overscroll, and others where you don’t.
<emeyer> flMy high-level view is that things that move with scroll should be affected by overscroll.
<emeyer> (previous was from flackr)
<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?
<emeyer> emilio: We used to have them moved, and we changed so they didn’t.
<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.
<chrishtr> q+
<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?
<emeyer> smfr: Seems like it’s adding a non-consistency to the specs.
<emilio> q+
<emeyer> TabAtkins: We certainly wouldn’t be getting worse, since there’s no spec text right now.
<emeyer> astearns: I’d be reluctant to resolve without having gone through all the JS APIs. We don’t want to make things incoherent.
<astearns> ack chrishtr
<emeyer> chrishtr: Non-nomative note that says SHOULD as opposed to MAY?
<astearns> ack emeyer
<astearns> ack emilio
<emeyer> emilio: QA filed a bug mentioning things didn’t match between browsers.
<emeyer> …We certainly haven’t recieved complaints about the Chrome behavior.
<emeyer> astearns: Could do a non-normative SHOULD note.
<emeyer> fremy: Not sure of the point of making it non-normative if it says SHOULD.
<emeyer> s/fremy/fantasai/
<fremy> scribenick: fremy
<bmathwig> +1 to that
<fremy> chrishtr: when we make it non-normative, the practical result is that chromium considers changing the behavior
<fremy> astearns: the proposal is thus to add a normative should for this
<fremy> astearns: would anyone object to this?
<fremy> RESOLVED: fixed-position elements whose scroller is not their containing block do not participate in overscroll
<flackr> +1 support for sticky
<fremy> TabAtkins: also sticky
<fremy> astearns: any objection to adding sticky?
<fremy> RESOLVED: the former statement also applies to sticky element when stuck
<astearns> github: https://github.com//issues/4549#issuecomment-1067389586
<dbaron> no, you want to fix the github back to the original
<astearns> github: https://github.com//issues/6299

[chrishtr]

Re JS APIs: currently, Gecko and Chromium's implementations of overscroll do not affect any developer APIS, and are purely a "UA affordance" in that sense.

Overscroll implementations differ between platforms (e.g. I know of at least 3 approaches: rubber-band/translate [iOS/Mac], stretch [Android current], glow [old Android]), and it's good to allow UAs to try out different affordances.

Pull-to-refresh was a use case @smfr mentioned as being helped by the current negative scroll offfset approach in Safari.

Therefore, I propose:

• Specify that overscroll does not affect any JS APIs
• Solve pull-to-refresh (which I agree is worth solving) with other APIs that will be independent of the approach to overscroll, and work on platforms without overscroll affordances

[flackr]

• Solve pull-to-refresh (which I agree is worth solving) with other APIs that will be independent of the approach to overscroll, and work on platforms without overscroll affordances

And platforms with different overscroll affordances which are not translations (i.e. at this point, Android)

[smfr]

So if we specify that overscroll does not affect any JS APIs, then it becomes impossible for a page to use JS to position an element with fixed-like behavior during overscroll. Is that OK?