jQuery UI 1.9 Milestone 6 – Spinner 2

Posted on by

The sixth milestone release for jQuery UI 1.9 is out, featuring many updates for the Spinner widget. This release also includes updates and bug fixes to existing and new widgets that will not make it into a 1.8.x release.

What’s a Milestone Release?

A milestone release makes it easier to try out the latest development code of jQuery UI without necessarily having to check out code from GitHub.

With a milestone release you can try out new widgets that are pretty far along (though not yet final) and provide feedback based on released code with a specific version number.

Note: the API is subject to change as the code is still under active development.

Spinner

The Spinner API has been updated with a few new features and bug fixes. Check out the planning wiki for documentation.

Menu

Menu now handles submenus much better.

Position

Position now has a within option, allowing you to use something other then window for collision detection, e.g., a scrolling div. The collision detection itself got a lot smarter, and has a new mode: flipfit.

Download

You can download the jQuery UI 1.9 Milestone 6 – Spinner 2 release as a zip file or via git:

File Downloads

Git

How to Provide Feedback

wiki page

To help with the testing of the Spinner widget, visit the Spinner page on our Development & Planning wiki.

forum

If the comments section on the wiki page doesn’t provide enough room for your feedback, post to the Developing jQuery UI Forum and tag the post:

How to Contribute Code

If you have code changes for the Spinner widget, fork jQuery UI on GitHub and submit a pull request.

If you’re new to git or GitHub, see our guide: How to submit a fix to jQuery UI – The Easy Way.

Comments

Note: please do NOT use the comments section of this blog post for feedback on the Spinner widget. This discussion should occur on the wiki page and the forum (see How to Provide Feedback, above).

If you have feedback on us doing our sixth milestone release, feel free to leave a comment below. Thank you.

Dialog API Redesign

Posted on by

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.