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

Ping.  Any thoughts from folks familiar with the history API definition?

This proposal resolves a high-profile issue we've received from a number of
major websites.  As Majid said, mobile-optimized websites are being forced
to choose between the fullscreen UX users expect from websites on phones
 (document scrolling) and the navigation transitions users expect from rich
mobile apps (full page div scrolling).  This is unacceptable for apps
trying to provide a 1st-class mobile UX on the web.  We're anxious to ship
a solution in blink ASAP.

Thanks,
   Rick

On Thu, Mar 19, 2015 at 1:31 PM, Majid Valipour <majidvp@chromium.org>
wrote:

> # Problem
> 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.
>
> Currently it is not possible to disable the scroll behavior so web
> developers
> have resorted to various hacks [1]. Here are the two most popular:
> - 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.
> - Use a secondary scroll after browser's initial attempts to restore
> scroll.
>   This leads to two visible jumps and bad UX.
>
> Few documented cases of web developers struggling with this problem may be
> found in [2, 3, 4].
>
> # Proposal
> Allow web applications to explicitly disable user agents default scroll
> restoration behavior via History API. This is achieved by adding a fourth
> optional parameter 'options' to both history.pushState,
> history.replaceState.
> Obviously the default values will be backward compatible. We should also
> provide a new attribute (history.options)  that exposes the current
> effective
> value of this new property and use it to provide a simple feature
> detection.
>
> 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,
> }
>
> Here is a more complete version of this proposal with details around
> background, current proposal design, and considered alternative designs:
>
> https://docs.google.com/a/chromium.org/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM
>
> We like to implement this or something similar in blink and would be
> interested to hear from other vendors. All feedback on proposed design is
> welcome. :)
>
> Thanks
> Majid Valipour
>
> [1]
> http://stackoverflow.com/questions/10742422/prevent-browser-scroll-on-html5-history-popstate
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=679458
> [3] https://github.com/rackt/react-router/issues/707
> [4] http://andrz.me/blog/scrollx-scroll-why-history
>
>

Received on Tuesday, 24 March 2015 14:58:50 UTC