Drag'n'Drop Uploads

The problem

Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

Use cases

• Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
• Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
• Adding attachments in a webmail
• Web-based file browser/asset management interface
• Drag'n'drop customization of images in page templates, forum avatars, etc.

Proposed solution

The basic concept

A universal IDREF attribute that would connect particular element in document with a <input type=file> control.

<input type=file id=uploader>
<div dropped-files=uploader>drop your files here!</div>

In the above example, when file is dropped onto

, browser would "redirect" the file to <input> element. <input> can use max attribute to allow multiple files to be dropped at once.

Note: alternative approach would be to use DOM event triggered when a file is dropped. That could be much more flexible, but probably would require giving JS method for passing file information from event object to chosen <input> element - with complexity of DOM events and inherent insecurity of JS prototypes it could be too difficult to implement securely. With IDREF browser can keep full control and have process of setting <input type=file> hardcoded.

The process

When user drops file(s) into the document:

1. Take element on which file(s) were dropped (that's target of mouseup event)
2. If the element does not have dropped-files attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
3. If no ancestor with dropped-files was found, ignore dropped files or perform browser's default action and abort these steps.
4. Find element referenced by dropped-files attribute and verify it's <input type=file>. If this element can't be found or is not a file input, ignore dropped files or perform browser's default action and abort these steps.
5. Set value of <input> just as if files were chosen using regular method (including setting multiple files if max attribute permits)
6. ?? Fire change event (formchange? filesdropped?) [ on which element? <input> or drop target? how would one find where files were dropped? (Range object with position within related textarea/contentEditable would be useful) ]
7. ?? Should the form be submitted automatically? For example form could be submitted asynchronously unless script objects to it using preventDefault/stopPropagation of filesdropped event

Open Issues

What's the best way to get information about dropped files and where event has occurred? It will be needed for inserting markup into WYSIWYG/textarea.

How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property (and clearing value of <input>) enough?

Since the solution requires form and <input> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.

Many elements could reference single <input>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that there were separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.

Would it be possible to have previews of images and documents available prior upload? Import into <canvas> without upload?

Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).

If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <from replace=values> and hidden input element or <from target=hidden_iframe> and cross-frame scripts.