Add jQuery UI elements to core

This would be fantastic. I think this patch should just be the addition of jQuery UI. Other enhancements should come as separate issues. Maybe attach the farbtastic changes as a separate patch to this issue for testing.

I think all of jQuery UI is too heavy. Wouldn't it be possible to include only the pieces as we need them? I'm in full support of the following being added immediately:

- jQuery UI core
- Draggable, Droppable, and Sortable
- Date picker
- Colorpicker(?)
- Progressbar(?), afaik, jQuery's progress bar does not natively support incremental loading via AJAX.

But I'd prefer to see these split up rather than bundled together into one giant JS file. Unless these are loadable on a per-file basis, I'm strongly opposed to the effects jQuery UI adds, as they're mostly dead-weight that'll actually increase inconsistencies between the the way Drupal behaves on a per-module basis.

I also agree that this issue needs to be split up as soon as possible into separate issues. There's no way we can replace all of Drupal's legacy code with UI equivalents in a single patch.

How about just getting jQuery UI in by itself, as well as an incremental loader, and then making core use it can come later.

I agree with dimtrig01. This issue should stick with adding jQuery UI to core and the implementation of the incremental loader. Does anyone have an outline of how you would handle an incremental loader?

Good call Rob. I wanted to suggest we do that first but didn't want to be a total downer. :)

This is a great idea, and could really help give Drupal an edge when it comes to innovative UI.

As long as each jQuery UI component is overridable, it's fine by me.

For example jQuery Resizable (both 1.5.2 and 1.6rc1, because both are identical) is an utter piece of crap, as soon as you're trying to use it in an advanced way (e.g. apply it to a "grip" div that then applies the same scaling to >= 1 selects, see this issue). The code is also so incredibly ugly and inconsistent that I didn't even want to try to report my problems. (Because of those same reasons I couldn't be sure my hacks to make it work correctly were the right way to fix it anyway.)
So I want to be able to override it with a potential newer (more stable) version.

Thanks for the discussion guys - I'm just passing this on the the jQuery UI guys so that they'll be able to chime in.

this is a fantastic development.

Thinking in terms of aggregation, loading them file by file on each page may be optimal for some files and less than optimal for others. Considering realistic latencies however, it is almost certainly better (in terms of client side performance) to load all the JS as one big blob as we do now or split it into a small handful of (ideally functionally related) blobs, along the lines of sf_cache.

@Grugnog2 I'd suggest getting jQuery UI in core first and then having a follow-up patch for optimization in the preprocessing/aggregation. It's a good idea. A simpler patch would just be easier to review/test and easier to get in.

@Rob Loach I think what @Grugnog2 is getting at is to have more than one file to have the js files aggregate to. Basically, intelligent grouping of files. Check out http://drupal.org/project/sf_cache for ideas on the concept. There is potential, with browser file caching, to cut down the amount of bandwidth used by doing this.

Subscribing.

I may have some bad news regarding the jQuery 1.6 colorpicker for farbtastic. I wanted to get it working with color.module however found this:

19:40 < ThrushAAX> skiquel: colorpicker is probably going to be dropped from
ui1.6 release because it doesn't work in iE

There has also been news on the list about it being recoded. I'll make a ticket on the UI list asking to make it more important.

If they are still up in the air about about what is going to be in jQuery UI 1.6 is it really a good time to introduce it to core? I use it daily and am not sure I consider it ready for drupal core yet.

If the issue comes down to color picker vs. farbtastic, I'll keep up the maintenance on farbtastic for the time being.

I created a thread regarding jquery color picker here: http://groups.google.com/group/jquery-ui/browse_thread/thread/1c16468720...

I'm having my fingers crossed for the rewrite here, as a long-awaited feature that was held back from 1.5

@RobLoach: Agreed, even without the colorpicker it's still substantial and a well made library to use. Unless there is a serious technical reason otherwise it would be very helpful to have in core.

Update Nov 27 3:49PM CST: according to the group thread color picker won't make 1.6. :( Think nothing of it, it's a good time to emphasise 1.6's many other strong points (and jQuery UI itself, of course).

As the maintainer of a Drupal release that realistically is going to be in use "in the wild" for at least 3 years (and realizing that whatever we get into it by then is going to be "frozen" for that length of time), I get real nervous about "locking in" libraries that are still undergoing major refactoring like this.

Had we put jQuery UI in core when this issue was first brought up, we would've replaced farbtastic with jQuery UI's colorpicker, only to have that removed under our noses in this new version. Not fun. It kind of implies to me that this thing isn't really stable enough yet, and although you could *definitely* make the same argument against jQuery itself (new versions of that broke all kinds of stuff until lately when it seems like it's started to settle down a bit), that is a much, much smaller bunch of code than jQuery UI within which to find bugs.

