- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 12 Jul 2015 10:44:33 -0700
- To: Majid Valipour <majidvp@chromium.org>
- Cc: WHATWG <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Olli Pettay <olli@pettay.fi>, Rick Byers <rbyers@chromium.org>
On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour <majidvp@chromium.org> wrote: > On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking <jonas@sicking.cc> 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. So I suspect that grouping the two together will >> create awkwardness in the API in the future. >> >> But I don't have time to chase this issue. >> >> / Jonas >> > Jonas, > > After some offline discussion with Rick, we have decided to converge to your > preferred API. I hope this addresses your concern about potential future > awkwardness and help make adoption easier. > > I have updated the proposed spec to reflect this change. The semantic of > history.options.scrollRestoration is based on our previous discussion in > this thread [1]. It short, it does not change any previous entries and > navigating across documents resets its value so it only applies to entries > created for the same document. > > 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., recorder > scroll position, scale restoration, recorded scale). Thanks Majid! This sounds great! / Jonas
Received on Sunday, 12 July 2015 17:45:35 UTC