- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Thu, 24 Mar 2011 19:29:52 -0400
- To: Ashok Malhotra <ashok.malhotra@oracle.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>
Ashok: on the phone today, you asked for information on what sorts of URI changes could be made, without causing a document retrieval, using the HTML5 pushState() or replaceState methods. The specification is available at [1]. From that: ------------------------------ The pushState(data, title, url) method adds a state object entry to the history. The replaceState(data, title, url) method updates the state object, title, and optionally the URL of the current entry in the history. When either of these methods is invoked, the user agent must run the following steps: 1. Let clone data be a structured clone of the specified data. If this throws an exception, then rethrow that exception and abort these steps. 2. If a third argument is specified, run these substeps: 1.Resolve the value of the third argument, relative to the entry script's base URL. 2. If that fails, raise a SECURITY_ERR exception and abort these steps. 3. Compare the resulting absolute URL to the document's address. If any part of these two URLs differ other than the <path>, <query>, and <fragment> components, then raise a SECURITY_ERR exception and abort these steps. ------------------------------ I believe that step 2.3 is what you're looking for. You can change the <path>, <query> and/or <fragment> using these APIs, without causing a retrieval from the server. Changing any other part of the URI is not allowed. As you know, I believe that with these APIs widely deployed, the major reason for using # for client-side state maniupalation goes away, and some of the advantages of avoiding it (by using <path> and/or <query>) seem to me compelling. Noah [1] http://dev.w3.org/html5/spec/history.html#dom-history-pushstate
Received on Thursday, 24 March 2011 23:30:23 UTC