Sorry to self-reply. I just want to make four targetted points: -As is, the language specifying clearState() has gapping holes that prevent us from agreeing on what it is we're implementing.
-I personally think the intention of clearState() is useful and not a bad idea, and that a more fine grained "truncate" is something that can easily be added later with enough demand. -I personally think expanding the API to allow a script to remove history entries its Document object didn't create is a bad idea, and would object to expanding this power beyond the Document object to "same origin" based control. -I think that if we can't reach a consensus fairly soon, we should dump clearState() and revisit it later. The API is certainly very useful with just pushState() and replaceState(). ~Brady On Nov 12, 2009, at 4:54 PM, Brady Eidson wrote: > > On Nov 12, 2009, at 4:39 PM, Jonas Sicking wrote: > >> 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). > > An AJAX heavy site already violates your user preconceptions about > back/forward. One of the whole points of this API is to allow such AJAX > heavy sites to play *better* with back/forward. >> >> 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. > > Remember this API extends the lifetime of a single Document object. If the > checkout-wizard is its own document, then its invocation of "clearState()" > could not nuke any more history than it owned. > >> In order to satisfy this use case I'd imagine you'd need the ability >> to remove a precise range of session history entries. > > I disagree, see above. > >> 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>. > > This already plays well with the "A Document object is the only thing that > gets to manage its own state entries" model. If you clicked this link > sometime during the middle of your checkout process, then completed the > checkout and clearState() was called, your fragment entry would be removed > along with the others for the document. > > I know you're arguing "as a user, I don't want my back history messed with." > But the whole point of this API is to give scripts the ability to mess with a > very limited, very controlled subset of the back/forward history. Having > that as a goal but then neutering the scripts ability to take advantage seem > somewhat contrary here. > > ~Brady >> >> / Jonas >
