[whatwg] history.back()

On Fri, Jan 22, 2010 at 1:13 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote:
>
> On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> I asked Brady (the Safari/WebKit engineer who implemented pushState())
>> about this, and he told me he found that in the pushState case it sometimes
>> made things easier from the authoring side for history.back() to be
>> synchronous. But I don't have the details.
>
>
> Brady and I have been discussing this too.  I'm not convinced that
> synchronous history.back() makes things significantly better for content
> authors.  Indeed, I'm concerned that it makes things worse.
>
> Here's what I mean:  If history.go() sometimes results in the history
> traversal completing synchronously (hash change) and sometimes not
> (navigation required), then there is a loss of predictability for the
> programmer.  They have to deal with event dispatch sometimes happening in a
> re-entrant manner, but other times not.  A consistent model seems better to
> me.
>
>
> I don't really have strong feelings about this at present. But I think the
> most important deciding factor should be what is the best behavior for
> authors. It seems like the implementation details are something that can be
> worked out either way, so implementation challenge should be a tiebreaker at
> best.
>

That's fair, and I completely agree in principle.

The reality of the situation of course is that implementation challenges
matter a lot.  If implementation costs are high and the benefits of
modifying the code are relatively low, then we are likely to end up with
browsers having inconsistent behavior for some time.



> You are correct that consistency is good. However, whether a navigation to
> a different document is asynchronous can barely be observed - it's not like
> any code from the current document will run after the navigation anyway. For
> within-document navigations, I could imagine synchronous behavior might make
> some things easier to code - you could call history.back() to pop the state
> stack, and your code running afterwards could assume you'd successfully
> traversed to the new state. On the other hand, I could also imagine it's
> harder. And history.back is probably not used all that much in modern Web
> apps anyway. That's why I don't have a very good picture of which approach
> is better.
>

Isn't this what popstate and hashchange notifications are for?  Afterall,
the user could also press the back button, and the developer would probably
be concerned with that case too.

-Darin



>
> Regards,
> MAciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100122/8586fcea/attachment.htm>

Received on Friday, 22 January 2010 09:57:51 UTC