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

On Thu, Mar 26, 2015 at 11:12 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Mar 26, 2015 at 3:57 PM, Majid Valipour <majidvp@google.com>
> wrote:
> > That is fair. Assuming clear documentation helps alleviate potential
> > confusion I am fine with deprecation route. I suppose the purpose of the
> > spec is to not only document the current recommended behavior but also
> > capture any legacy ones until it is fully removed.
>
> Yeah, we don't want any new user agents such as Spartan or Servo run
> into pages that only work with history.replaceState(). They'd then
> have to reverse engineer it rather than simply reading a specification
> which is not nice.
>

** Re-sending with my member email address. Apologies for duplication.

I have updated the proposal document
<https://docs.google.com/a/chromium.org/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM>
based
on feedback around API design:

partial interface History {

  void push(in optional HistoryEntry entry);

  void replace(in optional HistoryEntry entry);

}


dictionary HistoryEntry {

  any state,

  DOMString title,

  DOMString url,

  Boolean restoreScroll = true,

}


Now instead of adding a fourth optional parameter to existing methods it
introduces new methods (push, replace) which accept dictionaries.


Although not required I think it improves API completeness if the following
two modifications are also included:


   1. Add a readonly 'history.current' attribute which returns the current
   entry in joint history session analogous to how history.state behaves now.
   This allows developers to access title, url, and restoreScroll of the
   current history entry.
   2. Add a new attribute 'entry' of type HistoryEntry to PopStateEvent in
   addition to 'state'. This one may actually be unnecessary if we have
   history.current and knowing that there can only ever be one PopState event
   in flight.

Thanks

Received on Tuesday, 7 April 2015 14:37:09 UTC