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 <maji...@chromium.org> wrote:
> On Wed, May 20, 2015 at 11:00 AM Majid Valipour <maji...@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

Reply via email to