[css-scroll-anchoring-1] add API to expose current scroll anchor and offset

[noahlemen]

Absolute scroll offsets are still commonplace in many implementations of scroll restoration. If current scroll anchor nodes could be exposed via some API it would enable engineers to build more reliable scroll restoration.

For example, we recently ran into some complications with scroll restoration on facebook.com when using content-visibility: auto on posts in feed. After clicking on a photo in feed and then later returning to feed, our existing scroll restoration tries to scroll to a stored absolute scroll offset, but with content-visibility: auto (unless contain-intrinsic-size is properly set) the content has not been laid out, and the browser will fail to scroll to a proper position. If we were able to store the feed's scroll anchor and an offset from it, we could use a combination of scrollIntoView and scroll-margin-top to return to a more appropriate scroll position. This would also avoid other issues with scroll restoration via an absolute offset, like incorrect scroll restoration after viewport resize.

https://drafts.csswg.org/css-scroll-anchoring/

Upon investigating the idea further, I noticed a similar idea is mentioned in the scroll anchoring explainer doc (https://github.com/WICG/ScrollAnchoring/blob/master/explainer.md#history-scroll-restoration).

cc: @chrishtr, @vmpstr, @flackr

[chrishtr]

Upon investigating the idea further, I noticed a similar idea is mentioned in the scroll anchoring explainer doc (https://github.com/WICG/ScrollAnchoring/blob/master/explainer.md#history-scroll-restoration).

Interesting. That section of the explainer for scroll anchoring is considering the case of a history navigation and the need to restore scroll to show the previously-anchored element.

@noahlemen: do you think it would be reasonable to model your restorations as SPA navigations in the browser history? You'd also only gett scroll offsets for the root scroller, is that enough? Then maybe this use case could be solved with a new History API option saying that, when pushing a new state, the current scroll anchor should be associated with that entry, rather than an absolute scroll offset.

If using the root scroller is too restrictive, maybe we should also expose nested scroller state to the History API?

But first let's see if the History API is enough; otherwise we might need to expose a JavaScript API for obtaining the current scroll anchor and its offset.

[noahlemen]

Yes, I think that would work for us! I believe the use-cases I have in mind would only need this for the root scroller, but I could imagine nested scroller state might be useful to be able to recall as well?

Great idea!