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

Jumping in at the end here.

As I've said before, I like the general idea of giving pages more
control over scroll restoration, but I don't think we should tie this
to pushState()/replaceState()/onscroll.

My proposal is instead that we add an API like

history.restoreScroll = boolean;

This property would default to true. Whenever pushState() is called,
or the user navigates away from the current page, for example by
clicking a <a href=...> the value of history.restoreScroll is copied
into the session-history-entry data that the browser keeps internally.
As soon as the new session-history-entry is created, restoreScroll is
set to true again.

Additionally we could enable passing a boolean to pushState(), and
this value would be used as the new initial value for restoreScroll.
So something like pushState({ url: myURL, restoreScroll: false });.
This would simply be syntax sugar for |pushState("", "", myURL);
history.restoreScroll = false;|.

I think that's all that's needed.

In order to make it easier for pages we could also expose a
history.restoredScrollPosition which is a readonly property which the
UA writes to any time it restores a session history entry, which is
the scroll position that it would have restored scrolling to if the
page hadn't disabled scroll restoration for the given session history
entry.

This is isn't strictly needed though since the page can simply use
sessionStorage and update the scroll position in a onscroll handler.
But history.restoredScrollPosition would reduce boilerplate code.
Also, using sessionStorage is somewhat complex to do correctly given
that the user might visit the same URL multiple times in the same
session.

(As an aside, it would be great if we had something like
sessionStorage, but specific for a given page. Right now
sessionStorage seems to make it very hard to store page specific state
unless I'm missing something obvious?)

/ Jonas


On Thu, Apr 23, 2015 at 3:25 PM, Majid Valipour <majidvp@chromium.org> wrote:
> On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson <ian@hixie.ch> wrote:
>
>> On Sun, 12 Apr 2015, Anne van Kesteren wrote:
>> > On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson <ian@hixie.ch> wrote:
>> > > I'd strongly recommend against adding new methods. It'll mean we now
>> > > have two different ways to do the same thing, which means more bugs,
>> > > which means less interoperability, more confusing behaviour for
>> > > authors, more to document, etc.
>> >
>> > If the existing method didn't have the flaw with the title argument I
>> > wouldn't have suggested it. Also, since they both built upon the same
>> > primitive I think we'd be okay in the bugs and interop department.
>>
>> You are more optimistic than I. In any case, I strongly recommend against
>> such redundancy.
>>
>>
>> On Wed, 15 Apr 2015, Majid Valipour wrote:
>> >
>> > Actually URL is optional in current spec and it defaults to current URL.
>> > Why is this suboptimal?
>>
>> Because it means you can't bookmark the state or share the state,
>> reloading the page loses the state, etc.
>>
>>
>> > In anycase If making URL required is a goal then it is best done by
>> > introducing a new method to avoid breaking compatibility.
>>
>> Why is that better?
>>
>> Changing the optional third argument to become required on the existing
> methods will break any call site that is not passing it. This is a non
> trivial compatibility issue which does not exists with a new method.
>
>
>>
>> > I personally find a dictionary with only optional members which have
>> > appropriate defaults to be very convenient.
>>
>> I don't disagree... for new APIs. But when we already have an existing
>> API, maintaining consistency and lack of redundancy IMHO trumps pretty
>> much everything else, if you want the end result to be usable.
>>
>> A lot of the pain with using the Web's APIs is the inconsistency and
>> redundancy that is rampant throughout.
>>
>
> I understand the desire for maintaining consistency and reducing
> redundancy. On the other hand a new API will allow fixing some existing
> warts. I can see merits in both arguments. I am happy to defer the API
> decision to spec editors.
>
> I created the W3C bug for this proposal:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28553
>
> Majid

Received on Tuesday, 28 April 2015 01:54:43 UTC