[whatwg] Proposed changes to the History API

[Mike Wilson]

Justin Lebar wrote:
> Mike Wilson wrote:
> > It would be interesting to see a concrete
> > example on how you intend the dynamics of your solution to
> > work. It would be great if you could outline the different
> > events and method calls used (in order) to save and restore
> > the history state object in the following situations:
> > - doing a "fresh" navigation from page#1 to page#2
> > - going back in history from page#2 to page#1
> 
> Here's one way it could go:
> 
> User was at http://google.com, types
> http://mozilla.com/index.html#1 into address bar.
> * onload
> * stateactivated
> User clicks on link with href "#2"
> * statedeactivated (until this event is complete,
>   document.location.hash == "#1" and the pageStorage object is 
>   for the "#1" state)
> * stateactivated (at the beginning of this event,
>   document.location.hash == "#2" and the pageStorage object is 
>   for the "#2" state)
> User clicks back
> * statedeactivated (for #2)
> * stateactivated (for #1)

Great, this seems to be exactly what I want too. In particular
I note the following differences from the current spec:
- events both when entering and leaving a history entry (I 
  called them hashload and hashunload but I agree it is better 
  to avoid "hash" as we also have state-only history entries)
- the same processing for "fresh" (newly navigated to) history
  entries as for "historical" (navigated back/forward to)
  history entries
- removal of the popstate event and exposing a read/writable 
  state object during the whole history entry "session"

About "stateactivated" naming:
Activated/deactivated is a bit longish. Could
- stateload/stateunload
- stateenter/stateleave
or others be good alternatives?
Is "state" the desired keyword? Or should "history" or others
be considered?
Or something playing on the "pageshow/pagehide" naming?

About "pageStorage" lifetime:
Adding on to your description, assuming we are navigating from 
one page (/a) to another (/b) in history without bfcache, the 
following would be a suitable chain of events:
- /a statedeactivated event
- /a unload event
- /a browser saves form fields, scrollpos, and history state obj
- <browser swaps out /a and loads /b>
- /b browser restores history state obj before any script runs
- /b scripts are executed and form fields and scrollpos are 
     restored while document content is built
- /b load event
- /b stateactivated event

About "pageStorage" naming:
I think "page" makes you think more of Document than of history
entries. Looking at an overview of storage areas, ordered from
large scopes down to fine-grained scopes may spawn some ideas:

  CURRENTLY DISCUSSED:

  Scope               Storage area / identifier
  -----               -------------------------
  user agent          window.localStorage
  browsing context    window.sessionStorage
  document            -
  history entry       window.pageStorage

If anticipating there could be a future storage area per 
Document, naming could be something like this:

  ALTERNATIVE:

  Scope               Storage area / identifier
  -----               -------------------------
  user agent          window.localStorage
  browsing context    window.sessionStorage
  document            document.documentStorage
  history entry       window.history.entryStorage

Best regards
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090822/7ff397ab/attachment.htm>