HTML5 pushState rules for URI changes

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