[whatwg] Global Script proposal.
ian at hixie.ch
Mon Sep 14 04:41:36 PDT 2009
On Mon, 7 Sep 2009, Dimitri Glazkov wrote:
> On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson<ian at hixie.ch> wrote:
> >> Another case is an application that uses navigation from page to page
> >> using menu or some site navigation mechanism. Global Script Context
> >> could keep the application state so it doesn't have to be
> >> round-tripped via server in a cookie or URL.
> > You can keep the state using sessionStorage or localStorage, or you
> > can use pushState() instead of actual navigation.
> First off, sessionStorage and localStorage are not anywhere close to
> being useful if you're dealing with the actual DOM objects. The JS code
> that would freeze-dry them and bring back to life will make the whole
> exercise cost-prohibitive.
Indeed. I don't see why you would want to be keeping nodes alive while
navigating to entirely new documents though.
> But more to the point, I think globalScript is a good replacement for
> the pushState additions to the History spec. I've been reading up on the
> spec an the comments made about pushState and I am becoming somewhat
> convinced that pushState is confusing, hard to get right, and full of
> fail. You should simply look at the motivation behind building JS-based
> history state managers -- it all becomes fairly clear.
> The best analogy I can muster is this: pushHistory is like creating
> Rhoad's-like kinetic machines for moving furniture around the house in
> an effort to keep the tenant standing still. Whereas globalScript
> proposes to just let the poor slob to walk to the chest to get the damn
> My big issue with pushHistory is that it messes with the nature of the
> Web: a URL is a resource you request from the server. Not something you
> arrive to via clever sleight of hand in a user agent. So, you've managed
> to pushState your way to a.com/some/path/10/clicks/from/the/home/page.
> Now the user bookmarks it. What are you going to do know? Intuitively,
> it feels like we should be improving the user agent to eliminate the
> need for mucking with history, not providing more tools to encourage it.
The only criticism of substance in the above -- that pushState() lets you
change the URL of the current page when you change the page dynamically --
is pretty much the entire point of the feature, and I don't understand why
it's bad. I certainly don't want to require that every pan on Google Maps
require a new page load.
On Tue, 8 Sep 2009, Anne van Kesteren wrote:
> within a single domain, be in control of what is displayed and without
> security issues and all that'd be rather cool and also solve the issue.
This seems substantially less preferable, performance-wise, than having a
single Document and script, using pushState().
The pushState() model is basically fixing the AJAX model to work right; it
seems like a good thing to me.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg