On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote: > On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <[email protected]> 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. 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. Regards, MAciej
