W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 29 Jun 2015 14:19:52 -0700
Message-ID: <CA+c2ei_cXK0wMkefZ8Aj9z=qq5u96NNVZc0_pySOivxSCDEPhA@mail.gmail.com>
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>
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

On Mon, Jun 29, 2015 at 8:14 AM, Majid Valipour <majidvp@chromium.org> wrote:
> On Wed, May 20, 2015 at 11:00 AM Majid Valipour <majidvp@chromium.org>
> 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}State. This is what
>> we have implemented in chrome (see IDLs above).
>>      history.replaceState(history.state, '','', {scrollRestoration:
>> 'manual'})
>> 2- Setting scroll options directly on history object. This is what Jonas
>> has proposed. Per our earlier discussions in this thread it should be
>> possible to define the semantics such that we get per-entry control.
>>     history.options.scrollRestoration = 'manual'
>> Both  are equally powerful with #1 being better for complex situations
>> where different entries may need to have different scroll restoration
>> behaviour  and #2 being better for simpler case where the application wants
>> the same scroll restoration for all its entries. As an experiment, I have
>> created a small script that implements #2 on top of #1.
>> Jonas prefers #2. I am partial to #1. Spec editors (Anne, Ian, Simon,
>> Robin):
>> Do you have a preference here?
> Anne, Ian, Simon, Robin,
> Do you have a preference one way or another for either of the above APIs?
> I have a git repo where I have spec'd the first option (as implemented in
> Chromium) and am tracking issues against it. Unless there is a strong
> preference against #1, I feel it is reasonable to try to ship it.
> Majid
Received on Monday, 29 June 2015 21:20:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC