- From: Kris Zyp <kris@sitepen.com>
- Date: Fri, 11 Feb 2011 07:13:27 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: WebApps WG <public-webapps@w3.org>
On 2/11/2011 6:55 AM, Anne van Kesteren wrote: > On Fri, 11 Feb 2011 14:48:26 +0100, Kris Zyp <kris@sitepen.com> wrote: >> Increasingly, web applications are centered around JSON-based content, >> and utilize JavaScript to render JSON to HTML. Such applications >> (sometimes called single page applications) frequently employ changes to >> the hash portion of the current URL to provide back/forward navigation >> and bookmarkability. However, this is largely viewed as an awkward hack, >> and is notoriously problematic for search engines (Google has a hash to >> query string conversion convention, which is also highly inelegant). We >> need support for first class navigation of JSON documents, while still >> leveraging HTML rendering technology. > > What is wrong with the more generically applicable history.pushState()? > > This proposal is about creating a proper causal link between URLs, that return JSON representations, and the correct associated rendering. The pushState proposal doesn't create handling for JSON data, it just aliases URLs once a page is loaded. The pushState function adds URL aliases as JS-handled history entries, but this does nothing to help the situation if I send someone a link to a state that doesn't have that URL aliased in the browser. By allowing the page entry point to be the underlying JSON data, we have a solid and sound starting point for building a view, without having to create intermediate HTML pages that serve no purpose but to load the associated JSON and try to recreate history entries so it can hang on to the DOM. The pushState API is definitely useful, but this proposal is about starting in the right place, and if the core content/data of your application is JSON, that's the correct entry point, using pushState to emulate that just devolves to a hack. Thanks, Kris
Received on Friday, 11 February 2011 14:14:27 UTC