[css-overflow] set element as document scrolling element

[tylersticka]

It's relatively straightforward to use overflow properties to make a child element of a page scroll independently of the document. But it's a much larger effort currently to allow "fullscreen" elements like modals, menus and dialogs to seamlessly become the primary scrolling element while "locking" the scroll of the parent page.

I suspect this is an overly optimistic idea, but in a perfect world this behavior would be as simple to define as this:

.menu.is-open {
  overflow: document;
}

(I was encouraged to submit this issue after writing about the idea.)

[tabatkins]

I would really enjoy something for this as well. It's currently somewhat awful to, for example, make body a fullscreen grid, with header/footer/aside/nav around the edges and main be in the center and scrollable, because it doesn't receive the document-scroller behavior of implicitly getting all otherwise-untargeted scrolls.

I have no idea what the impl constraints are, tho. @bfgeek, can you route?

[tabatkins]

Actually, good chance this is @bokand or @majido?

[bokand]

By "locking the scroll of a parent page", you mean that scrolls don't bubble up to the parent? If so, this is quite easy now with scroll-behavior: none. Or am I misunderstanding the use case?

[tylersticka]

By "locking the scroll of a parent page", you mean that scrolls don't bubble up to the parent? If so, this is quite easy now with scroll-behavior: none. Or am I misunderstanding the use case?

Currently if you want a menu or modal to lock the page scroll while being scrollable itself, you may need to perform the following steps:

1. You need to prevent scrolling of the document so two scrollbars do not inadvertently show up. (I haven't used scroll-behavior: none and I'm having trouble finding documentation for it, so it's hard to say if that meets this need.)
2. Some techniques for preventing document scrolling (such as overflow: hidden or position: fixed on the body) will also reset the user's scroll position, so you'll need to store that so you can restore it when closing the modal/dialog/menu.
3. If the document is still visible beneath the modal/dialog/menu, you will see a visible "jump" back to the top of the page when the menu is open as soon as its scroll is locked. In these cases, you might use top or translateY to visually offset the document body by the same amount as its former scroll position.
4. You then need to make sure the bounding box of your modal/dialog/menu is large enough that it will be intuitive to scroll. This often involves making a container that covers the entire viewport that is set to overflow: auto, then making the actual menu or modal box within it separate. (That way the user doesn't have to reach or move their cursor to a small area to scroll the content.)

But I really like @tabatkins' example, too, because it removes the "scroll-locking" part of the equation entirely. It's possible that I'm conflating the challenge of locking the page scroll with the challenge of having a child element function to the end user as the document.scrollingElement.

Would it help if I were to whip up some use case code examples?

[bokand]

Scroll-behavior lets you prevent scroll from chaining up to the parent. It won't affect things like scrollbars though - you'd have to hide those yourself somehow. For that I'm not sure there's a great solution - you could just apply ::webkit-scrollbar styles to hide the scrollbars but that only works in Blink/WebKit and also might incur layout issues.

There's also root-scroller which shipped in Chrome. It lets you mark a single scroller on the page as the "main content" and we give it all the special UX that only the documentElement gets today.

There wasn't any interest from other vendors to make this more flexible with an API so we've limited it to an implicitly applied UA feature. However, because it's implicitly applied, we're rather restricted in how often we can apply it to prevent breaking pages inadvertently. We'll only promote an element to the root-scroller if it meets a rather rigid set of criteria.

[tabatkins]

Ah yeah, implicit-root-scroller doesn't solve my use-case (since the grid item containing the main content does not fill the entire screen, which is one of the conditions). :(

[SebastianZ]

It won't affect things like scrollbars though - you'd have to hide those yourself somehow. For that I'm not sure there's a great solution

To hide scrollbars there is scrollbar-width: none.

Sebastian

[frivoal]

Correction: references in comments above to scroll-behavior and scroll-behavior: none should be read as references to overscroll-behavior. That's a different property.

[simevidas]

This should work:

.menu.is-open {
  overflow: auto;
  overscroll-behavior: contain;
}

The reason why it doesn’t work is because browsers don’t follow the specification:

#3349 (comment)

We’re in a weird situation. Web developers want a common-sense behavior (prevent page from scrolling when hovering modal dialog), the CSS specs provide a simple solution for this behavior, but none of the three major browser engines implement this behavior correctly.