[whatwg] Some likeness of DOM Session scope
Sjoerd Visscher
sjoerd at w3future.com
Mon Jul 18 03:36:13 PDT 2005
Ian Hickson wrote:
> I used this idea for the window.history.pushState() idea:
>
> http://whatwg.org/specs/web-apps/current-work/#the-session
>
> Let me know if you have any comments.
>
> It doesn't cover the bookmark case, only the back-forward case, so I don't
> think this removes the need for a cross-page-load and persistent local
> store. You still need something for, e.g. offline applications, and for
> applications whose "sessions" are likely to outlive the actual browsing
> session. For most cases this information might be better dealt with using
> a session cookie and server-stored data, but I can definitely see some
> cases (especially games and "productivity" applications like
> word-processor-like things) that would require local data storage rather
> than wanting to depend on the network.
I think it is great!
Now, what I'd really like to see a solution to the "bookmarking
problem". Well, it's really not a bookmarking problem, because you can
simply do
location = "#...some representation of the state of the page..."
And you can bookmark that. The bigger problem is Google. Google afaik
completely ignores fragment identifiers. So if f.e. the bookmark
location was "http://www.example.com/#salesdep", and everybody is
linking to that location, there are 2 problems with Google:
1. Google doesn't support javascript. But it is impossible for the
server to send a static page of the sales department, because fragment
identifiers are not sent to the server with http requests.
2. Because of the links, Google will add the page to its database, but
it will remove the fragment identifier. So even clients with javascript
support will see the homepage instead of the sales department page, when
they found the page through Google.
So what we need is a way to change the path or the query part of the
location, without getting a page reload. I think it works best (security
etc) to just allow to change the query part. It would probably make the
most sense to make this the second argument to pushState.
In our example we could do
history.pushState(data, "salesdep")
and get http://www.example.com/?salesdep in the address bar.
When Google, or any other non-AJAX client, follows that URL you can let
the server generate a static sales department page. AJAX clients get the
basic site framework, and the client will read the query string and go
to the sales department part.
--
Sjoerd Visscher
http://w3future.com/weblog/
More information about the whatwg
mailing list