[prev in list] [next in list] [prev in thread] [next in thread]
List: whatwg
Subject: Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
From: Jonas Sicking <jonas () sicking ! cc>
Date: 2015-06-29 21:19:52
Message-ID: CA+c2ei_cXK0wMkefZ8Aj9z=qq5u96NNVZc0_pySOivxSCDEPhA () mail ! gmail ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic