The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
So what's new? For starters, the beefed up History API will let you add and modify history entries using the pushState() and replaceState() methods. The pushState() method, which creates a history entry, accepts three parameters: a state object, a title, and a URL. What are these parameters, you ask? Mike Robinson provides with condensed versions of Mozilla's paragraph-long definitions:
- data: Some structured data, such as settings or content, assigned to the history item.
- title: The name of the item in the history drop-down shown by the browser’s back and forward buttons. (Note: this is not currently supported by any major browsers.)
- url (optional): The URL to this state that should be displayed in the address bar.
replaceState() modifes an entry rather than creating one. If that seems a little confusing, the IEBlog summarizes it this way:
If you’re not already familiar with the HTML5 History APIs, think of pushState as being the dynamic equivalent of navigating to another page. Similarly, replaceState is much like location.replace. The difference is these APIs leave the current page intact when updating the session history by storing states instead of pages. Both pushState and replaceState take three parameters: a data object, a title, and an optional URL.
Grack.com also provides an interesting example of how the additions to the History API can be abused for fun and chaos. The fun part? By changing the contents of the history state, you can do something like create a scrolling marquee in the address bar to grab people's attention. The chaos? As usual, this is a result of browser compatibility issues:
It turns out that some browsers weren’t designed to handle this level of awesomeness. Trying to navigate away from a page that turns this on can be tricky. Firefox 4 works well: just type something into the location bar and the bar stop animating. WebKit-based browsers are a different story.
On Safari, every replaceState call removes what you’ve typed into the location bar and replaces it with the new data. This makes it impossible to navigate away by typing something else into the bar. Clicking one of your bookmarks will take you away from the page, however.
On Chrome, the same thing happens, but it’s even worse. Every replaceState call not only wipes out the location bar, but it cancels navigate events too. Clicking on bookmarks has no effect. The only recourse is to close the tab at this point.
For a less fun but equally useful example of the new tools in action, check out the demo at HTML5 Demos.
Scrolling marquees in the address bar and talk about boosting performance and improving navigation efficiency are great, but I'd like to know what the additions to the History API mean to you. How do you plan to implement the changes in your projects, or do you plan to implement them at all?