So, still not sold on this. I guess we'll see what happens once the various JS sub-system refactoring is done and we know what our options are.

@webchick - I use jQuery UI on an almost daily basis and I agree with you 100%. I'm happy with it in contrib at this point and when it's stable enough I would love to see it in drupal core. But, not yet.

@issue - Robloach (and probably some others) made the mistake of thinking colorpicker (delayed in 1.5 and subsequently in 1.6) would make it in. Same with "autocomplete". jQuery UI isn't moving code into a major release unless it's stable. I had to update their documentation accordingly.

When it comes, let's take a look at the low and high level benefits of 1.6 stable from a technical perspective and see if it fits.

jQuery UI 1.5 was released in June. 1.6 will probably release in December. If they continue on the same release cycle then 1.7 could arrive next June. I don't think that D7 will be released by then. So there is still a possibility that we can still work colorpicker and autocomplete in. Also I've seen an increase of contrib modules that depend on jquery ui so it would be useful to them also.

I completely agree with mfer.

@redndahead: The problem is that if we ship with 1.7, there will be bugfixes in 1.8, 1.9 and so on that won't be in core. So you'd need a contrib module to override core's 1.7 version to a newer version. jQuery itself on the other hand is stable enough to develop with for years.

I think this is a wise decision of webchick. As much as I'd like to see jQuery UI in core and all the cool stuff that it enables, it simply isn't mature enough yet.

subscribing

Also noticed that they would like UI 1.6 to be used with jQuery 1.3 and ui 1.5.3 to be used with 1.2.6. So this means #350275: Update to jQuery 1.3.2 should probably be committed before this.

I prefer these Jquery UI features to be included in Drupal core.
- jQuery UI core
- Draggable, Droppable, and Sortable
- Date picker

For rest of Jquery UI features we should create a module because we need to change them to be adapted in Drupal.
--
Sharique

Subscribing—drawing together threads in a domino-effect of postponed patch dependencies. :)

/me tries really hard to stifle a scream of "TOLD YOU SO" about this not being remotely ready to lock into our CMS for 3+ years. :P

Anyway, we'll see what happens.

So whats our time frame here? Is there still time for them to stabilize or is jQueryUI off the table for d7?

@starbow: D7 code freeze has yet to be announced, so yes, there's definitely still time. However, given how absolutely hap-hazard jQuery UI has been traditionally been about releasees, I would really rather NOT include any of it in core until we have an easy way for site builders to swap it out for newer versions. That's why this is postponed on #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries). I'm not sure why that issue is postponed right now.

jQuery UI also requires jQuery 1.3.x, so this is also postponed on #350275: Update to jQuery 1.3.2. Right now that issue is blocked both on waiting for 1.3.2 to be released (which fixes a regression), and also because tablesort is completely broken in 1.3.

thanks for the clarification. I am still getting a feel for when you are expressing an opinion and when you are making an official proclamation :)

Ah. ;) I very rarely am making official proclamations. I am, however, always very opinionated. ;)

Subscribing.

Mark and Lisa published a video of D7UX initial concepts & direction. If these ideas are to be implemented, parts of jQuery UI will be needed in core.

