jQuery UI 1.8.11

Posted on by

The eleventh maintenance release for jQuery UI 1.8 is out. This update brings bug fixes for Accordion, Autocomplete, Button, Datepicker, Draggable, Droppable, Mouse, Sortable and Effects. For the full list of changes, see the changelog. You can download it here:

Download

File Downloads

Svn (contains final files as they are in the zip, with @VERSION replaced with 1.8.11, all themes)

Git (contains source files, with @VERSION not yet replaced with 1.8.11, base theme only)

Google Ajax Libraries API (CDN)

Microsoft Ajax CDN (CDN)

Custom Download Builder

Changelog

See the 1.8.11 Upgrade Guide for a list of changes that may affect you when upgrading from 1.8.10. For full details on what’s included in this release see the 1.8.11 Changelog.

Thanks

Thanks to all who helped with this release, specifically: Adam Parod, ajpiano, akantro, alkaaran, awgy, daepark, David.Sullivan, ddstreet, Douglas Neiner, dziastinux, eleotlecram, elijahmanor, ghusse, gnarf, Guillaume Gautreau, Marcel Toele, Matt Hoskins, michaelmwu, mosevo, mystic414, nathansobo, [email protected], Niloct, Richard Worth, saidovab, Scott González, Skaffen, waschmittel.

Comments

Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery UI Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our eleventh maintenance release for jQuery UI 1.8, feel free to leave a comment below. Thank you.

API Redesigns: The Past, Present and Future

Posted on by

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.

Tabs API Redesign

Posted on by

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.

jQuery UI 1.8.10

Posted on by

The tenth maintenance release for jQuery UI 1.8 is out. This update brings bug fixes for Accordion, Button, Datepicker, Dialog, and Resizable. For the full list of changes, see the changelog. You can download it here:

Download

File Downloads

Svn (contains final files as they are in the zip, with @VERSION replaced with 1.8.10, all themes)

Git (contains source files, with @VERSION not yet replaced with 1.8.10, base theme only)

Google Ajax Libraries API (CDN)

Microsoft Ajax CDN (CDN)

Custom Download Builder

Changelog

See the 1.8.10 Upgrade Guide for a list of changes that may affect you when upgrading from 1.8.9. For full details on what’s included in this release see the 1.8.10 Changelog.

Thanks

Thanks to all who helped with this release, specifically: adam j. sontag, Alex Dovenmuehle, alfatek, cmcnulty, Dan Heberden, echos, George Marshall, istvan.m.antal, jamey, jomyjohn, loganbailey, Martin Solli, Richard D. Worth, Scott González, severin, Squ36, Tobias Brunner, Xavi.

Comments

Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery UI Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our tenth maintenance release for jQuery UI 1.8, feel free to leave a comment below. Thank you.

jQuery UI 1.9 Milestone 4 – Accordion Redesign

Posted on by

The fourth milestone release for jQuery UI 1.9 is out, featuring the updated Accordion 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.

Accordion

The Accordion API has been redesigned for simplicity, extensibility and consistency with other widgets in jQuery UI. We’d love to get feedback on any compatibility issues you may have with existing code. Everything supported in 1.8 should work out-of-the-box in 1.9; if something breaks, we will work to fix it before the final release.

jQuery.uiBackCompat

As mentioned above, 1.9 will support the 1.8 API, as well as the redesigned API. However, this introduces two problems. First, some of the APIs don’t overlap cleanly. For example, in 1.8 you can collapse an accordion by setting the active option to false or -1; but with the API updates, you can set the active option to a negative number in order to activate a panel starting from the last panel instead of the first (similar to .eq()). Second, while both APIs are supported, it’s hard to test whether you’ve successfully updated all of your code for compatibility with the 2.0 release which will not support the 1.8 API. In order to deal with these issues, we’ve introduced a flag, jQuery.uiBackCompat, which can be used to prevent the backward compatibility layer from executing. This flag must be set after jQuery is loaded, but before jQuery UI is loaded. Toggling the flag after jQuery UI has been loaded will have no effect.

Download

You can download the jQuery UI 1.9 Milestone 4 – Accordion Redesign release as a zip file or via git:

File Downloads

Git

How to Provide Feedback

wiki page

To help with the testing of the Accordion redesign, visit the Accordion 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 Accordion, 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 Accordion 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 fourth milestone release, feel free to leave a comment below. Thank you.

jQuery UI 1.8.9

Posted on by

The ninth maintenance release for jQuery UI 1.8 is out. This update brings bug fixes for Accordion, Datepicker, Draggable, Sortable and Tabs. For the full list of changes, see the changelog. You can download it here:

Download

File Downloads

Svn (contains final files as they are in the zip, with @VERSION replaced with 1.8.9, all themes)

Git (contains pre-build files, with @VERSION not yet replaced with 1.8.9, base theme only)

Google Ajax Libraries API (CDN)

