[whatwg] Global Script proposal.

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.

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 socks.

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.

:DG<

Received on Monday, 7 September 2009 14:30:42 UTC