Back in November, we announced the first of many API redesigns. In that post, we briefly stated our overall goals:

jQuery UI is undergoing an API redesign which will slim down the size of the API in order to provide a more stable codebase that is easier to learn and use. We’ll be posting the proposed changes over the next few weeks in order to gather feedback from the community. Our goal is to support the old (current) and new (proposed) APIs simultaneously in 1.9 and then remove support for the old APIs in 2.0.

Now it’s three months later and two things are clear: 1) it’s taking more than a few weeks to post all of the proposed changes; and 2) we didn’t give enough information about the planned changes and the reasoning behind them.

The Past

When jQuery UI was first created, it was a combination of new and existing plugins. Pulling in existing, popular plugins was beneficial for everyone involved: jQuery UI was released earlier and with more plugins, the original authors’ hard work was publicly recognized and supported by the jQuery Project and the existing user base gained official support for the code they were using. Unfortunately, there was a downside to this approach. Because the existing plugins were written by different authors with different design principles and different coding styles, there wasn’t much consistency within jQuery UI. Between the 1.0 and 1.8 releases there were a few attempts to standardize various parts of the API, but there was never a coordinated effort large enough to make the necessary changes.

In addition to the inconsistencies between plugins, other problems started to appear over the past three and a half years. As users requested more and more features, the number of options, methods and events continued to grow. Over time, this led to what we have today, where something as simple as a draggable element has almost 30 options. On one hand, it’s impressive that so many various use cases can be handled, often with the use of just one or two of these options. On the other hand, finding the right one or two options to use can be a daunting task, especially for new users.

The Present

Recognizing the existing problems, we approached the 1.8 release differently. We defined a new process for building plugins that focuses on simplified APIs that are easy to extend. With the success of the 1.8 release, especially the simplicity and flexibility of the Autocomplete widget, we were convinced that our new process was working. Having a new process and new standards, we decided to go back and redesign all of our existing plugins with the same design process. In October, the jQuery UI team got together in Boston to do a first pass at redesigning all of the existing plugins. A few weeks later we started posting the proposed changes to gather feedback from the community. We’re still working through some of the details for specific plugins.

Our goal is to have a completely refreshed project with the 2.0 release. We will have a much simpler API, better stability, full documentation and a full test suite for every plugin. However, getting there will require a lot of backward-incompatible changes. We’re aware of how painful that can be and we are doing everything we can to reduce the pain of upgrading. Specifically, we’re doing the following while implementing the new API:

• Ensuring we have a full test suite for the 2.0 API
• Creating a separate test suite for the 1.8 API
• Re-implementing any deprecated functionality on top of the new functionality
• Defaulting to the 1.8 API in cases where the old and new APIs cannot live side-by-side

This approach has several benefits, with one of the most important being that upgrading to 1.9 should not break any existing pages. In fact, the 1.9 release will have better support of the 1.8 API than any 1.8.x release. As plugins are refactored for 1.9, many bugs present in 1.8.x will be fixed and some of the fixes will not be easily ported to the 1.8 branch. Because the support for the 1.8 API in the 1.9 release is actually new code built on top of the 2.0 API, it benefits from these bug fixes. The addition of a full test suite for the 1.8 API ensures that these bugs are actually fixed in both APIs.

Defaulting to 100% support of the 1.8 API is great for upgrading to 1.9, but it doesn’t provide a way to determine if you’re ready to upgrade to only using the 2.0 API. In order to deal with this, we’ve added a new flag, jQuery.uiBackCompat. If you load jQuery, then set jQuery.uiBackCompat = false, then load jQuery UI, none of the 1.8 API will be loaded. This will result in only having the 2.0 API available and will allow you to test your pages for compatibility with the new API and provide confidence that you will be ready to upgrade to 2.0 when it is released.

The Future

When jQuery UI 2.0 is released, we will no longer support the 1.8 API. However, the 1.8 API compatibility layer from 1.9 should continue to work; it will just not be included in the 2.0 release and will no longer be officially supported. All new plugins will go through the new design process so large API changes like this should not occur again. Once the existing plugins have been updated to our new standards, we should be able to move the project forward much faster than we’ve previously been able to.

It’s worth mentioning that only widgets, utilities and effects are being refactored in 1.9. All interactions are going to be rewritten for 2.0 so they will be undergoing a different implementation process. As a user of jQuery UI, there shouldn’t be much perceived difference between the widget refactors and the interaction rewrites other than the release date.

We know that no one looks forward to refactoring existing code to work with API changes, and we’re working to make sure the transition process will be clear and simple.  We hope that you, our users, understand that we need take this opportunity to refine jQuery UI to make it more robust, extensible, and maintainable in the long term.

Continuing with the API redesign, we have some changes planned for the Tabs widget. We know that API changes like this are not without cost to our users, so we’d like to make it clear that except where specifically noted, jQuery UI Tabs in 1.9 will support the 1.8 API as well, and the deprecated APIs will not be removed until jQuery UI 2.0.

API Redesign

Remove rotation.
The rotate method will be removed as it is not very common and has always been implemented as a built-in extension anyway. This will actually be removed, not just deprecated in 1.9 since it has always existed as an extension. Christopher McCulloh has an enhanced rotation extension based on the original code.