Microsoft Ajax CDN (CDN)

Custom Download Builder

New Features

Datepicker

The datepicker widget now has support for the Algerian Arabic, Australian and New Zealand localizations.

Changelog

See the 1.8.9 Upgrade Guide for a list of changes that may affect you when upgrading from 1.8.8. For full details on what’s included in this release see the 1.8.9 Changelog.

Thanks

Thanks to all who helped with this release, specifically: Campbell, cherif, Christoph Burgdorf, Ivan Peters, jorrit, marcos.sousa, Scott González, tobias.istvan.

Comments

Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery UI Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our ninth maintenance release for jQuery UI 1.8, feel free to leave a comment below. Thank you.

jQuery UI 1.8.8

Posted on by

The eighth maintenance release for jQuery UI 1.8 is out. This update brings bug fixes for Position, Accordion, Autocomplete, Button, Datepicker, Dialog, and Effects. For the full list of changes, see the changelog. You can download it here:

Download

File Downloads

Svn (contains final files as they are in the zip, with @VERSION replaced with 1.8.8, all themes)

Git (contains pre-build files, with @VERSION not yet replaced with 1.8.8, base theme only)

Google Ajax Libraries API (CDN)

Microsoft Ajax CDN (CDN)

Custom Download Builder

New Features

Datepicker

The datepicker widget now has support for the Malayalam localization.

Changelog

See the 1.8.8 Upgrade Guide for a list of changes that may affect you when upgrading from 1.8.7. For full details on what’s included in this release see the 1.8.8 Changelog.

Thanks

Thanks to all who helped with this release, specifically: aaronpeterson, Alex Dovenmuehle, calvin, chyi1235, Corkup, danlash, draenor, hypnotoad, ji1337, Kevin Dalman, m4olivei, Mario Visic, mjpowersjr, Saji, Scott González, Tony Ross, urkle.

Comments

Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery UI Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our eighth maintenance release for jQuery UI 1.8, feel free to leave a comment below. Thank you.

jQuery UI 1.8.7

Posted on by

The seventh maintenance release for jQuery UI 1.8 is out. Along with official support for jQuery 1.4.4, this update brings bug fixes and enhancements for the Position, Draggable, Sortable, Autocomplete, Button, Datepicker, Dialog, Progressbar, Slider, Tabs and Effects. For the full list of changes, see the changelog. You can download it here:

Download

File Downloads

Svn (contains final files as they are in the zip, with @VERSION replaced with 1.8.7, all themes)

Git (contains pre-build files, with @VERSION not yet replaced with 1.8.7, base theme only)

Google Ajax Libraries API (CDN)

Custom Download Builder

New Features

In this release, we’ve added support for jQuery 1.4.4.

Button

The buttonset widget now supports an items option to define which elements to convert to buttons.

Datepicker

The datepicker widget now has support for the Rhaeto-Romanic localization.

Progressbar

For the second release in a row, the progressbar widget has received an update! You can now specify a max value via the new max option.

Changelog

See the 1.8.7 Upgrade Guide for a list of changes that may affect you when upgrading from 1.8.6. For full details on what’s included in this release see the 1.8.7 Changelog.

Thanks

Thanks to all who helped with this release, specifically: 1730wang, AccessDenied, Alex Dovenmuehle, amodlin, andrew_, anonymous, awgy, azran1981, c_schmitz, dalexandre, dblood, DoctorArnar, doerwalter, dsargent, fetchak, fracmak, gethinw, ghusta, goldy, guoicq, Heiko Henning, imefisto, InAme, inukshuk, israelrios, J. Ryan Stinnett, [email protected], jamiejag, jao, Jay Merrifield, jazzido, Jean-Francois Remy, Jeff Roush, jeffsmith, jessicah, joern.zaefferer, jryans, juergen.furrer, jzaefferer, k.robinson, kbwood, kevin.wells.iq4bis, Khaled AlHourani, Kyle Wilkinson, kzamir, mal, Marian Rudzynski, mayoulti, mbarkhau, michael.heuberger, mlooise, nmb.ten, perlpunk, pheiberg, Phillip Barnes, poplix, rambat, rdworth, rlandrum, Ronin, rosieks, Rwhitbeck, Sachemo7, saks, saksmlz, Scott González, seb835, sixhead, skeetergraphics, Stéphane Raimbault, sz_zoly7, tedclarkjr, TheBlaze, tombigel, vosechu, Wallbanger, WanderingZombie.

Comments

Note: please do NOT use the comments section of this blog post for reporting bugs. Bug reports should be filed in the jQuery UI Bug Tracker and support questions should be posted on the jQuery Forum.

If you have feedback on us doing our seventh maintenance release for jQuery UI 1.8, feel free to leave a comment below. Thank you.

Position API Redesign

Posted on by

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.

Progressbar API Redesign

Posted on by

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.