To add to the lists at #2 and #4, jQuery UI would also open up the doors to making interface elements "ThemeRoller" compliant. Supporting ThemeRoller would a huge win for themers and could expand color module's roll in Drupal core.

Adding "usability" tag.

subscribing and wishing jQuery UI 1.7 is stable enough. It's hard to see how a new release of jQuery UI breaks whatever you've done with the previous version. But now, the documentation seems to be a bit more concerned about changes between versions, so that seems to be a good sign.

The decisions that need to be made include:
a) How much of jQuery UI to put into core?
b) If the answer is not all of it (which would be nice, because that's far fewer lines of code we need to be responsible for and related bugs we need to squash), how do we deal with the fact that people are going to need the "Squishable" library, which is not included in core, in their modules?
c) Most importantly, how do we deal with the fact that jQuery UI is not currently a stable library (it has had at least three releases since D7 opened for code thaw a year ago) and will thus need to be upgraded 5 or 6 times during the lifecycle of D7?

I would encourage people who want to see this in core to focus on #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries), so that we can abolish the requirement for modules like jQuery Update, jQuery UI, jq, jqp, and the 11,000 other modules in contrib that are all doing the same thing to make up for the fact that core doesn't provide central management of JS plugins. :P

This way we could put relatively unstable libraries such as this in core with a lot more confidence that people wouldn't be stuck with unsupported JS libraries for 3-5 years when Drupal 7 gets released.

it has had at least three releases since D7 opened for code thaw a year ago...

Hm. Make that four:

http://jqueryui.com/docs/Roadmap

May - June 2009

* Stable: 1.8.1, 1.8.2, 1.8.3
* Preview: 1.9alpha, beta, rc
o New plugins: TBD

Might even be five, if you look at the aggressive timeline they have for going from 1.7 to 1.8. (3 months: March -> May) That'd make their target 1.9 release date pretty much exactly coinciding with D7's code freeze.

Then again, it's just a roadmap. ;) Who uses those things anyway? ;)

In regards to jQuery UI's pace of development (#47 point C), I agree that a plug-in manager in core would make upgrading easier and more consistent. However, in the end core itself will still be tied to UI's aggressive schedule. While this isn't ideal, it is better than the alternative I see. What is worse: shipping with a (soon to be) outdated version of jQuery UI or Drupal's current piece-meal approach to JS UI elements? Even though jQuery was soon out of date in D5, using the library was the right choice. I feel the same about UI despite its rapid evolution.

At the risk of being off-topic (and maybe even heretical), I'd also like to consider amending Drupal's stance towards minor updates. If core releases are going to be supported for 3+ years, maybe minor releases should incorporate new versions of external libraries if most developers are in favor. I appreciate Drupal's approach to API stability but jQuery UI updates could be appropriate considering the upside of staying current.

@rickvug: Given that their APIs tend to break every single time they do a new jQuery/jQuery UI version, I think this is not a very nice thing to roll out as a "surprise!" to module developers depending on a stable release of Drupal to be... well... stable.

Having dealt with a constantly changing API in SimplePie when I did early development on SimpleFeed module, this was a hair-ripping-out experience I hope to never have to deal with again, and wouldn't wish it on my worst enemy, let alone 100,000 Drupal developers. ;)

We still need answers to A and B regardless if we do C. I don't think it makes any sense to commit any of jQuery UI (or, at the very least, release Drupal 7) without C. However, I'm also not a JS person, but there are several JS people in this thread earlier who agreed.

hmm... let me think about "a) How much of jQuery UI to put into core?". I guess it depends on "what's the benefit of doing so".

Now, Drupal javascript is built on top of jQuery itself and we already have a problem to keep in sync with new jQuery versions. Upgrading jQuery means rewriting/replacing a few Drupal components (jquery_update module). Here I would think about the cost of this operation versus the cost of being limited by out dated versions. I mean cost for Drupal itself, but also cost for those developing/investing on top of Drupal. Also, would it be easier to upgrade components that were based on jQuery UI?

