W3C home > Mailing lists > Public > public-webapi@w3.org > November 2005

(wrong string) €“ saving document state by document.save()

From: Jim Ley <jim.ley@gmail.com>
Date: Tue, 22 Nov 2005 16:22:28 +0000
Message-ID: <851c8d310511220822m18d259fice3f90c12fad5730@mail.gmail.com>
To: public-webapi@w3.org

On 11/22/05, Anne van Kesteren <annevk@opera.com> wrote:
> On Mon, 21 Nov 2005 20:03:40 +0100, Karl Pongratz <karlhp@karlhp.com>
> wrote:
> > There is yet the question if pushState() requires to execute JavaScript
> > to display the altered document.
> I'm not sure I understand. Could you elaborate?

The problem I have with pushState/popState is that it's only solving
part of the problem, the back/forward navigation.   It's not solving
the going away and coming back on another machine, or the emailing a
link to someone, and it requires scripting to sync the local state
with what they want it to be, and local storage to persist the
information, shared bookmarks and shared history no longer work.

The simple proposal in the start of this thread did meet that needs,
what it says is the state I'm in now, is equivalent to the state you
get when you request this URI, this requires no local storage, and the
request can be copied to other users.

Of course the 2 use cases are actually very different, and it's not
surprising they end up with very different solutions - the simple
"this uri is equivalent to the current view" of the initial proposal
is extremely powerful for the majority of non-web-application systems.

Where the web application wants to provide back-forwards within the
current instance of the application, then local javascript state with
pushState/popState more of the type of solution you need (although not
necessarily the solution I would favour).


Received on Tuesday, 22 November 2005 16:23:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:19 UTC