- From: Sjoerd Visscher <sjoerd@w3future.com>
- Date: Mon, 18 Jul 2005 12:36:13 +0200
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/
Received on Monday, 18 July 2005 03:36:13 UTC