<div class="gmail_quote">On Fri, Jan 22, 2010 at 1:13 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote:</div><br></div><blockquote type="cite"><div class="gmail_quote"><div class="im">On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote: </div>
<div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<br>
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.</blockquote>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

</div></div></blockquote></div><br><div>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.</div>
</div></blockquote><div><br></div><div>That's fair, and I completely agree in principle.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>-Darin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>Regards,</div>
<div>MAciej</div><font color="#888888"><div><br></div></font></div></blockquote></div><br>