- From: Mike Wilson <mikewse@hotmail.com>
- Date: Sat, 22 Aug 2009 17:02:36 +0200
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>
Received on Saturday, 22 August 2009 08:02:36 UTC