- From: Majid Valipour <majidvp@chromium.org>
- Date: Tue, 07 Apr 2015 12:56:40 +0000
- To: Simon Pieters <simonp@opera.com>, WHATWG <whatwg@whatwg.org>
** 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