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

> > 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?
>

Its main purpose is to allow feature detection because it is not possible
to feature detect the existence of the new optional fourth argument on its
own. Exposing option allows the following feature detection:

var canControlScrollRestoration = ‘options’ in window.history &&
‘restoreScroll’ in window.history.options;

As a minor advantage, it may be useful for libraries that will handle
scroll restoration. They can check history.options.restoreScroll and decide
whether they need to restore scroll or user agents will do so. The same can
be done with a boolean in state itself so this is just a nice to have.

Of course if we were to add a new method this would not be needed.

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).
>

I think this is a good idea.


> 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.
>
I think a method to prevent/customize scrolls
<https://code.google.com/p/chromium/issues/detail?id=416862> might be
helpful in this situation but it may be a while before such an API actually
becomes available. In the meantime, this proposal is simple and easy to
implement and addresses a serious issue for developers.


>
> 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".


Sounds like a reasonable plan. Hopefully we can get more vendors interested
and I am more than happy to adjust the proposal to help this happen.

Majid

Received on Friday, 10 April 2015 19:41:32 UTC