- 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