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