- From: Majid Valipour <majidvp@chromium.org>
- Date: Fri, 10 Jul 2015 20:54:15 +0000
- To: Jonas Sicking <jonas@sicking.cc>, 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 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 <http://majido.github.io/scroll-restoration-proposal/history-based-api.html> 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). Majid [1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Apr/0123.html
Received on Friday, 10 July 2015 20:54:53 UTC