[whatwg] HTML5 History Management

[Ian Hickson]

On Wed, 29 Jul 2009, Nathan Hammond wrote:
> 
> Clarifications
> 1. window.history.pushState({}, "Title", "/path/to/new/file.html?
> s=newvalue#newhash") replaces the current document object with the one
> specified by the new URL. It then causes the event popstate to fire
> immediately after the load event, correct?

Actually that doesn't replace the Document object, only the current 
address. It doesn't cause any events to fire.


> 2. window.history.pushState({}, "Title", "#newhash") creates a new history
> state object with the specified data object, the specified title, the same
> document object, and a location object that replaces the existing hash with
> "#newhash", correct?

More or less, yes. It's the same as the previous call, just with less of 
the URL being changed.


> Possible Action Items
> 1. Specify the order in which history related events are triggered.
> 
> In what order would one expect the events triggered by
> window.history.pushState({}, "Title", "#newhash")?

No events are triggered by doing that.

Some events are triggered when moving back and forth in the history, which 
I will assume is to what you are referring here:

> There are two events of interest: popstate, and hashchange.

The order of those events is defined in this algorithm:

   http://www.whatwg.org/specs/web-apps/current-work/#traverse-the-history

Step 5 (as the algorithm stands today) calls this subalgorithm:

   http://www.whatwg.org/specs/web-apps/current-work/#activating-state-object-entries

...which fires 'popstate' (if appropriate), and then step 6 fires 
'hashchange' (if appropriate).


> 2. Specify a method to allow access to the history stack. (At least 
> readable within the context of same-origin, possibly mutable.)
> 
> This would allow for understanding on the client side of a user's path 
> through the site, even after navigating away from the page. If this is 
> not implemented the absolute first thing I will be implementing is a 
> method to track this information, a rather large duplication of effort 
> for something that could easily be made available. This would involve a 
> something like currentstate = { _previous: currentstate, title: 
> window.title, newval: true }; plus a form-based storage mechanism to 
> repopulate state in case the user exits on a page which they manually 
> changed the hash to get to (which would not have access to the data 
> object upon revisiting later since there wouldn't be one stored with 
> that history state).
> 
> I'm aware of the privacy ramifications, but at the same time, I'm going 
> to be exposing those exact same concerns with the above method.

It turns out to be quite complex to expose this in the API currently, 
because the History object exposes a mix of all the various frames at 
once, and you can get to the History object of cross-origin frames, and 
there's some other legacy baggage here also (e.g. history.length).

Since it's not entirely clear what the use case is, and since you can do 
it to some extent already using onload, onhashchange, and onpopstate, I'd 
rather just let authors reimplement this themselves at this point, and 
maybe revisit this in a future version.


> 3. Specify a method to modify the current history state without adding a 
> new history point.

Assuming you don't mind causing the page to reload, you can use 
history.replace(). I'm not sure what it would mean to replace the history 
state without changing the Document or anything, though.


> This would alleviate the need for the (incredibly brittle) form-based 
> storage mechanism I describe above.

Can you use sessionStorage for this?


> 4. Specify additional properties on the hashchange event.
> 
> Lots of possible useful information with the number one most important 
> being the new hash that triggered the event to prevent race conditions 
> reading window.location.hash. Other fun things that are a bit more pie 
> in the sky: the previous hash and knowledge of how it was triggered 
> (manually? pushState? window.location.hash = ? window.location.href = 
> ?).

What are the use cases?


On Thu, 30 Jul 2009, Nathan Hammond wrote:
>
> Thanks for the reply, forgive my disbelief on Clarification 1. :) If I'm 
> completely with you, that is entirely unexpected on my part (and I've 
> read this part of the spec a few times). Is this to imply that, no 
> matter what the arguments to pushState(), if the path is relative to the 
> current URL there will be no request for a new document and no 
> user-agent initiated network activity?

Right.


> Also, that would imply that the popstate only fires when you're 
> navigating through history. Is that correct?

Yes.


On Thu, 30 Jul 2009, Sebastian Markbåge wrote:
> 
> That is my interpretation too. But I think it's a little unclear whether 
> that means that the UA should update any Location fields in the UI. I 
> understand that this may be optional or outside the scope, but I think 
> that it should still be mentioned.

The spec defines two URIs for each Document, the "document's address" and 
the "document's current address". I've added a note saying that most UAs 
expose the latter in the UI.


On Thu, 30 Jul 2009, Nathan Hammond wrote:
> 
> Possible Action Items
> 1. Clarify how the user agent uses the calculated location value from the
> pushState description step 2 in section 6.10.2 in terms of being reflected in
> the Location object.
> 
> It is my opinion that this URL should be reflected in the Location 
> value. This would imply that it would be reflected in the location bar 
> of user agents that have this as part of their UI. It seems that the 
> place to include this clarification would be the pushState description 
> step 5 in section 6.10.2

This is defined by virtue of the Location object being defined in terms of 
"their document's current address", and pushState()'s step 5 saying "If 
the third argument is present, set the document's current address to the 
absolute URL that was found earlier in this algorithm".


> 2. Clarify that pushState() does not cause navigation.
> 
> I read the spec quite a few times and still got this wrong, apparently. 
> Making this completely clear would not hurt.

Could you elaborate on what led you to this conclusion?

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'