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

[Jonas Sicking]

On Thu, Nov 12, 2009 at 4:54 PM, Brady Eidson <beidson at apple.com> 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.

The fact that AJAX already breaks how I as a user would like pages to
behave doesn't mean that we should build APIs to allow them to keep
doing so. Like you say, the intent of this API is to make AJAX work
better.

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

But it means that you have to load a new Document object for the
checkout part of your site. I.e. you can't extend the lifetime of the
product page to cover the checkout page as well.

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

I disagree. The goal of this API isn't to allow pages to "mess" with
my history. I think the goal of this API is to allow AJAX pages to
integrate better with the web platform and behave more like normal
pages. I.e. things like bookmarks will work like normal pages, AJAX
pages get the correct referrer (something that is a big deal in many
cases), work like normal pages with the back button, etc.

/ Jonas