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

On Mon, Jul 13, 2015 at 5:56 PM, Majid Valipour wrote: > On Mon, Jul 13, 2015 at 10:55 AM Philip Jägenstedt >> If the StateOptions interface could be implemented with no internal >> reference back to its owning History object it seems pretty harmless, >> a mere holder of values, > > I think a ref

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

On Mon, Jul 13, 2015 at 4:26 PM, Anne van Kesteren wrote: > On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour wrote: >> It is only used as way to group properties (perhaps similar to >> ValidityState?) and to keep History interface clean and stack-like. If that >> is not valuable enough to introduc

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

On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour wrote: > It is only used as way to group properties (perhaps similar to > ValidityState?) and to keep History interface clean and stack-like. If that > is not valuable enough to introduce a new interface then putting these on > the History interface

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

On Sun, Jul 12, 2015 at 1:51 PM Anne van Kesteren wrote: > On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking wrote: > > I think we've already made that assumption given that history.state > > already relies on this. > > Good point. I'm still somewhat skeptical of introducing new objects > just for

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

On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking wrote: > I think we've already made that assumption given that history.state > already relies on this. Good point. I'm still somewhat skeptical of introducing new objects just for the purpose of grouping some properties if they don't serve a purpose

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

On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren wrote: > On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote: >> Minor bikeshed: >> I have put scrollRestoration on history.options instead of directly history >> itself in order to use history.options as an interface to contain any other >>

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

On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour wrote: > On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking wrote: >> >> FWIW I still prefer an API like >> >> history.scrollRestoration = 'manual'; >> >> The main reason is that it seems to me that pushState/replaceState has >> a largely orthogonal set

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

On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote: > Minor bikeshed: > I have put scrollRestoration on history.options instead of directly history > itself in order to use history.options as an interface to contain any other > restoration related attributes which have similar semantics (e.g.,

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

On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking wrote: > FWIW I still prefer an API like > > history.scrollRestoration = 'manual'; > > The main reason is that it seems to me that pushState/replaceState has > a largely orthogonal set of use cases that it tries to address from > scroll restoration. S

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

FWIW I still prefer an API like history.scrollRestoration = 'manual'; The main reason is that it seems to me that pushState/replaceState has a largely orthogonal set of use cases that it tries to address from scroll restoration. So I suspect that grouping the two together will create awkwardness

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

On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour wrote: > Do you have a preference one way or another for either of the above APIs? Not really. The fact that history and navigation is not really cross-browser makes me a bit wary about extending it further, since we obviously don't really understan

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

On Wed, May 20, 2015 at 11:00 AM Majid Valipour wrote: > > It will be great if we could make progress on getting a consensus on the > API so that we can actually ship this feature. I think we have narrowed it > down to two main options: > > 1- Setting scroll options using history.{push, replace}S

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

Hi all, I wanted to give you an update on the progress. I have implemented this in Chromium in version 44 behind a runtime enabled experimental feature flag . Here are the relevant IDL files for the API: - StateOptions.idl

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

On Thu, Apr 9, 2015 at 3:05 PM Ian Hickson wrote: > > 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 "willRestoreSc

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

On Tue, Apr 28, 2015 at 3:24 PM Jonas Sicking wrote: > On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour > wrote: > > On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking wrote: > >> > >> Jumping in at the end here. > >> > >> As I've said before, I like the general idea of giving pages more > >> control

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

On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour wrote: > On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking wrote: >> >> Jumping in at the end here. >> >> As I've said before, I like the general idea of giving pages more >> control over scroll restoration, but I don't think we should tie this >> to pu

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

Jumping in at the end here. As I've said before, I like the general idea of giving pages more control over scroll restoration, but I don't think we should tie this to pushState()/replaceState()/onscroll. My proposal is instead that we add an API like history.restoreScroll = boolean; This proper

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

On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson wrote: > On Sun, 12 Apr 2015, Anne van Kesteren wrote: > > On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson wrote: > > > I'd strongly recommend against adding new methods. It'll mean we now > > > have two different ways to do the same thing, which means mor

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

On Sun, 12 Apr 2015, Anne van Kesteren wrote: > On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson wrote: > > 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 confusi

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

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

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

On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson wrote: > 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. If t

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 opt

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 (ofte

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

Hi Nils, I am not advocating for breaking the back button but in fact the opposite. The idea is to allow single-page applications that are creating new history entries and for whom the automatic scroll restoration is *broken* (because the page is being re-creating on popstate event) to be able to

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

Majid Valipour writes: > 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

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

On Thu, Mar 26, 2015 at 11:12 AM Anne van Kesteren wrote: > On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour > wrote: > > That is fair. Assuming clear documentation helps alleviate potential > > confusion I am fine with deprecation route. I suppose the purpose of the > > spec is to not only docum

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 … > Yeah... also consider navigating back and forth between two different > sites/apps, without navigating within

[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. Sorry about duplication :(. -- Forwarded message - From: Majid Valipour Date: Wed, Mar 25, 2015 at 8:22 PM On Wed, Mar 25, 2015 at 4:32 PM Jonas Sicking wrote: > Is this re

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

On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour wrote: > That is fair. Assuming clear documentation helps alleviate potential > confusion I am fine with deprecation route. I suppose the purpose of the > spec is to not only document the current recommended behavior but also > capture any legacy one

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

On Wed, 25 Mar 2015 21:31:51 +0100, 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 woul

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

On Thu, Mar 26, 2015 at 1:22 AM, Majid Valipour wrote: > My only concern is to make sure that these new methods replace > history.pushState() and history.replaceState() in the spec. Otherwise I feel > the benefits of a cleaner API is not worth the additional confusion of > having different methods

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

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.

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

On 25/03/2015 14:54 , 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

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

On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour wrote: > 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 S

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

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

# 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 th