Intent to Implement: Scroll Anchoring Serialization

[pno...@chromium.org]

Contact emails

pno...@chromium.org, chrome-...@chromium.org

 

Spec

Scroll Anchoring Serialization Design

Summary

Scroll anchoring is an intervention that prevents visible page jumps when content above the visible viewport changes. We propose to use a serialized representation of the scroll anchor to restore the scroll position and scroll anchor on history restore. 

 

Motivation

Currently, the scroll anchor element is transient and only absolute pixel offsets are saved/restored when performing history navigation or history restoration. Further, even newly computed anchors are clobbered when restoring. Restoring scroll position via the scroll anchor instead of the absolute offset allows the anchor to be established much earlier, preventing reflows during page load from causing visible jumps. 

 

Interoperability Risk

Scroll anchoring itself has shipped in Chrome, and Mozilla has expressed interest in implementing it. There are no signals from other vendors about using a serialized scroll anchor in the session history. 

Compatibility Risk

Moderate. Manual scroll restoration via the history API won't be affected, but pages that perform scroll restoration in other ways have the potential to break since they may expect the absolute offset behavior. The proposed change also does not affect the developer facing API w.r.t. scroll anchoring, which still allows for suppression of the scroll anchoring behavior. 

 

Ongoing technical constraints

None

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

 

OWP launch tracking bug

crbug.com/734679

 

Link to entry on the feature dashboard

I don't think this is needed because at this point it's not a developer-facing change? I will happily create one if I'm wrong about this.

 

Requesting approval to ship?

No. (Runtime flagged)

[Joe Medley]

"I don't think this is needed because at this point it's not a developer-facing change?"

Are there any hacks to get around what this fixes? How common are they? Developers might want to know they don't need to do them anymore. 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0d16fcb4-b905-4a35-aa62-c3a822208533%40chromium.org.

[pno...@google.com]

Most of the techniques for addressing this are larger than hacks since they're targeted at the much bigger problem of creating smooth transitions between pages, especially on mobile devices with slow connections. Off the top of my head, these are some common techniques:

• Make your page an SPA and use pushState with {historyRestoration: manual} to manually restore scroll position. The proposed change won't affect this technique.
• Use "skeleton" pages(HTML templates cached by a service worker). This technique is a general purpose one for progressive loading and I don't think the proposed change is sufficient to make it unnecessary. 
• Pre-declare the size of img elements so that their loading doesn't cause visible page jumps. The proposed change does make this less important, but I feel like this is a good practice anyhow.

I don't know about any Chrome-specific hacks that this removes the need for, so it might be premature to tell people they can stop using a hack when other browsers would still need them?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Steve Kobes]

Agreed this is not really a developer-facing change, except insofar as it makes scroll anchoring work more reliably.  Anything developers are currently doing to reduce the need for scroll anchoring (e.g. declaring img sizes) is probably something they should continue doing.

This intent fixes a significant limitation of the current scroll anchoring implementation, namely that it doesn't work during back/forward/reload navigations.  I'm excited we're finally plugging that hole.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/016ef0c6-758d-4fe7-921a-ba1dd8b2e4f2%40chromium.org.

[Joe Medley]

"I don't know about any Chrome-specific hacks that this removes the need for, so it might be premature to tell people they can stop using a hack when other browsers would still need them?"

You're half right. We never tell people "stop now". Part of Dev-Rel's job is to draw attention to over all platform improvements. In the short term, developers can add features tests around their hacks or polyfills, especially when doing so will improve performance for some users. 

I'm not saying that's necessary here. I'm just saying that's a consideration for us.