Here I would add as a concern the fact that new jQuery UI versions may require latest jQuery versions, so if you need to write something on top of jQuery UI that requires latest version, you simply can't. You cannot install a new version of jQuery because you would be breaking your Drupal installation. So you cannot use latest jQuery UI. Your business is limited by Drupal during X months/years.

Being able to use latest versions of jQuery/jQuery UI can put you on top of your competitors, and it is good investment because that's the future. Sooner or later the world will move in that direction just because that's the very latest version. It looks like a bad investment to write on top of outdated versions as it will be broken for sure when Drupal is upgraded. If you do, you know you're increasing the cost of development and maintenance of your project.

On the other hand, let's say jQuery UI is like a high level API, so it seems it would be easier to deal with version changes as it would encapsulate the complexities of the low level API (jQuery itself). Upgrading drupal components based on jQuery UI would cost less to upgrade?

Not sure if I'm adding anything useful for the discussion, though.

sub

For cross-reference : http://drupal.org/node/444344#comment-1569638 on #444344: jQuery .once() method for adding behaviors once

Dries says he would support jQuery UI inclusion in core: http://hojtsy.hu/blog/2009-jun-17/two-alternatives-d7ux-overlay-implemen... Adding his tag, and hope is not offended :)

Tagging it is OK in this case. Thanks even. :)

Gábor/Dries: I'm pretty sure we all support putting jQuery UI in core. The questions left to resolve are:

a) How much of jQuery UI in core?
b) What do we do about the fact that this library is still very unstable, and a new major jQuery UI version is coming out about every 3 months, filenames changing willy-nilly, things that were "core" being removed out from under your feet, etc?

There are people doing work at #315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) to help make sure that whatever decision we make here don't screw people using Drupal 7 six months from now.

One alternative is just to put the whole damn thing in and kick it to something like jQuery UI Update module in contrib to deal with the issue. That's certainly the easiest. Are we comfortable basically doubling the size of core with a complex third-party library that none of us know how to support?

Why not just use the Google AJAX Libraries API? Then all you have to do is specify the version (however general or specific that is preferred) that the particular version of Drupal uses and the modules you need and let Google handle the headache and bandwidth. Plus, this means that it is significantly more likely that the (rather large amount of) JavaScript in question will be cached when you jump between multiple Drupal sites.

@jrchamp: well, that would not work when you don't have an internet connection or you are in a firewalled intranet or somesuch. Whatever we use we distribute.

@webchick: note that Drupal 6 did not change much in how it includes jQuery, and neither it is including the latest jQuery if it breaks APIs (jQuery update still makes sense for Drupal 6). I don't think we need to include the latest and greatest at all times. If they have a bugfix release which does not include new/changed stuff, then that we can ship. I know jQuery is also notorious for bundling new stuff with bugfixes, so sometimes it might not be a trivial decision.

On the size of the codebase, it is a huge codebase if you count the tests, docs and all that, but if you only count the core jQuery UI files, it is around 600 - 700k as far as I've seen. Maybe I missed adding up some required stuff?

@jrchamp in addition to what Gábor pointed out, some countries block google apis so it's not a realistic solution.

@Gábor The minified jQuery UI is just over 600k (with i18n). The base theme is about 160k. We may want our own here but this gives us a rough size.

