Great article. Recommends building on conventional hash-less URIs and using progressive enhancement e.g onClick handlers to implement hash-bang URIs.
Three particularly interesting ideas:
* sites should support the _escaped_fragment_ query parameter, the result of which should be a redirection to the appropriate hashless URI
* if you’re serving large amounts of document-oriented content through hash-bang URIs, consider swapping things around and having hashless URIs for the content that then transclude in the large headers, footers and side bars that form the static part of your site [can't envisage how this would work]
* "I suspect we might find a third class of service arise: trusted third-party proxies using headless browsers to construct static versions of pages without storing either data or application logic"
Well... I don't see how ignoring IE would change that much for those visitors, if the pushState is used only as progressive enhancement. I probably wouldn't even display a message to them.
On the other hand, if dynamic changes are essential, we'll have to support hashbangs too.
I look forward to the day when this API is supported by all the major browsers. In the meantime, the article suggests a sensible-looking set of steps for gracefully degrading.(and using hash-bang URLs as little as you can).
The frustrating thing about all this is that, until HTML 5, there hasn't been any way of causing the contents of the URL bar to change to an arbitrary URL within your site without reloading the page.
I don't think there's any particular reason to use a hash-bang style to get the same functionality - /content/uuid could be parsed as easily.
maybe I missed something by skimming the article... I was initially hoping to read something about using one way functions to derive UUIDs from document content :/
Three particularly interesting ideas:
* sites should support the _escaped_fragment_ query parameter, the result of which should be a redirection to the appropriate hashless URI
* if you’re serving large amounts of document-oriented content through hash-bang URIs, consider swapping things around and having hashless URIs for the content that then transclude in the large headers, footers and side bars that form the static part of your site [can't envisage how this would work]
* "I suspect we might find a third class of service arise: trusted third-party proxies using headless browsers to construct static versions of pages without storing either data or application logic"