Let's say I have a navigation that as-soon-as-possible loads a page skeleton, then loads the data afterwards.
Push/replace load
Load skeleton content.
Scroll to target element, or 0,0.
Load real content.
If there's a target element, and there wasn't one before: scroll to it.
If there's a target element, and there was one before, but it's in a significantly different position to before: scroll to it.
Traversal
Load skeleton content.
Restore scroll.
Load real content.
If reapplying scroll restoration would result in a significantly different position: do it.
The reason you'd restore twice is if the intent was to restore to y=2000, but the page skeleton wasn't tall enough to accommodate that.
This is pretty hard to do in the current API.
Could this be achieved by allowing the developer to call scroll.restore() multiple times, and call it even when the scroll mode is "after-transition"?
Alternatively, there could be a scroll restoration mode of "throughout-transition", which attempts to do this automatically, reacting to DOM changes during the transition, as well as afterwards.
I'm not confident in my "significantly different position" heuristic. I'm thinking of what the browser does during a streaming page load.
Let's say I have a navigation that as-soon-as-possible loads a page skeleton, then loads the data afterwards.
Push/replace load
Traversal
The reason you'd restore twice is if the intent was to restore to y=2000, but the page skeleton wasn't tall enough to accommodate that.
This is pretty hard to do in the current API.
Could this be achieved by allowing the developer to call
scroll.restore()
multiple times, and call it even when the scroll mode is "after-transition"?Alternatively, there could be a scroll restoration mode of "throughout-transition", which attempts to do this automatically, reacting to DOM changes during the transition, as well as afterwards.
I'm not confident in my "significantly different position" heuristic. I'm thinking of what the browser does during a streaming page load.