[css-overflow-5] Limit scrolling to the associated scroll container when activating a marker

[flackr]

Currently, when a scroll marker is activated, the activation behavior scrolls the scroll target into view. This behavior right now will scroll every scrolling box up to the root to the target.

I think that it is quite common to expect that the scroll stops at the managed scroll container. E.g. @bakura10 from twitter mentioned this expectation in #9452 (comment). In #9452 I proposed adding this option to the scroll into view api.

The question here is, should we restrict the scroll into view for activation to stop at the scroll marker group container? This would mean that we would not ensure that the group container is currently scrolled into view in all of it's ancestor scrolling containers.

If we don't restrict this, you could end up in a degenerate situation when the scroll markers are above the targeted scroll marker group container as scrolling the ancestors of the group container to position the group container into view would naturally scroll the markers out of view.

I propose we do this.

[tabatkins]

Yes, I think we absolutely need to add the "stop at this element" option behavior to the scrolling APIs, and auto-invoke it for marker activation to stop at the scroll marker group container.

So, proposals:

1. Accept the proposal in [cssom-view] Consider adding Element.scrollParent #1522, defining a new Element.scrollingParent accessor that returns the nearest scrollable ancestor of an element.
2. Then, accept the proposal in [cssom-view-1] Option for scrollIntoView that doesn't propagate to ancestors #9452, defining a new container option for the scrollIntoView() method, taking an optional Element to stop at. (The previous one makes it easy to just stop at the nearest scroller.)
3. Then, accept the proposal here, to make scroll-marker scrolling automatically stop at the scroll marker group container.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Limit scrolling to the associated scroll container when activating a marker, and agreed to the following:

• RESOLVED: Only propagate the scroll into view for a scroll marker up to the common ancestor scroller of the targets

The full IRC log of that discussion

<andreubotella> flackr: when you have scroll markers as part of a control that are scrolling some scrollable area, it's not expected that scrolling that thing scrolls things outside it
<andreubotella> flackr: authors often expect that scrolling a container only scrolls inside that container
<kizu> q+
<fantasai> sgtm
<andreubotella> flackr: limit scrolling to the common scrolling container of the markers
<andreubotella> flackr: there are some related issues, but we don't have to discuss them here
<andreubotella> kizu: +1
<astearns> ack kizu
<andreubotella> kizu: one common case if we don't do this – a ToC that is a sidebar on mobile but on top on desktop, you don't want the scroll section to go back up
<andreubotella> PROPOSED RESOLUTION: Only propagate the scroll into view for a scroll marker up to the common ancestor scroller of the targets
<andreubotella> RESOLVED: Only propagate the scroll into view for a scroll marker up to the common ancestor scroller of the targets

[flackr]

Spec edits are landed in #11674