jQuery Forum

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 leave a comment here. Thanks.

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 leave a comment here. 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 leave a comment here. 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 leave a comment here. 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 leave a comment here. Thanks.

At the last jQuery conference someone asked if we could remove the need to call the base widget destroy method from each plugin's destroy method. This should be very easy to accomplish by just having the base destroy method call _destroy and then changing all plugins' destroy methods to _destroy. This would introduce another API change, but like all the other API changes coming with the new widget factory this is an extremely simple upgrade path. Also, nothing should break if a plugin isn't updated.
In addition to this request, John pointed out that when destroying a method because of the element being removed from the DOM, a lot of the undoing is unnecessary. He suggested adding a second, trimmed down version of destroy specifically to be used on remove. We would need to decide on a name for this method.
Any objections to either of these?

--

The merge of button, toggleButton and radioButton is complete. It would be great to have a sanity check if people can play around with the plugin and make sure everything is working as expected.

--

I'd like to pull jQuery 1.4a2 (and any subsequent releases) into UI and update all files to use it. This will give us a little time to do some more thorough testing with 1.4 before it's released. UI 1.8 should be compatible with both 1.3.2 and 1.4.
Any objections?

--

Jörn and I would like to pull the new widget factory into the 1.8 release.
Steps to get this done:
<ol><li>Split existing code out of jquery.ui.core.js and into jquery.ui.widget.js</li><ol><li>Update dependency for all existing plugins</li>
<li>Update demos for all existing plugins to include new file</li><li>Update build system to include new file?
</li></ol><li>Merge trunk into dev branch</li><li>Replace contents of jquery.ui.widget.js in dev branch with widget factory code from labs branch</li>
<li>Update all plugins to use the new widget factory
</li></ol>Anything else need to happen?

--

Currently in section 4 on our planning pages, we have a grid of browsers that we've tested static markup in. Is there any reason to keep this around after we've completed our initial development? Filling in the grid after the initial development phase just seems like busy work and if any problems are found after this point, they should just be filed as bugs.
Would anyone object to deleting grids for released plugins (any plugin that can have a bug filed against it)?

--

In jQuery UI we have lots of cases where we normalize various values to jQuery objects. Possible values are a jQuery object, DOMElement, array of DOMElements, selector, the string 'parent', the string 'clone', a function that returns a jQuery object. I've put together a function to handle this, but I'd like to see if anyone has any feedback about my solution or other possible values. If you have any thoughts, please post them on the thread at <a href="http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/6a478b0118896672">http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/6a478b0118896672</a> which also contains a link to the code.

--

We've got a lot of plugins that take an element as a option's value (position's of, draggable's helper, etc.). Each of these work slightly differently because there are so many cases to handle that some of them get overlooked. I wrote a function a long time ago to handle this, but never ended up using it anywhere. Here are the cases I came up with back then as possible options:
Note: In many cases there is a context for determining the element. For example, draggable's helper has a context of the actual draggable element.
jQuery object - just return the object again
DOMElement - wrap it in a jQuery object
array of DOMElements - wrap them in a jQuery object
selector - return the jQuery object that matches the selection
the string "parent" - return the parent of the context element
the string "clone" - return a clone of the context element
function - return the result of executing the function and passing the context element as a parameter
anything else - return an empty jQuery object
I'd like to go through and test this on all of our plugins, but I wanted to see if anything had any other cases that we should be handling.
Here's the code: <a href="http://gist.github.com/233531">http://gist.github.com/233531</a>

There's a ticket about the left nav on our demos breaking when the font size is bumped up ( <a href="http://dev.jqueryui.com/ticket/4912">http://dev.jqueryui.com/ticket/4912</a> ). I've modified the description to include a possible fix. Can someone verify the fix?

There's a ticket to support page up/down on a slider ( <a href="http://dev.jqueryui.com/ticket/3096">http://dev.jqueryui.com/ticket/3096</a> ). There's a comment from Richard suggesting a page size to always be 1/5 of the slider's range, rather than adding a page option to define the size. This seems reasonable to me. Any objections?

There's a ticket requesting dialog buttons to be disabled when the dialog is disabled. The request make sense, but I'm wondering what a disabling an open dialog should actually do. Should it just disable everything it controls or should it also try to disable use of any controls inside the dialog's content?

There are a few tickets about setting dialog's width option to 'auto' not working properly. I never intended for this to be a valid option. We do support height: 'auto', but I really don't know how width: 'auto' would even work.
Is width: 'auto' something we should consider supporting? If so, how would it work?

There are currently 55 comments on <a href="http://wiki.jqueryui.com/jQuery-UI-CSS-Framework">http://wiki.jqueryui.com/jQuery-UI-CSS-Framework</a>. Can someone go through and clean this up?<div>
</div><div>Also, it would be good to have a section that explains why our CSS doesn't validate. This question keeps coming up on the mailing list. Here's a thread that covers it well: <a href="http://groups.google.com/group/jquery-ui/browse_thread/thread/0b61ad62072d2578">http://groups.google.com/group/jquery-ui/browse_thread/thread/0b61ad62072d2578</a></div>

I just updated the dialog in the dev branch to use the button plugin. This makes the button plugin a dependency for dialogs if you want to use the button option. Should we keep this as a dependency or should we just use native buttons if the plugin isn't available?<div>
</div><div>My vote is for native buttons instead of just breaking when the button plugin isn't available.</div>

The spinner option of tabs currently requires a span to be nested inside the anchor tag for the tab.  Our visual test file for tabs doesn't include the span and none of our demos do (including our ajax demo).  Do we need to update the markup or can we get away with just changing the tabs implementation?  I assume the span was used for a reason, probably to allow more flexibility with positioning.

This ticket was closed with the following comment:<div>
</div><div><span class="Apple-style-span" style="font-family: Arial, Helvetica, Verdana, sans-serif; font-size: 12px; ">"Patch isn't working, since this move from mouseCapture to mouseStart heavily destroys some functionality: If you add new elements to a sortable list, say via an ajax call, they're automatically valid draggables because of the check being there in mouseCapture already - if it wouldn't, they wouldn't be considered a target, and therefore the drag fails."</span></div>
<div><font class="Apple-style-span" face="Arial, Helvetica, Verdana, sans-serif" size="3"><span class="Apple-style-span" style="font-size: 12px;">
</span></font></div><div><font class="Apple-style-span" face="Arial, Helvetica, Verdana, sans-serif" size="3"><span class="Apple-style-span" style="font-size: 12px;">What are the chances that items are actually added to the sortable in the middle of a sort?  This really seems like an edge case to me, and certainly not something that needs to be natively supported if it causes performance issues.  Wouldn't an alternative solution to this be to call a refresh method on the sortable list if you modify the list in the middle of a sort?</span></font></div>

When you disable a resizable element, the ui-state-disabled class gets added to the resizable element, which defaults to an opacity of 0.35.  Resizable probably shouldn't use the .ui-state-disabled class because the element isn't actually disabled and it's not at all unlikely that a resizable element will contain nested widgets which may be enabled while the resizable is disabled.

Here's my suggestion for a release plan:
Fix #2525 (standardized way to pass coordinates to plugins), land a few more bug fixes and release 1.8a1.
Fix class animations, fix #3772 (full effects support across plugins), land spinner and release 1.8a2.
Bug fixes then 1.8b1.
Bug fixes until 1.8 final.

We've got a ticket for creating a standardized way of passing coordinates/positions to plugins ( <a href="http://dev.jqueryui.com/ticket/2525">http://dev.jqueryui.com/ticket/2525</a> ).  This was put on hold until we had a positioning plugin.  Now that the position plugin is in trunk, we should tackle this.  I've created a ticket to make dialog use the position plugin ( <a href="http://dev.jqueryui.com/ticket/4716">http://dev.jqueryui.com/ticket/4716</a> ) and attached a patch.  Before committing that change, I'd like to figure out our standard way of passing positions to plugins and make sure this will work across the board.
We've got an interesting situation with the three use cases outlined by these tickets:
- Position does not (currently) allow mixing pixel values with words (left, right, top, bottom, center).  There are separate options that deal with words (my, at) and pixels (offset).
- Dialog's position option accepts a string or an array and allows specifying either words or numbers and they can be mixed.  The previous version didn't support specifying multiple values with a string, just short forms like "left" or "top" and would default the second value to center, which is the same behavior as passing a single value to the position plugin.  My patch for dialog allows users to specify two values using a string or an array (accepting an array is needed for backward compatibility).
- Draggable's cursorAt option only accepts pixel values.  This could be extended to support words if we wanted it to.
So, what are everyone's thoughts on how we should handle this?  Should we always only accept string, only arrays, always accept both?  My vote is for accepting both, should only be a few small tweaks to make the position plugin work with arrays.  I would also vote to support mixing words and pixel values when only one value may be provided (dialog's position option and draggable's cursorAt both fall in this category).  Anything that accepts multiple values (this should really only be limited to the options hash for the position plugin) can be decided on later when we add more functionality to the position plugin.