Overhaul ajax tabs
The ajaxOptions and cache options are being removed in favor of a new event: beforeload. The beforeload event will receive a jqXHR object and the settings object that will be passed to jQuery.ajax(). ajaxOptions is replaced by modifying the settings passed to beforeload and caching can be implemented by calling event.preventDefault() to prevent the ajax call and jump straight to showing the tab. We will also be keeping the href attribute unmodified and storing the panel id in the aria-controls attribute. The aria-controls attribute will be set for all tabs, regardless of whether they are local or remote. This will remove the need for the url method, which is also being removed. It will be possible to pre-define a value in the aria-controls value for remote tabs, removing the need to specify the location in the title attribute (which is also being removed). The abort method will be removed since the jqXHR object will be directly accessible and you can therefore abort the ajax call directly. Another benefit of the beforeload event is when paired with the existing load event, you can create custom loading functionality; as such we are removing the spinner option.

Selected vs. active
In order to improve consistency within the jQuery UI suite, select/selected will be renamed to activate/active across the board. What this means for tabs is that the selected option will be renamed to active, the select event will be renamed to beforeactivate, and the show event will be renamed to activate. The beforeactivate and activate options will include references to the tab and content panel for the old and new tabs, similar to accordion. In addition, the select method will be removed in favor of the setting the active option. Lastly, the deselectable option will be removed in 1.9 since it was deprecated in 1.8.

Remove templating
All options related to templating are being removed. The templating in tabs is a one-off implementation and creates an inconsistency with the rest of jQuery UI. This change includes the removal of the idPrefix, tabTemplate, and panelTemplate options.

Adding and removing tabs
The add and remove methods will be removed in favor of a new refresh method. This is consistent with how new plugins are updated after initialization. Removing these methods also means that the add and remove events are being removed.

Enabling and Disabling tabs
Tabs will properly support disabling individual tabs or the entire tab set. A boolean can be used to disable the entire set or an array of indices can be provided to disable individual tabs. In addition, the enable and disable events will be removed for consistency with other widgets.

Remove length method
The length method will be removed as it doesn’t serve much purpose and can easily be calculated by counting the number of list items.

Remove cookie option
The cookie option will be removed as cookie support is not core to the plugin. Cross-page state management should be easy, but not be built-in.

Design changes still in flux
There are a few things that we still haven’t fully worked out. We plan on replacing the fx option with show and hide options for consistency with other widgets, but are still working through an open issue of how to support effects across plugins. We would also like to remove the load method but we need to verify that it can be built as an extension. Until we get into the new implementation, we won’t know if this is possible; if it’s not, the load method will remain in the plugin.

Feedback

We’d love to hear your feedback on these changes. We want to make sure we address any issues the community may have before we finalize and implement these changes. If you have any feedback, please post it on the related forum post. Thanks.

Continuing with the API redesign, we have some changes planned for the Position utility.

API Redesign

Merge offset option into the my and at options
The offset option will be removed in favor of including the offset as part of the my or at options.
For example, while you would currently do:

$( "#elem" ).position({
    my: "left top",
    at: "left top",
    of: "#otherElem",
    offset: "50 20"
});

You would now do:

$( "#elem" ).position({
    my: "left+50 top+20",
    at: "left top",
    of: "#otherElem"
});

Regardless of whether you include the offset in the my or at option, the offset will always adjust based on the final position, just like the offset option currently does. We also plan on supporting percentages, so you can offset the element based on a percent of its width or height. If you specify a percentage in the my option, then the percentage will be based on the size of the element being positioned. If you specify a percentage in the at option, then the percentage will be based on the size of the element being positioned against.
For example, to place an element 1/4 of the way down the screen and horizontally centered, you could do:

$( "#elem" ).position({
    my: "center top",
    at: "center top+25%",
    of: window
});

And to position an element so that only the left 10% of it is visible, you could do:

$( "#elem" ).position({
    my: "left-10% center",
    at: "right center",
    of: window
});

Better collision handling
Currently the collision handling is fairly simple. If you enable collision (by specifying fit or flip) then the plugin will detect if there is a collision and if there is, it will move the element accordingly. However, depending on the size of the element, this adjustment may actually cause even less of the element to be visible. We plan on making the collision handling smarter so that it will never make the positioning worse. There will be no change in the API, just better handling for collisions.

Feedback

We’d love to hear your feedback on these changes. We want to make sure we address any issues the community may have before we finalize and implement these changes. If you have any feedback, please post it on the related forum post. Thanks.

As previously stated, jQuery UI is undergoing an API redesign which will slim down the size of the API in order to provide a more stable codebase that is easier to learn and use. This post lists out the details of the proposed changes for the Progressbar widget along with the reasoning behind each change.

API Redesign

Add support for indeterminate progress bars.
We had previously said that indeterminate progress bars should be a separate widget. However, there is a common enough use case where you may want to start providing feedback about that a task has started before you know the actual progress. In this case you may want to start with an indeterminate progress bar and switch to a determinate progress bar as soon as you have enough information to provide details. In order to support this, we will allow the value option to be set to false to indicate that the progress bar should be indeterminate.

Switching from an indeterminate state to a determinate state would look like this:

$( "#progressbar" ).progressbar({
    value: false
});

// later when you find out more information
$( "#progressbar" ).progressbar( "option", {
    value: 15,
    max: 250
});

Feedback

We’d love to hear your feedback on these changes. We want to make sure we address any issues the community may have before we finalize and implement these changes. If you have any feedback, please post it on the related forum post. Thanks.