darin at chromium.org
Fri Jan 22 09:57:51 PST 2010
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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg