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.

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. This post lists out the details of the proposed changes for the Accordion widget along with the reasoning behind each change.

API Redesign

Remove navigation and navigationFilter option.
The navigation-related options are being removed in favor of setting the active option during initialization. The built-in navigation filter didn’t always make sense and was turned off by default. We plan on adding a demo which shows how to implement the current navigation functionality as well a demo which shows how to use a cookie to store the active panel.

Merge the autoHeight, fillSpace and clearStyle options into a new option called fixedHeight
The autoHeight, fillSpace and clearStyle options all deal with similar issues and therefore cannot be used together. Having three options for the same feature (how tall the panels should be) creates a complex and confusing API. These three options are being replaced by a single boolean option called fixedHeight. When set to true (the default), all panels will have the same height. If the accordion has a height of “auto”, then all panels will be as tall as the tallest panel (equivalent of autoHeight: true). If the accordion has an explicit height, then all panels will be sized based on that height (equivalent of fillSpace: true). When fixedHeight is set to false, no calculations will be done for the height of the panels and they will be sized based on their content (equivalent of clearStyle: true).

Rename icon.headerSelected option to icon.activeHeader
This option is being renamed for consistency both within Accordion (active vs. selected when dealing with the active panel) and within the full jQuery UI suite.

Remove activate method
The activate method will be removed in favor of updating the active option. The inclusion of the activate method doesn’t simplify the use of the accordion and therefore isn’t necessary.

Rename resize method to refresh
This method is being renamed for consistency within the full jQuery UI suite. However, this will continue to only handle size changes for now. We do plan on supporting adding/removing panels in the future.

Rename changestart event to beforeactivate
This event is being renamed for consistency both within Accordion (activate vs. change when dealing with the active panel) and within the full jQuery UI suite.

Rename change event to activate
This event is being renamed for consistency both within Accordion (activate vs. change when dealing with the active panel) and within the full jQuery UI suite.

Add .ui-accordion-heading class
There is currently no class being added to the headings for each panel. This results in the stylesheet using .ui-accordion-header a for styling, which makes adding additional anchors to the headers difficult. To solve this, we will add a class to the first child of each header and use the new class for styling.

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.