[whatwg] Do we really need history.clearState()?

[Jonas Sicking]

On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beidson at 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