[css-overscroll] the target of overscroll-behavior should be scrolling box instead of scroll container?

[hiikezoe]

An example;

<div style="height: 20vh; overflow: hidden; overscroll-behavior: none;">
  <div>overflow: hidden; overscroll-behavior: none;</div>
  <div style="height: 100vh; width: 100%;"></div>
</div>
<div style="height: 200vh; width: 100%;"></div>

In my understandings with the current spec text (i.e. "applied to scroll container"), scrolling on the overflow: hidden element shouldn't be handed off to the outer one, but in fact both Chrome and Firefox hand off it to the outer.

[hiikezoe]

When I opened this issue, I was naively thinking all not-scrolling-box should not respect overscroll-behavior properties. That said, I think now, in the case of viewports things are a bit more complicated.

So for example, if the top level content document specifies overscroll-behavior: none, I am pretty sure such sites want to implement their own reload contents feature when the user swipe down the content or something like that. But if the document doesn't have enough contents to make it scrollable (i.e. make it a scrolling box), the site still wants to reload by swiping down? I am pretty sure it does.

Also note that if another website embeds such sites in iframes, users expect the embedded sites not to capture the swipe gestures, instead the users want to scroll the outer document if the embedded documents are not scrollable at all.

[nanto]

I think it's helpful if scrolling on an overflow: auto element with no scroll range doesn't hand off to outer elements. The major use case is to prevent background scrolling when a modal dialog is open.

Many people are looking for a way to prevent background scrolling when a modal dialog is open. Some people use body { overflow: hidden; } but this way has some problems:

1. Needs JavaScript to know the timing to specify overflow: hidden to the body element.
2. Scrollbar gutter disappears and the reflow happens on the content of the body element.

If scrolling on an element with no scroll range doesn't hand off, we can just write as dialog:modal { overscroll-behavior: contain; }. This way works as expected on Chrome canary 110 but doesn't work on Firefox nightly 109.

[hiikezoe]

If scrolling on an element with no scroll range doesn't hand off, we can just write as dialog:modal { overscroll-behavior: contain; }. This way works as expected on Chrome canary 110 but doesn't work on Firefox nightly 109.

I tested it on Chrome Canary 110.0.5453.0, it does still hand off.

[hiikezoe]

If scrolling on an element with no scroll range doesn't hand off, we can just write as dialog:modal { overscroll-behavior: contain; }. This way works as expected on Chrome canary 110 but doesn't work on Firefox nightly 109.

I found there's an open spec issue for such case.

[nanto]

If scrolling on an element with no scroll range doesn't hand off, we can just write as dialog:modal { overscroll-behavior: contain; }. This way works as expected on Chrome canary 110 but doesn't work on Firefox nightly 109.

I tested it on Chrome Canary 110.0.5453.0, it does still hand off.

Sorry, my examination was incomplete. On Chrome, scrolling by mouse wheel or two-finger swipe doesn't hand off but scrolling by Arrow/PageUp/PageDown key does hand off.

I found there's an open spec issue for such case.

Thank you for letting me know!

[xPaw]

I think it's helpful if scrolling on an overflow: auto element with no scroll range doesn't hand off to outer elements. The major use case is to prevent background scrolling when a modal dialog is open.

I agree with this, overscroll-behavior is much less useful in my use cases even when overflow-y: scroll is set, but the element is not scrollable because it fits on the screen, which causes overscroll to still happen.