- From: Bill Sempf <bill@pointweb.net>
- Date: Tue, 22 Nov 2005 21:00:25 -0500
- To: <public-webapi@w3.org>
- Message-ID: <SBS-TMCIH71yEXUIEAO00000016@tmci-sbs.tmci.net>
-----Original Message----- From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Jim Ley > 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. I would like to further on Jim's comments. We have two scenarios here. Mr. Heaton mentioned that the web doesn't go back and forth, but in all different directions. We have discussed Gmail and Flicker. We have discussed search engine compatibility, and mailing or bookmarking links. Be there are two different problems that need to be solved. Mr. Eriksen puts it very well: "The concept of browsing the web and using web applications are very different." The real 'semantic web' - tagged information for retrieval - needs to be linear, and accept all of the things that the current Web paradigm provides, like stable URIs and use of the back button. 'Web 2.0' - web applications like Google Maps or Outlook Web Mail - frankly don't. Load up MapPoint - do you see a back button? How about in Thunderbird? The paradigms are different. This points to two different solutions. Browsable sites might just not be as well suited for the Ajax model because of the open nature of the web. Even if there is a URL parameter added to pushState, the browsers will have to constantly be asking "should I allow this to be pushed to the stack if it is a different domain?" and like that. Web applications, however, are well suited to the Ajax model, and the Back button can be expected to move the user to the previous section of the application, or out of it altogether - it is already semi-accepted behavior. So I submit that the addition of a tag or DOM method to handle history in Ajax is a non-issue, and Mr. Heaton is correct, "Maybe we just need to be smart about the way we design and develop our applications, and a set of best practices perhaps." Thoughts? S
Received on Wednesday, 23 November 2005 02:35:34 UTC