Drag'n'Drop Uploads - Revision history

Annevk: /* Related implementations */

2011-01-26T12:09:38Z

Related implementations

← Older revision		Revision as of 12:09, 26 January 2011
Line 94:		Line 94:
	IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.		IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.

	[[Category:~~Feature Request~~]]		[[Category:Proposals]]

Mabdul: adding Category:Feature Request

2008-12-01T11:27:57Z

adding Category:Feature Request

← Older revision		Revision as of 11:27, 1 December 2008
Line 93:		Line 93:

	IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.		IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.

			[[Category:Feature Request]]

KornelLesinski at 13:47, 2 May 2007

2007-05-02T13:47:37Z

← Older revision		Revision as of 13:47, 2 May 2007
Line 89:		Line 89:
	* 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).		* 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 <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.		* 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 <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

			== Related implementations ==

			IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.

KornelLesinski: /* The basic concept */

2007-04-26T20:39:47Z

The basic concept

← Older revision		Revision as of 20:39, 26 April 2007
Line 19:		Line 19:
	=== The basic concept ===		=== The basic concept ===

	A universal IDREF attribute that would connect particular element in document with a <code><input type=file></code> control.		A universal IDREF attribute that would connect particular element in document (''drop zone'') with a <code><input type=file></code> control.

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

	In the above example, ~~when file~~ is dropped ~~onto~~ <div>~~, browser~~ would "~~redirect~~" the ~~file to~~ <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.		In the above example, files is dropped into <code><div></code> would be "redirected" to the <code><input></code> element. <code><input></code> can use <code>max</code> 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~~ <code><input></code> ~~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~~ <code><~~input type=file~~></code> ~~hardcoded~~.		Drop zone doesn't have to be <div>:

			<textarea dropped-files=''uploader''>write post and drop images to have [img]url[/img] added automagically!</textarea>

			Algorithm also allows dropping files directly into <code><input></code>, without requiring any additional code.

			<input type=file title="drop files here!">

			Drop zones can be nested (deepest-nested takes precedence). For ease of implementation and compatibility with HTML4 documents, <code><form></code> can act as a drop zone (with least precedence).

	=== The process ===		=== The process ===

KornelLesinski: /* Open Issues */

2007-04-26T20:24:38Z

Open Issues

← Older revision		Revision as of 20:24, 26 April 2007
Line 59:		Line 59:
	# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.		# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

	=== ~~Open Issues~~ ===		=== Security ===
	~~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?~~		Dropping is limited to one DOM tree (does not cross frames). Scripts still can't set value of <input type=file>.

	~~Since the solution requires form~~ and <code>~~<input>~~</code> ~~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~~.		The only new risk is that script may know exactly when user has chosen a file and may start uploading it immediately (IIRC currently major browsers don't trigger <code>change</code> event on file controls).

	Many elements could reference single <code><input></code>. 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~~.		Browsers which used to open files dropped into document area will probably have to ask user for confirmation when first file is dropped to prevent websites from stealing files from users unaware of the new feature.

	~~Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?~~		=== Open Issues ===

	~~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~~).		==== Filesdropped Event ====
			* It should reference relevant <code><input></code>
			* Provide some information about dropped file(s) (file name, mime type, size?)
			* If possible, provide information about exact place where event occurred (using <code>Range</code> object for WYSIWYG?)

	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 <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.		==== Other issues ====
			* 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 canceling <code>filesdropped</code> event enough?
			* Since the solution requires form and <code><input></code> 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 <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that authors prepare 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 <code><canvas></code> 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 <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

KornelLesinski: /* The process */

2007-04-26T20:04:35Z

The process

← Older revision		Revision as of 20:04, 26 April 2007
Line 29:		Line 29:

	=== The process ===		=== The process ===

			==== Finding related <input type=file> ====

			These steps are supposed to allow dropping files directly into <code><input></code>, or into a designated drop zone. As a fallback a <code><form></code> can be assumed to be a drop zone.

	When user drops file(s) into the document:		When user drops file(s) into the document:

	# Take element on which file(s) were dropped (~~that~~'s target of <code>mouseup</code> event)		# Take element on which file(s) were dropped (''drop target'') - usually it will be target of <code>mouseup</code> event.
			# If the element is <code><input type=file></code> '''proceed to the next section.'''
	# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.		# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
	# If ~~no ancestor~~ with <code>dropped-files</code> was found~~, ignore dropped files or perform browser's default action and abort these steps.~~		# If element with <code>dropped-files</code> attribute was found:
	# Find element referenced by <code>dropped-files</code> attribute ~~and verify~~ it's <code><input type=file></code>. ~~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.		## Find element referenced by <code>dropped-files</code> attribute
	# ~~Set value of <input> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits)~~		## Verify that referenced element it's an <code><input type=file></code>
	# ~~?? Fire~~ <code>~~change~~</code> ~~event (~~<code>~~formchange~~</code>? <code>~~filesdropped~~</code>~~?) [ on which element?~~ <code><input></code> or ~~drop target? how would one find where files were dropped?~~ (~~Range object with position within related textarea/contentEditable would~~ be ~~useful~~) ]		## If above conditions are met '''proceed to the next section.'''
	# ?? Should the form be submitted automatically? For example form could be submitted asynchronously unless script objects to it using <code>preventDefault/stopPropagation</code> of <code>filesdropped</code> event		## Otherwise ignore dropped files or perform browser's default action and abort these steps.
			# Start again from the ''drop target''
			# If the element is not <code><form></code>, check its parent. Continue checking ancestors until <code><form></code> is found or there are no more parent elements.
			# If <code><form></code> is found:
			## Find first <code><input type=file></code> that belongs to that form
			## If element can be found, '''proceed to the next section.'''
			# Otherwise ignore dropped files or perform browser's default action.

			(this algorithm can be optimized to walk up the DOM tree only once)

			==== The next section ====

			# Synchronously fire <code>filesdropped</code> event on ''drop target''
			# If <code>filesdropped</code> event was cancelled, ignore dropped files and abort these steps.
			# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

	=== Open Issues ===		=== Open Issues ===

KornelLesinski: New page: === 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...

2007-04-25T23:04:12Z

New page: === 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...

New page

=== 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 <code><input type=file></code> control.

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

In the above example, when file is dropped onto <div>, browser would "redirect" the file to <code><input></code> element. <code><input></code> can use <code>max</code> 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 <code><input></code> 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 <code><input type=file></code> hardcoded.

=== The process ===

When user drops file(s) into the document:

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