On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beid...@apple.com> wrote: > I think clearState() is a good idea but is just spec'ed poorly. > > Imagine the use case of the checkout procedure at an online merchant. > > There's normally steps like "enter your address," "choose your shipping > method," "enter your CC info," and finally "place your order." It'd be > pretty neat if they used this new API to make it so the user could use the > built-in back/forward buttons to switch between the various steps to update > the information. > > But once the user has finished the "place your order" step and is presented > with an order confirmation, all of the previous steps are irrelevant. The > site would be prudent to clear them all out so the user is under the > impression they can go back and continue to play with the details of their > order. In this case, clearState() fits the bill greatly! > > It is true that what is really being performed is "truncate this part of > history." But we wouldn't to give scripts the ability to control parts of > session history they don't own. And the only way we know which session > history entries are owned by a Document is when this new API is used, where > the same Document object is shared between history entries. > > One might argue that we should give finer grained control - letting a > Document remove some of the history entries it owns but not others. I might > be able to think of a use-case for that, but I don't see it being > tremendously important. It could always be added later if there's demand for > it. > > I think we just need to get the language in shape so the spec is interpreted > the same by everyone and is implementable.
As a user of a site, I'm not really sure that that's what I would like to have happen. I can see wanting to be able to go back to those pages to for example see what information I filled out. In general I'm always annoyed as a user when I can't go back to pages that I've left (it's why I pushed the back-button in the first place). And in any event I don't think clearState provides enough fine grained control to be able to satisfy this use case. I would imagine that in many cases a call to clearState would nuke not just the checkout-wizard, but likely also navigation the happened before that. In order to satisfy this use case I'd imagine you'd need the ability to remove a precise range of session history entries. And be able to do so in a way that doesn't get messed up if the user created additional session history entries by clicking links such as <a href="#sizeinfo">Check size information here before buying</a>. / Jonas
