Review request for Scroll Anchoring

[KenjiBaheux]

Spec: https://cdn.rawgit.com/WICG/interventions/master/scroll-anchoring/spec.html

Abstract:
Changes in DOM elements above the visible region of a scroller can result in the page moving while the user is in the middle of consuming the content.

This spec proposes a mechanism to mitigate this jarring user experience by keeping track of the position of an anchor node and adjusting the scroll offset accordingly.

This spec also proposes an API for web developers to opt-out of this behavior.

---

Context: we've reached a point where we are confident in our design and have run out of known web compatibility issues. The next logical step would be to try shipping this, listen for feedback and iterate if needed. We would like to request a TAG review for the spec. The current timeframe we are aiming for is: Chrome 56 (branch cut: Nov 17th, 2016).

Thanks in advance.

[triblondon]

I am personally very excited about having this feature.

2.1, step 2, third bullet:

If N is fully clipped in S, skip over E and its descendents.

There is no definition of E

2.2: Is it intended that the use case for this is only content changes higher up in the document, or does it also directly address the case where the viewport is resized, causing layout, with no changes to the document?

Suppression triggers: this appears to act to turn off the anchoring feature if the movement of the anchor element is caused by a change to any ancestor of it. But wouldn't it be a common scenario that content moves as a result of a change to an ancestor element (eg increasing padding on the document body in order to dynamically insert an absolutely-positioned ad) in a situation where anchoring would be desirable?

It would be useful to know (in a non-normative aside, perhaps) specifically why these exclusions exist. This one in particular is interesting:

Any change to the computed value of the position property on any element within the scrollable element (or document), such that the element acquires or ceases to have an out-of-flow position (fixed or absolute). Note that this trigger applies regardless of whether the modified element is on the path from the anchor node to the scrollable element.

Reuse of overflow-anchor from the CSS Sticky Scrollbars spec seems to cause a conflict, only one use of the term could work in practice?

Is there a realistic scenario of a developer implementing logic that would move the anchor element in response to the document's scroll offset changing? Eg. if you scroll to the bottom of a document and that triggers content to be added at the top, then scroll anchoring would reposition the viewport at the bottom to keep the anchor node in view, and that would in turn trigger the content loading event handler, creating an infinite loop of content loading.

It would be good to link to the explainer from the spec.

[travisleithead]

Also, see explainer: https://github.com/skobes/ScrollAnchoring/blob/master/explainer.md

[skobes-chromium]

Thanks @triblondon, I have fixed the typo in 2.1 and added a link to the explainer.

The suppression triggers are mainly to handle pages that implement various forms of "sticky headers". In the simplest case, script simply toggles position:fixed on a header element below a scroll offset, causing the content to shift by pulling it out of flow. We've also seen animation on document body padding at the transition. See e.g. http://crbug.com/601906 and http://crbug.com/641814.

I think the reuse of overflow-anchor makes sense because scroll anchoring and sticky scrollbars are two alternative strategies for connecting scroll position to layout. It wouldn't make sense to want both at the same time.

The infinite-scroller content loop is an interesting idea, we haven't encountered scenarios like this in practice. Typically a scroll-triggered content load inserts at the bottom and not the top.

[dbaron]

/cc @tabatkins @fantasai to provide feedback on the overflow-anchor name, perhaps either here or in w3c/csswg-drafts#676

[triblondon]

Picked up at TAG F2F in Boston. I'm still concerned about the potential for inconsistency from a developer perspective. A common pattern is to animate open a zero-height element containing an ad when the viewport encounters the placeholder. If that element is in the ancestry of the anchor node (eg if it is the document body) then scroll anchoring is suppressed, whereas if it is not, scroll anchoring is activated. It's not a huge problem, but it may confuse people initially.

Otherwise LGTM, and I'm (still) excited about having this feature :-)

[RByers]

For reference, current spec and explainer are at: https://github.com/WICG/ScrollAnchoring