[whatwg] history state object api issues
Mike Wilson
mikewse at hotmail.com
Wed Dec 23 07:52:25 PST 2009
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
More information about the whatwg
mailing list