jQuery Forum

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 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.

I created a ticket for the zIndex method we had talked about on the planning wiki.  I've attached an implementation, it just needs some tests written.
<a href="http://dev.jqueryui.com/ticket/4709">http://dev.jqueryui.com/ticket/4709</a>

Does anyone know why all the effects wrap the functionality in .queue instead of .each?  Seems odd to me since they then tell .animate not to queue and then manually dequeue after the animation.

Hey everyone,
It's been four months since the 1.7 release and two and a half months since the 1.6 release.  I'd like to propose a 1.8 beta release no later than two weeks after we get positionTo and the class animation fixes into trunk.  We've currently got 286 open tickets and 45 blockers/criticals for 1.8, so please help out and close some bugs.

I just created a ticket to create some test pages for nested widgets ( <a href="http://dev.jqueryui.com/ticket/4651">http://dev.jqueryui.com/ticket/4651</a> ).  These just need to be visual tests that we can use to verify that our widgets work together.  I've got a couple of tests I'd like to create listed in the ticket, but please add to the ticket if you have other ideas.  They don't need to have any context or real-world use case like our demos, they just need to prove that the functionality works.

Is there a reason we have defaults for my and at?  The entire purpose of this plugin is to specify where you want an element to be positioned, so calling it without any values specified for my or at doesn't seem logical.