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

[Brady Eidson]

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 <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).
> 
> 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
>