[whatwg] history state object api issues

[Mike Wilson]

There are still some issues with the pushState feature of 
session history, as I wrote in August [1]. As there was a 
lack of discussion at that time I am raising these issues 
again. Below is a list of naive requirements on the state-
handling parts of the new "client-side" session history 
mechanism, mapped against the current support in the 21 
December 2009 version of editor's draft.

"It should be possible to:"

- specify associated state when programatically creating a 
  new session history entry 
  [supported by spec (pushState)]

- update state for the current session history entry
  [supported by spec (replaceState)]

- get state for current session history entry 
  [partial support by spec (popstate), *1]

- allow for self-contained components to handle own state
  [not supported by spec, *2]

- have a notification event when entering a history entry
  [almost full support in spec (popstate), *3]

- have a notification event when leaving current history 
  entry 
  [not supported by spec, *4]

Notes:
*1: only available in popstate event, not during rest of
    history entry lifetime (getter needed)
*2: all page parts saving state must coordinate with a 
    shared data structure (key/value-store or similar 
    needed)
*3: popstate event not fired for navigation with pushState
    (fire for navigation too needed)
*4: there is no event that fires before upcoming history
    entry is activated (new event needed)

If there is interest, I can put together a pseudo code 
example to illustrate these needs, to aid the discussion 
of solutions.

Best regards
Mike Wilson

[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022211.html