Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

On Thu, 19 Mar 2015, Majid Valipour wrote:
>
> Almost all browsers restore scroll position when a user traverses 
> history. This behavior works well for document style web sites but it is 
> often not appropriate for single-page web applications where the page 
> content may be reconstructed (often asynchronously) upon navigation and 
> where the application wants to control the details of visual transition 
> between UI states.

Seems reasonable.


> Avoid document scrolling altogether by fixing body size and putting 
> content in an inner scrollable div. This breaks browser features that 
> depend on document scrolling such as top controls hiding, or overscroll 
> visuals and in some cases disables fast scroll optimizations for 
> document scrolling.

Also really it's a bug in browsers that such divs aren't getting the 
scroll position restored as well.


> Below is the IDL for the proposed changes:
> 
> partial interface History {
>   void pushState(in any data, in DOMString title, in optional DOMString
> url, in optional StateOptions options);
>   void replaceState(in any data, in DOMString title, in optional DOMString
> url, in optional StateOptions options);
>   readonly attribute StateOptions options;
> };
> 
> dictionary StateOptions {
>   Boolean restoreScroll = true,
> }

I'm not sure there's much point exposing history.options, what's the 
purpose of that?

Also, I'd recommend an option name that suggests more strongly that the 
author is expected to restore the position themselves, rather than just 
that the position shouldn't be restored. For example, calling it something 
like "willRestoreScrollPosition" (defaulting to false, meaning the UA 
should do it).


On Wed, 25 Mar 2015, Anne van Kesteren wrote:
> 
> The only suggestion I have is that instead of having four-argument 
> methods we might want to consider introducing two new methods that take 
> a dictionary. E.g. history.push() and history.replace(). Giving the page 
> more control over the scroll position when navigating makes sense to me.

I'd strongly recommend against adding new methods. It'll mean we now have 
two different ways to do the same thing, which means more bugs, which 
means less interoperability, more confusing behaviour for authors, more to 
document, etc.

I think the original approach of adding a fourth argument is much better.

It's also a better API in general, since the URL should always be given. 
If we had a one-argument form with a dictionary, people would consider not 
giving the URL but just disabling scrolling, which is suboptimal.


On Wed, 25 Mar 2015, Jonas Sicking wrote:
>
> Is this really something we should tie to the pushState/replaceState 
> API?
> 
> It seems like websites that lazily add more content as the user scroll 
> down, like the facebook feed or twitter feed, might not use 
> pushState/replaceState, but would still like to handle restoring scroll 
> position themselves.

On Thu, 26 Mar 2015, Simon Pieters wrote:
> 
> Yeah... also consider navigating back and forth between two different 
> sites/apps, without navigating within each site/app. Should they be able 
> to turn off scroll restore?
> 
> Is this something that should be toggled on a per-page basis or on a 
> per-navigation basis? If per-page, is it enough to just be able to turn 
> it off (i.e. not turn it on again)?

These are interesting points.

It seems like what you really want is a way to hook into the scroll 
behaviour. For example, we could fire an event at the document saying 
"we're about to automatically scroll to 75% of the way down the page, 
cancel this if you want to do it yourself". The real problem with that, 
though, is that 75% means nothing in the cases where you'd want to 
actually do it yourself. It's not clear to me how you could convey the 
information that is actually needed.

Maybe infinite-scroll pages _should_ use replaceState(), to say how much 
they have loaded. At which point, the boolean flag seems reasonable again.


Are there other vendors interested in implementing this?

If not, I recommend that Chrome implement this as the fourth argument with 
a dictionary with a boolean that implies that the author will perform the 
scroll position restoration behaviour themselves, and then filing a bug on 
the spec with the Target Milestone set to "Needs Impl Interest".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 9 April 2015 19:05:48 UTC