type: widget
release: N/A
priority: none
status: in planning
documentation: N/A
demo: LABS
1 - Description:
A file uploader extends the default single file browse tool with to allow for a custom UI for providing feedback, the ability to upload multiple files at once and a real-time progress bar for upload feedback.
A few jQuery plugins provide all or some of this functionality:
http://plugins.jquery.com/project/MultiFile/
http://www.fyneworks.com/jquery/multiple-file-upload/
http://15daysofjquery.com/multiple-file-upload-magic-with-unobtrusive-javascript/17/
http://jquery.webunity.nl/jQuery.uploader/landing (this is the latest version of the plugin that was documented on the jQuery site at http://docs.jquery.com/UI/Uploader)
http://blogs.bigfish.tv/adam/2009/06/14/swfupload-jquery-plugin/
http://www.alexandremagno.net/blogs/jqswfupload/
http://www.uploadify.com/
2 - Visual Design:

3 - Functional Specifications/Requirements:
All functionalities need to work independent to each other
- File input replacement
- this should be the basic functionality
- Ajax
- upload file ( or files ) without leaving the page
- Queue
- provide an option so that a user could select multiple files and upload them at once
- Flash
- this is required only for the progress bar
How to achieve the functionalities
File input replacement
This should be optional, the user may use any object as a uploader ( images, links etc ). Since we can't trigger a click event for a file input we have to improvise.
We need to create a file input right near the selector, because the file input might be used in a form.The thing that all the plugins have in common is that it creates a file input at the cursor's position when it hovers the element.
This is pretty easily, we must get the object's coordinates ( offset left, offset top, width and height ) and when the event meets the conditions display the file input. But we must be careful because the button may change it's position or dimension.
So it's better to take in consideration a method that would recalculate the coordinates based on the current position and dimension.

Ajax
If the user enables ajax it's better to wrap the file input in a form and append it to the <body> tag, but also create an iframe for submitting the form to.
Ajax being enabled, we also create events such as ajaxsubmit and ajaxcomplete .
Queue
Coming soon
Flash
Coming soon
4 - Markup & Style:
4.1 Initial markup examples
(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )
4.2 Recommended transformed HTML markup
(The HTML markup structure and classes that will be used by the scripts in the enhanced version)
4.3 Accessibility recommendation
(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices)
4.4 CSS & Theme
(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.)
5 - Latest version of plugin:
(Link to the latest version in the jQuery UI trunk here)
6 - Open issues being discussed
(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)
Comments (39)
Jonathan Gotti said
at 5:15 pm on Jun 2, 2009
It must be considered to achieve this that the server side must be abble to send feedback on the upload state.
For example php on it's own can't achieve this without rarely installed extensions.
Gilles said
at 3:29 am on Aug 19, 2009
When using a Flash based version this is doable. There is also the possibility to add a CGI backend, to allow more flexibility. However, this needs some additional configuration.
Ca-Phun Ung said
at 4:32 am on Aug 19, 2009
Hey Giles,
I set the status back to "in planning" and demo link to "n/a". Links in the header should always point to resources in the UI repos.
jQuery.uploader looks really good and feature complete. Were you intending to add your plugin to UI?
scottjehl said
at 8:15 am on Aug 19, 2009
This plugin looks nice.
Is it possible to develop this plugin in a way that doesn't depend on Flash? Or at least only using Flash if it's available? Also a solution that does not need to be configured to align with the backend would be ideal as well.
The first priority should be to make a native file input customizable in appearance and behavior. This portion shouldn't require Flash or any backend configuration.
I've seen some nice plugins that manipulate an input type=file element with some additional elements to at least make a single file uploader configurable with CSS and JS.
Here's one I've used that worked quite well (you apply the plugin to an element which could replace a file input, it doesn't use Flash, and submits using a generated iFrame):
http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm
it works by actually using a hidden file input positioned over the clickable button, so you actually click the native input button while using it.
Obviously, this plugin isn't as full-featured as the example posted above, but it's a nice solution for configuring a native file input element, and then we could provide options for things that might require Flash, such as reporting upload progress back to a UI progressbar widget, uploading multiple files, and more.
Thoughts?
Gilles said
at 9:57 am on Aug 19, 2009
@Ca-Phun ung:
yes i have been thinking about this for over 2 years (that is, i have suggested it many times but due to the fact that everybody is very busy, it just never came off it). I started today to convert my jquery.uploader to jQuery.ui.fileuploader (as in: rewriting to confirm with jQuery UI). As per Scots request (and the fact that i have seen it on other plugins which are MIT licensed) at first i am just "converting" my plugin, meaning it requires flash and basically works just like the plugin above but then using UI standards. Then we can think about other formats (both front-end as backend).
The main problem here is that this plugin can't be used "out of the box" you have to do some event handling and backend programming in order for it to work, but that should all be self explanatory when you take a look at the demo's. I've decided to use SWFobject (also MIT licensed) for Flash detection since you can build that into the plugin, but better is to not reinvent the wheel. I'll keep you guys updated.
Ca-Phun Ung said
at 10:32 am on Aug 19, 2009
I see, that's good news! I'm glad you're willing to contribute your code.
Do you want to add this stuff to the UI labs? I'm not sure if you have commit access?
I think we could have the JS and demo page on the UI repos with Flash and backend code on your server (if you're willing)?
I think FileUploader could become something of a standard API that anyone could create their own Flash/Backend scripts to work with as long as they adhere to the FileUploader API. Rather than focus on Flash we should focus on the JS.
Gilles said
at 2:07 am on Aug 20, 2009
On your last line; that is kinda hard. Since the entire callbacks and multi-file selection is all based on Flash. Lets first add this to the labs (no i don't have write access yet) and lets see how we can evolve from there.
Ca-Phun Ung said
at 3:13 am on Aug 20, 2009
Yes, it's a long shot but I think it's something that would set this UI plugin apart from the rest. Basically it's the same but I'm looking at it from the JS side. We define a set of API calls for the FlashUploader to adhere to and that is what sets the standard.
I agree that we should first get what we have converted to UI then develop from there.
Jörn Zaefferer said
at 6:14 am on Aug 20, 2009
That make sense, considering fileupload support in HTML5, eg. as implemented in Firefox 3.5. In the long term, Flash should be just an optional implementation, not the API.
Jörn Zaefferer said
at 2:13 pm on Aug 19, 2009
Can you replace SWFObject with the flash plugin? http://jquery.lukelutman.com/plugins/flash/
Gilles said
at 2:06 am on Aug 20, 2009
I've replaced SWFObject with the flash plugin. Didn't think it was so easy ;)
Gilles said
at 7:58 am on Aug 24, 2009
Well, i've removed the jQuery flash plugin from my project since it produced embed tags in IE. This way my externally exposed functions are not callable. I've reverted it back to my own (old but functioning) code which is a combination of jQuery.flash plugin (for Flash detection) and some code from the Flash detection kit. Anyway; demo1 (see url on top of the page) is working again, so i'll think i'll add the project to the labs in a few days.
Ca-Phun Ung said
at 8:03 am on Aug 24, 2009
Great, thanks Gilles!
Gilles said
at 4:34 am on Sep 8, 2009
Guys i added the first demo (and complete source) to the labs, please tell me what you think of this.
Ca-Phun Ung said
at 9:25 am on Sep 9, 2009
Wohooo! Gonna check this out over the weekend! Thanks :)
valums said
at 3:56 am on Nov 2, 2009
Hi,
I am an author of AJAX Upload plugin http://valums.com/ajax-upload/ ,
and I would like to help developing a jQuery UI widget.
As I see, Gilles is already in process of creating a flash based widget,
and I would like to know what do you have right now.
I was thinking that it would be great if Flash was only required if developers
would like to see the progress-bar, but for others (that have trouble with Flash upload
because of the server settings), and for users without Flash,
and for newer browsers (which support XHR progress event and File API)
files uploads would be done with JavaScript.
Here is a list what's currently possible with the pure JavaScript.
In all browsers
Multiple file uploads using upload button styled with CSS
(http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm)
Safari 4, Opera and upcoming Firefox 3.6 support selecting multiple files using file selection dialog
<input type=”file” multiple> Safari, Firefox
<input type=”file” min="0" max="73"> Opera
With Safari 4 and Firefox 3.5 it is possible to show upload progress using XHR onprogress event,
but in my opinion it's too costly to implement it right now.
What do you think?
Scott Allen said
at 1:21 pm on Nov 3, 2009
Our business is looking for this exact kind of widget. We haven't found anything that works really well for multiple files with a progress bar. My boss and I are wondering if you know when this widget might launch - if you have a deadline time frame?
Scott González said
at 6:18 pm on Nov 3, 2009
This is currently not a prioritized plugin, which means at the earliest it could be a candidate for middle of next year, but as of right now there is no planned release date.
Basit said
at 3:31 am on Nov 24, 2009
i want to work on this widget, i been using mootool fancy uploader and customized it, which is great tool for multi-uploader, anyway this project seems like at halt position and i want to get started on this and finish it. let me know how is managing this project and what we need to do to get this back on track and finish it up. its been 2 years for this project. its time to finish it up.
Scott González said
at 8:57 pm on Nov 24, 2009
Hey Basit, as mentioned in the comment directly above yours, this is not a prioritized widget. This means that the team has not been working on this for two years (we're not even working on it right now). However, if you've got time to work on it, you can certainly create a plugin that uses the widget factory, conforms to our coding standards and is well documented and tested. If the plugin proves to be reliable and useful, we can look into pulling it into jQuery UI.
Yanick said
at 7:29 am on Nov 24, 2009
A few years ago, I have used SWFUpload on one project. It does require flash to be installed, but who doesn't have flash nowadays? The plugin supports multiple file selection and can fire all the necessary handlers to customize it at will. It doesn't have a frontend (no interface), so it can be replaced once it is no longer needed. I believe that this is a small compromise for those really seeking multiple file uploader widget right now.
http://swfupload.org/
Basit said
at 10:44 pm on Nov 24, 2009
@Scott Gonzalez great to hear that, yes i can do that, but before i start on it. i need to know what your guys coding standards are, well i been working for 10 years, so i dont think there will be problem, but still want to know and also what are the requirement fot this plugin (widget), so i can create exactly as it requires (or more better). you can check fancyUpload (mootool), its really good, i can build something like that, if its fill the requirements. http://digitarald.de/project/fancyupload/ (fancy uploader in mootool)
Scott González said
at 8:44 am on Nov 25, 2009
As Jaggi said, there are links to some of this information in the sidebar. However, there's a lot of missing content (I know because I wrote them). The relevant pages are:
http://wiki.jqueryui.com/Widget-factory
http://wiki.jqueryui.com/API
http://wiki.jqueryui.com/Coding-standards
For coding standards, read the Coding-standards page and just look through some of our existing code (dialog, progressbar and position should be good examples). Feel free to also just ask any questions on the jquery-ui-dev mailing list. The hardest part will be getting specs for this plugin because the team is in a crunch for the 1.8 release right now. You can start putting together some specs on this page and then just ask for feedback, just be aware that it may be a bit of a slow process. The more minimal the API is, the more likely it is to be approved.
Basit said
at 9:34 am on Nov 25, 2009
thanks for the links. ya ill write the specs and go from there. but so far i know myself and jquery team, its most likely will be approved. anyway thanks and ill write specs soon.
Jaggi said
at 6:17 am on Nov 25, 2009
@Basit look at the top of the page in the right area, theres a area called " sidebar" with all the links you need.
Basit said
at 8:12 am on Nov 25, 2009
@Jaggi thanks for the tip. i noticed the uploader on UI/uploader documentation is not completely free and opensource (http://docs.jquery.com/UI/Uploader). it needs a flash file to work properly and the guy who created it, he is charging money for it lol, cause he said it was hard writing 2000 lines, so he has to charge it. i recommand jquery guys to remove that uploader from documentation. i will definitely work on the uploader and opensource the flash file also, so everyone can access and update it from github. anyway, thanks again. ill get on it and launch the plugin at http://basit.me
Yanick said
at 8:35 am on Nov 25, 2009
Like I said, if you want to use a flash component as backend (at least until HTML support the same features natively), take a look at SWFUpload. It is free, signed, and have been tested for a while now by many people. It does not have an interface, so it is controlled strictly via handlers and functions through Javascript. (ie: opening file; swfUploader.browse(); this will open the flash "open file" dialog with multiselection capabilities, and for each selected file, a callback will be invoked with the fileInfo as argument (size, name, etc.) I guess the flash file could be inserted into the DOM automatically also, hence users would only require the ui-upload.js plugin (or even the single packed ui.js file) and everything would work straight out of the box. Writing the UI from the given specifications with SWFUpload is a breeze! And no server side scripts required. I'm pushing this idea because, so far, everything that has been spoken is fulfilled by SWFUpload. If not, I would like to know why? :)
Basit said
at 9:30 am on Nov 25, 2009
well everything is possible, but response back from the backend is also must, some people like myself uses for checking the responses and errors and limitations. but response back should be optional and everything should work out of the box and everything should be changeable also. no limitations and no restrictions.
Yanick said
at 10:03 am on Nov 25, 2009
getting server side state can be done with the onComplete event callback from the SWFUpload component...
Scott González said
at 8:45 am on Nov 25, 2009
Thanks for pointing out that documentation page, I've moved it to Plugins/Uploader so there is no longer any content under UI/Uploader since that was not a UI plugin.
Gilles said
at 2:36 am on Jan 12, 2010
Basit that is not fair; i am not charging any money for the flash file, all can be downloaded and is documented right off my site. I only asked (past tence) money for the source which is fair i guess. It took a lot of time and thinking to get it right.
--> I fully open sourced the project and added it to SVN some time ago; http://jquery-ui.googlecode.com/svn/branches/labs/uploader/ <--
So the full actionscript code is there; sitting to be 'checked' by the UI team but as Scott said; it is not a prio right now. I am using my own plugin allready on my own projects.
Basit said
at 4:04 am on Nov 26, 2009
there are few issues i wanted to talk about with you guys. there are few options i was thinking to add as per requirement from above image. adding an uploader on a file browse should not need an third party plugin (flash) in order to work, simply with $('input').uploader(); should start working instantly. but there is issue on progress bar. in order to have real time progress bar we need flash or get it done from backend and knowing that we cant put must require the third party, so the only way to do progress bar is on sent the request (50% complete) and on receiving the request (+50% complete) done, so that is 100%. if you guys want me to do it like that, then thats fine, we can do that, but if not, then share your thoughts how you want the progress bar to be achieved in the uploader? obviously i havent started to code, but im just planning first and then put all the options and requirement and then start building. anyway waiting for answers from you guys :).
Yanick said
at 8:30 am on Nov 26, 2009
Even when using flash, the code can still be $('selector').upload(); and the plugin can add the embedded flash player dynamically. Or it can simply rely on the server side to provide feedback. My opinion on this is this :
Pros to use flash for the plugin (temporarily until HTML supports file upload progress natively) :
- if flash is not available, the default input file will act normally (no progress)
- do not depend on server side at all and respect the 100% client side nature of JQuery
- increase the standard across browsers (some minor issues between OS and flash, but they are minor, and we can still degrade it to the HTML element only if needed)
And the cons:
- depends on flash
- the onProgress event with flash does not work at all on some OS and defeat the purpose of using flash, less multiple file selection capabilities
- flash use it's own session cookie when transferring files. This can be problematic for sites that require authentication when uploading files. A solution would be to fire a normal http request right after to tell the server that the specified file belongs to which user, but can be an undesirable process.
Yanick said
at 8:31 am on Nov 26, 2009
"Flash-less" solutions rely on server side scripts to handle the request, but PHP has still not provided good support for it, and other solutions (a la Google) requires Python. While Python is installed on most web servers (Linux), it is not desirable to couple JQuery with a server side script. At least I'm strongly against it.
Flash, on the other hand, is a temporary solution that works "well" on all major browsers, and should be able to degrade gracefully (like SWFUpload). The UI for the widget should be the same regardless if flash works or not. If it works, the normal behavior will be shown, with progression feedback. If not, the plugin should rely on other methods, perhaps an hidden iframe, to provide the necessary mecanism and fire, at least, the onComplete event and download the next. If all fails, the plugin could simply add the input file element, and wait for the form to be POSTed and processed as a standard form.
I know using flash is a reluctant idea, but none so far proposed a solution otherwise, or actually debated on the subject.
Scott González said
at 10:11 am on Nov 26, 2009
The project does not share your stance on not coupling plugins with server side scripts. Such a restriction would make several plugins very difficult or impossible to implement. Honestly, for many situations I'd rather see a server side solution than a flash solution. Server side solutions take advantage of the open web.
Gilles said
at 2:45 am on Jan 12, 2010
Well i have thought about coupling it with a few other things like:
- Browserplus (yahoo tech, which would make drag & drop uploads possible) mainly improvement on the client side
- Serverside CGI script (limit parralel uploads, but gives feedback)
- And flash off course
But; it is mainly a choice that the project team has to make; are you willing to implement a plugin depending (for a part) on Flash; just like EXT and YUI allready did? That is the main question holding things back really. I have been discussing this plugin with paul long before this wiki was here, so just to give you an idea on how long i have been working on it ;)
Scott González said
at 10:09 am on Nov 26, 2009
Faking 50% and then reporting 100% on completion sounds fine. The plugin should be built in a way to allow another script to be loaded that adds flash support to the plugin to get a more accurate progress.
Basit said
at 8:46 am on Nov 26, 2009
well so far i know, flash is must for two things. one is progress bar and second is the multiple instance (able to select 10/100 files at once).
ya i agree, we should not rely from server side or from flash, but flash can be used, if user wants it for using multi-instance or progress bar. but if flash is not used, then the solution i gave for 50% on trigger and 50 on receiving a response from client, can be good thing. i think that would be best solution for us, without relying on third party.
Yanick said
at 10:26 am on Nov 26, 2009
What about, then, using an adapter?
ie: $('selector').upload({ adapter: 'flash' }); // 'flash'=Flash based uploader, 'ajax'=server side ajax based uploader, null=standard uploader
Common options would be event callbacks, and other settings (max file count, etc.), and depending on the adapter, also have other options:
ex: $('selector').uploader({ adapter: 'ajax', uploadUrl: '/path/to/upload', progressUrl: '/path/to/progress', onProgress: callback1, onComplete: callback2, .... });
ex: $('selector').uploader({ adapter: 'flash', uploadUrl: '/path/to/upload', multiselect: true, fileCount: 10, onProgress: callback1, onComplete: callback2, .... });
etc.
You don't have permission to comment on this page.