For the stuff we are talking about with core we could even choose something other than jquery ui like jquery tools (http://flowplayer.org/tools/ - http://drupal.org/project/jquerytools) which is a whole lot smaller.

For core drupal stuff what are we considering using from jQuery UI?

@mfer: Well, so far only a little bit of jQuery UI was discussed to be possibly used via some form of the popups module or modal frame api being integrated into Drupal 7. So jQuery UI dialogs mainly.

@Gábor we maintain a bunch of custom JS to do what's in jQuery UI. If we can get jQuery UI in we would want to bring more of it over to remove our own stuff. It would be less maintenance for us. For example, resizable text areas and table sorting.

One of the pros I see in jQuery UI is the fact that it shares code between its own components. I cannot see jQuery UI included only with just one component.

Maybe jQuery UI developers could somehow get involved in this decission for D7, at least to know a little bit more about their plans for future jQuery UI versions. I think something like this has been done with jQuery itself?

@dries and @webchick What do we need to bring jQuery UI into core beyond a patch that does it?

If we want to add jQuery UI to core, we should simply add it and conditionally load the files where needed just like we load any other JavaScript.

That will already allow us to replace various custom UI implementations like others have mentioned. But also move forward with CCK UI / Form Builder in core.

#315100: Allow to add JS/CSS libraries (sets of files, settings, and dependent libraries) mainly adds a layer of indirection; nothing that couldn't be achieved using hook_js_alter() already.

Agreed with @sun.

Which means we simply need another issue that's marked critical and titles "Add hook_css_alter()". The issue you referenced has been bumped equally now.

+

It seems to me that the question should be - is jQueryUI, as it exists today, good enough to build core effects on? And it seems like the best people to give feedback on that, are people that have been using it to build real sites. Anyone have real world experiences to share?

If you do include it, seems silly to not include the whole thing (all the elements, not necessarily the tests and stuff).

One of the primary concerns raised in this issue is the frequency of jQuery UI releases. I'm not involved in jQuery so I do not know the roadmap for 1.8+. The best information I have is the list of Trac's release blockers at http://is.gd/1eCZq. Looking at the list, I'd assume that 1.8 isn't coming out for a while. The previous wiki information must have been overly optimistic.

Looking into this issue just a little bit, it looks like past problems were mostly associated with UI's 1.6 release release cycle. The code underwent significant changes while in RC status. RC2 became the 1.6 legacy branch and the newer 1.6 code become 1.7. See http://blog.jquery.com/2009/02/12/jquery-ui-17-is-the-new-16 for the whole story. Based on the explanation, I would assume that the release cycles from 1.8 onwards will be more structured. Here is the best release UI release timeline that I could put together:

- 1.0 September 2007
- ??? A quick Google search didn't turn up much. Trac doesn't show these releases.
- 1.5 June 9 2008
- 1.6 April 24, 2009 (legacy release, made after 1.7)
- 1.7 March 6 2008

The conclusion that I've drawn is that jQuery UI's past release cycles should not be used as a guide for future releases. 1.7+ brought new version/release pattern. It could very well be that the 1.7 release will be in use for a time to come. There still is the issue of point releases containing a mix of bug fixes and new features. If existing APIs/features remain stable these additions shouldn't be problematic. Obviously that is a big if.

It would be helpful if those involved in the jQuery community could chime in regarding the current/future length of jQuery UI release cycles as well as their policy towards API changes in maintenance (1.7.x) releases. The release manager is Richard D. Worth (@rworth) but he is not online for the next few weeks.

I've been involved with updating jQuery UI based solutions from Drupal 5 (with a pretty old jQuery UI version) doing drag and drop and that kind of stuff to Drupal *7* with the latest jQuery UI. It was a pretty simple update. I admit I did not use any great internals from jQuery UI, so I might just touched the compatible parts, but my experience so far is that it was not a groundbreaking problem.

I read through this issue and I'm currently a bit unsure what holds back adding jQuery UI. I looked at the jquery_ui module and I'd even say that we could commit this module as is. Pages that use a certain feature just call jquery_ui_add() and choose the parts they need (this could be streamlined with http://drupal.org/node/315100#comment-1748722, but I don't think that issue should hold this back. If no module/page uses a certain jQuery UI widget -- so what?

I think many people are just afraid of depending on external libraries because of their release schedules and possible bugs. There is a certain "let's implement it ourselves" kind of approach even if we cannot take on the support burden or bugfixing in that case either. For jQuery UI, we'd definitely not implement it ourselves, but there are efforts to get things into core like modal dialogs or formbuilder, where jQuery UI is pretty much a requirement, or we need to reinvent the wheel to an enormous extent.

Yeah. My concern comes from being one of the co-authors of jQuery UI module, and had the lovely experience while writing that of the file names, included libraries, APIs, etc. totally shifting out from under our feet at least 3 times in as many months.

We're basically in another situation like we found ourselves in in Drupal 5: the version of the external library we ship with is going to end up being totally obsolete by the time Drupal core becomes stable enough to ship, making something like jQuery UI Update module in contrib an absolute requirement in order for Drupal to remain competitive, since the jQuery plugin authors don't tend to support "ancient" versions of libraries. The difference being that "ancient" to us is 3-4 years, and "ancient" to them is more like 6-8 months. It's always been interesting relying on third-party libraries with an even faster "Drop is always moving" than us. ;)

So, my thought was to couple this issue with a centralized, alterable, plugin registry/manager so that we we wouldn't need stupid hacks like jQuery UI and jQuery Update module in contrib anymore, and also because while writing jQuery UI module, jjeff and I desperately looked for "the" solution to adding additional libraries in contrib so we wouldn't have to write a wrapper module for jQuery UI and create "yet another way" of adding some JS to a page. Therein we found 4-5 different modules that all did the same thing and decided that it was easier to write yet another one than leverage the existing solutions.

Therefore, the time seemed ripe to push core to take on this responsibility, rather than kicking it to contrib to deal with. However, I wasn't counting on said issue ballooning into like 200,000 replies, being so contentious within the larger JS developer community, and taking over a year to complete. And the fact is that we need the jQuery UI stuff in *now* in order to proceed on D7UX work.

So if we choose to keep with the status quo, which is "making Drupal able to stay agile with what happens with development of our external JS libraries is the job of contrib to somehow figure out," then I guess what we should probably do is just dump the entire library (excluding tests) into misc/jquery/. After that... not sure. I'm not thrilled about adding Yet Another Way To Add Certain JS On The Page, so I'd rather *not* have both drupal_add_js() and jquery_ui_add(). But there are dependencies in jQuery UI land, so you can't just add Draggable without also adding some of the core libraries.

Just worked on form_builder to Drupal 7, another module enjoying dependence on jQuery UI. Looks like updating the module from jQuery 1.2 to 1.3 and jQuery UI 1.6 to 1.7 did not took any considerable JS changes. I think we had only one JS change due to how draggables connecting to sortables changed. Other JS changes where how clear-block changed to clearfix in Drupal or how Drupal enforces ($)(jQuery) wrapped code now. I think this underlines again that it might not be that scary to include jQuery UI and not update it later.

#404818: Port form_builder to Drupal 7

Steps to proceed:

1) Mark #92877: Add numeric weight to drupal_add_css as critical. (done)

2) Agree on the library variant to add to core: source, minified, or packed. (My vote would go for minified for various reasons, also for misc/jquery.js)

3) Extract jQuery UI into misc/jquery-ui, remove its tests, companion files, and not used library variants (depending on 2)), and commit.

4) Open new issues to replace a few custom scripts in core with jQuery UI effects (the original intent of this issue).

For 2), I'm pretty sure we don't want 192K of JS loaded on every single page, no? (well. more than that. 192K is the packed version.)

I don't see a packed/minified version of the development bundle that has each file in there separately so a module can selectively load certain ones on the page, unless I'm missing it.

We don't automatically include them on every page, just on those pages that specifically request it.

Agreed with @sun (#78). I think we should follow the same pattern as with jquery.js in terms of the type of the library, so we ship with the same.

Of course, we don't use the big, monolithic, customizable package from jquery.com. We follow the installation instructions for jQuery UI module: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/jquery_ui/R...

@sun: Ok. Then the answer to #2 seems clearly to be "the source version," and we'll let Drupal's built-in JS aggregator/compressor handle packing/minifying?

Also, we can't call this issue "fixed" until modules have a way to add jQuery UI elements. Or are we just going to make modules do:

drupal_add_js('misc/ui/ui.core.js');
drupal_add_js('misc/ui/ui.draggable.js');
drupal_add_js('misc/ui/ui.tabs.js');
drupal_add_js('misc/ui/effects.core.js');
drupal_add_js('misc/ui/effects.fold.js');

@webchick: As said above multiple times, jquery.js in core is not a "source" version either. Also, why supporting jQuery UI via drupal_add_js() is not fixing "adding jQuery UI" to core? The core/contrib JS files already have this dependency problem, so solving it might be something you set out to put a requirement for this issue or to consider as an independent issue which is a task regardless of jQuery UI in core or not.

I have to agree with Gabor here:

- the packaging type of jQuery UI should be the same as jquery.js (ie. "packed"), the Devel module could use hook_js_alter() to load another version during development if required
- just use drupal_add_js() for now, and load the dependencies explicitely

Gabor: Sorry, really not trying to be difficult here... just trying to impart things we learned from writing the jQuery UI module.

1. jQuery UI is fricking big: something like 25 separate possible components.
2. But, you don't want to tell people "Our content management framework ships with jQuery UI 1.7.2" without giving them ALL of jQuery UI 1.7.2 at their disposal. Otherwise you have to say "Our content management framework ships with select, arbitray parts of jQuery UI 1.7.2 that we needed for core's specific purposes. If you want anything else than that, you're on your own."
3. jQuery UI only provides a packed/minified version of the *entire* library, which is 192K. They do not provide packed/minified versions of specific components.
4. On a given page, you do not want ALL 192K of jQuery UI. You want maybe 4 files. So you should be able to say the ones you want individually.

I don't know of a way to achieve #4 without keeping the individual files separate, which means shopping with source versions unless I'm wrong about #3.

@webchick #76 "I'd rather *not* have both drupal_add_js() and jquery_ui_add(). But there are dependencies in jQuery UI land, so you can't just add Draggable without also adding some of the core libraries."

You don't need to have jquery_ui_add. Adding the files is the job of the developer using them. If I add functionality to core or in contrib that needs Draggable is my job to add the right files for it to work.

Ah-ha. :) Sun has informed me that the development bundle over on Google code - NOT the full version available on their website as it was the last time I looked - has the individual files as minified version. /me needs to not assume instructions she wrote 6 months ago still apply in jQuery UI today ;)

@webchick: Even if they are not shipping it in a certain format, we could still always do the conversion and ship that way ourselves, no? I don't believe it is against some rules or that it would be rocket science.

Also, jQuery UI comes with minified versions. At least the package I download and use from http://code.google.com/p/jquery-ui/downloads/list as suggested by the jQuery UI contrib module (also said by @sun above).

One other thing to note about minified vs. source is that all of the files will have .min.js as their extension. This means that the code above would actually be:

drupal_add_js('misc/ui/ui.core.min.js');
drupal_add_js('misc/ui/ui.draggable.min.js');
drupal_add_js('misc/ui/ui.tabs.min.js');
drupal_add_js('misc/ui/effects.core.min.js');
drupal_add_js('misc/ui/effects.fold.min.js');

That seems right nasty to me. We could also rename the files prior to commit, but that's also a pain. I'm not sure how it works with using JS compression on an already minified file, but I'm assuming it's ok since we compress jquery.js?

We only aggregate JS, don't compress. There was some development period in Drupal 6 where we did have compression, but it did not work well, so it was removed before release. Help text quote:

CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed).

@Gábor: Right, sorry. Learning on the fly here. :D

Ok. So it sounds like the only remaining question is shipping with minified vs. source. While source is easier for debugging:

a) We already ship a compressed version of jQuery and jQuery Forms (although it's packed, not minified, but sun has informed me that minified is faster so we should likely change even those to minified in another issue)
b) We should optimize for end users, not developers.
c) It's always possible while debugging to "hack core" to replace a copy of the code with unpacked versions if you're having troubles.

So it sounds like the plan of attack is:

1. Create misc/jquery-ui
2. Copy the contents of jquery-ui-1.7.2/ui/minified there.
3. Remove misc/jquery-ui/jquery-ui.js (since that appears to just be a smooshed together copy of everything else)
4. Go through and rename all of the files from *.min.js to *.js
5. Commit.

Outstanding question: Do we ship with the i18n folder? Does anyone know what that does?

Here is a first patch, extracted from http://jquery-ui.googlecode.com/files/jquery-ui-1.7.2.zip:

- moved minified version in misc/ui
- removed the i18n files (only used by the date picker, those are not compatible with our translation framework)
- moved the base jquery-ui.css into misc/ui

For committers: please extract ui-images.tar.gz into a new misc/ui/images directory.

IMHO, we should leave the decision about the compression type/mechanism to the site builder and hence, only add source files to core. However, not being bold on this issue, because jquery_update module is able to alter the files to use uncompressed variants anyway.

Better version:

- removed the jquery-ui.js (that contains everything else)
- removed jquery-ui.css, and remplace that with per-element css files.

Still needs to extract ui-images.tar.gz into a new misc/ui/images directory.

@sun: if we ship with the source versions, then we are not really giving options to the user, since there is no compression of JS in Drupal core, so they cannot choose the right version. So we should put the user in front and ship witht he minified version. Then as Damien echoed above, we discussed here that devel module could ship with source versions of whatever we have minified, so developers can debug their JS code. The altering of JS is open to devel, so it can provide a more developer friendly version of the code.

// $Id: tags are missing in the patch. How are we able to solve the i18n issue?

Once #98 is addressed, we can probably proceed with committing this.

And here with #98 addressed.

And the correct patch.

Ok. Committed to HEAD, along with a CHANGELOG.txt entry.

For the i18n stuff, we decided to leave that out for now, since we ideally want this integrated with our own translation system. Will have to address this when we get around to looking at Datepicker, which is currently the only translated script in jQuery UI.

What are the follow up tasks for this?

Can we list those tasks here even if they are opened with new issue number? For example, is there a task to replace Farbtastic and the jQuery UI Color Picker?

As for translation, which tasks are required? I would definitely offer my help in translating this library in French.

Edited. Removed the double posting.

Let's use the "jQuery UI" tag (although listing them here is obviously not bad either)

I would think that this merits an entry in both the theme and module upgrade pages.

GOOD point! :)

Laissez les bon temps roulez

er - what ? ;-)

Let the good times come (I think) :)

Let the good times roll :)
It's New Orleans speak for "Yay! Let's party."

To start the party, I've added these docs following Moshe's suggestion:

http://drupal.org/update/modules/6/7#jquery_ui

jQuery UI (1.7) was added into core.

(issue) jQuery UI 1.7 was added into core. You can find the jQuery UI files in misc/ui and can add Javascript and CSS files from there to your pages with the regular drupal_add_js() and drupal_add_css() calls, no special function calls required. If you are migrating a module or custom code which was previously dependent on the jquery_ui contributed module, the difference in usage is:

Drupal 6 with jquery_ui module:

jquery_ui_add(array('ui.draggable', 'ui.droppable'));

Drupal 7 core:

drupal_add_js('misc/ui/ui.core.js', array('weight' => JS_LIBRARY + 5));
drupal_add_js('misc/ui/ui.draggable.js', array('weight' => JS_LIBRARY + 6));
drupal_add_js('misc/ui/ui.droppable.js', array('weight' => JS_LIBRARY + 7));

Note that you need to make sure that the weights are set appropriately for dependent elements and that component dependencies are included on the page.

Drupal ships with the minified versions of jQuery UI files, just like we do in case of jQuery itself.

Also added to the theme docs:

http://drupal.org/update/theme/6/7#jquery_ui

Added jQuery UI (1.7) to core

(issue) jQuery UI 1.7 was added to core. You can find the jQuery UI files in misc/ui and can add Javascript and CSS files from there to your pages with the regular drupal_add_js() and drupal_add_css() calls, no special function calls required. If you are migrating a theme which was previously dependent on the jquery_ui contributed module, see the module update guide on the topic, which provides examples.

About the weight of javascript files, please see #505528: JS files of the same weight are not included in the order of the calls.

No need for re-testing. This issue has long been committed to core.