Continuing with the API redesign, we have some changes planned for the Dialog 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 Dialog in 1.9 will support the 1.8 API as well, and the deprecated APIs will not be removed until jQuery UI 2.0. Read more about the full jQuery UI API redesign.

API Redesign

Contain focus in dialog
We currently only contain focus inside modal dialogs. We will be changing this behavior to always contain focus, even in modeless dialogs. This will bring us more in line with the DHTML Style Guide. We’re not sure about implementing a key command to move the focus out of the dialog (such as F6) since that would require defining a system to track where focus should move.

Allow disabling dialogs
Dialogs don’t currently support being disabled. They do inherit the default behavior of adding the ui-state-disabled class, which makes the dialog look disabled, but the user can still interact with elements in the dialog. In order to support disabling a dialog, we will place a div over the dialog to prevent mouse interaction.

Ability to configure which element gains focus
When opening a dialog, we search for which elements are tabbable and we focus the first element that we find. If there are no tabbable elements, then we focus the dialog itself. We will be adding an autoFocus option, which will allow customizing which element gains focus. The option will accept a function which will return the element to focus. The default value for the option will be the current implementation. If no element is found using the option, the dialog will be focused.

Move dialog back to original DOM position on destroy
When dialogs are created they are moved to the end of the body. When dialogs are destroyed, they currently stay at the end of the body. We will be changing this behavior so the dialog is returned to the original position, if possible. This will be done by tracking either a sibling or the parent on create.

Automatic stacking
The stack option controls whether a dialog will move on top of other dialogs when it gains focus. Since this should always be the case, we will be removing the option and forcing the behavior. In addition, we will probably remove the moveToTop method since the proper dialog(s) should always be available to the user based on when they were opened and whether they are modal or modeless.

Saner modality
The current implementation for managing modal dialogs is a bit unwieldy, comparing the z-index of elements and often causing problems. We plan to simplify the implementation and switch to a hierarchy-based solution instead of a style-based solution.

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.

The original idea of the ARIA Hackathon was to get developers of jQuery UI and experts for ARIA together in one room, connect them, share knowledge and work on the accessibility of jQuery UI.

Meeting at the Inclusive Design Research Centre (IDRC) of OCAD University in Toronto, several members of the jQuery UI team (Richard, Scott, Dan, Jörn), various developers at OCAD (Michelle, Justin, Antranig, Harris), around Toronto (Ates, George, Darcy) and further away (Mat from Boston, Candace and William from the University of Washington and Jerry from the University of Illinois) learned a ton about testing and developing for screenreader users, about the ARIA standard and its process, as well as Mozilla’s efforts on accessibility.

• Colin Clark gave an overview of the work of the IDRC team, including the Fluid project which makes use of jQuery UI.
• Hans Hillen provided a lot of very practical insight on testing and developing with JAWS and NVDA and the ARIA spec and DHTML styleguide.
• Jospeh Scheuhammer, heavily involved in the ARIA standards process, gave insight on how the process works like, how to provide feedback and which documents can and should be used along with the main specification.
• David Bolter provided an overview of Mozilla’s efforts on Firefox accessibility, also covering the state and future of Firefox Mobile.
• Finally Jennison Asuncion demonstrated usage of JAWS on regular websites, giving the spectators (or rather, listeners) a much better understanding of how a blind user actually uses a screenreader. He’s also an incredibly nice guy.

In a group discussion, we defined latest NVDA on latest Firefox as the supported setup for ARIA and acccessiblity, while also testing with JAWS on Windows and VoiceOver on OSX. We will accept reasonable patches for other or older ATs if the code is maintainable and doesn’t break ARIA in spec-conforming ATs.

After the two days of the main event, Hans and Jörn stayed till Friday to work on the keyboard and accessibility implementation of multiple jQuery UI widgets. Jörn also had meetings with Justin and Michelle at OCAD and Bobby and David at Mozilla to recruit them for jQuery UI and the Testing subteam (QUnit, TestSwarm). There is a lot of mutual interest that should lead to a lot more collaboration going forward.

Special thanks go out to IDRC and Colin Clark for hosting the event and Mozilla and David Bolter for funding some of the travel and lodging expenses.

For a mostly complete list of attendees (and links to Twitter and GitHub profiles) and various resources gathered during the event, visit the events page on our planning wiki.

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.

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.