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

** Re-sending my response with my member email address to ensure it is included
in the mailing list archive. Apologies for duplication.

On Thu, Mar 26, 2015 at 5:16 AM Simon Pieters <simonp@opera.com>
…

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

Yes. It think it should be possible for the application to control scroll
restoration for all of its own history entries including the one implicitly
created by the user agent upon initial load and the ones that are
explicitly create by itself for the purpose of internal navigation.

For example a news site may want to always send user to the page top where
top news are displayed regardless of where the user was before. This is
currently being achieved by resorting to workarounds such as setting body
size to 100% and using inner divs (e.g., CBC news
<http://www.cbc.ca/m/news/>).

Note that currently scroll is consistently restored regardless of the type
of the navigation (intra-app, inter-app). I don't think we should start
treating them distinctly or even change their default restoration behavior
as long as we provide ability for application to opt out of scroll
restoration for either type. The current proposal does just that and lets
the application decide what is best for their particular need.
…


> 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)?
>
> e.g.
>
> history.restoreScroll = false;
>
> or
>
> history.disableRestoreScroll();
>
>
We did consider a per-page global flags as an alternative design and it is
discussed in the original proposal document
<https://docs.google.com/a/chromium.org/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM>.
Here is a summary of  why we think an API that gives per-navigation control
is a better fit:

   - Scroll is restored per-navigation so an API for controlling it
   per-navigation is more natural and better represents the underlying
   behavior. A global per-page switch hides this fact and is harder to reason
   about unless we also change the scroll restoration to become per-page.
   - Controlling scroll restoration per-navigation is more flexible than
   per-page. It is trivial to implement a pollyfill for disabling scroll
   restoration per-page if we have the per-navigation version but the reverse
   is not true. I imagine libraries such as History.js and jQuery UI will be
   providing a flag to disable it per-page (or per app).
   - There are legitimate usecases where an application may want to have
   different scroll restoration behavior for its different UI state (i.e., per
   navigation). For example Facebook may want to have automatic restoration in
   timeline but disable it on photo pages.

Thanks

Received on Tuesday, 7 April 2015 12:57:07 UTC