type: utility

release: 0.0

priority: very low

status: in planning

documentation: N/A

demo: N/A

1 - Description:

Utility for managing browser history. Should use HTML5 history API (pushState) and fall back to changing location.hash with custom hashchange events where necessary.

Some references:

• Mozilla History spec
• History.js provides cross-framework and graceful degradation for the HTML5 History API
• YUI3 History, source for html5 implementation - so far no demo available for the pushstate implementation
• jQuery Mobile uses hash changes for history management, has ticket/branch for pushState support 
• jQuery BBQ plugin provides hash based history, part of that is used by jQuery Mobile 
• Twitter doesn't use pushstate for their new interface (using hashchange instead), due to a Webkit bug that is now fixed.  

To test for HTML5 history support, the most common test, e.g. used by Modernizr, is !!history.pushState. That is a start, but doesn't help when the implementation is as broken as it seems to be in Mobile Safari/iOS 4.2.x. A potential test, used in jQuery Mobile to detect hash change support, would try to push state once, save the location.pathname, push again, then check if there is a difference. If so, support is there, go back twice to clean up. It breaks forward history, but only once if the test result is stored and reused.

Too bad that that doesn't work for Mobile Safari, which updates location.pathname, but not the actual URL displayed in the browser (which gets loaded on reload). Could be related to this WebKit bug.

Mobile Safari also doesn't update the back/forward buttons properly. When the back button works after using pushState (not very reliable), a tap on back doesn't enable the forward button.

Checking for history.length, then using pushState, then checking history.length again and comparing the result could be a way to check if history.pushState is actually supported. But it looks like doing that check on pageload provides no useful result, as even if Chrome, with a proper pushState implementation present, the history.length doesn't change. Delaying the check produces different lengths, even on iOS 4.2.x.

While the native browser buttons are unreliable and either don't work at all or don't update the address bar, history.back() and history.forward() work fine, trigger the right popstate event and update the address bar to the correct value.

Note on the second argument to history.pushState, title: Both WebKit and Mozilla ignore the argument and do nothing with it. See Mozilla bug and WebKit bug.

2 - Visual Design:

No visuals necessary.

3 - Functional Specifications/Requirements:

(Detailed description of how the script will be structured: defaults, options, architecture, extensibility, etc.)

4 - Markup & Style:

No markup necessary. 

5 - Latest version of plugin:

(Link to the latest version in the jQuery UI trunk here)

6 - Open issues being discussed

(Use this area to place things that we're hashing out like features and options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)