- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 16 Feb 2010 03:48:04 -0800
On Tue, Feb 16, 2010 at 1:58 AM, Stef Epardaud <stef at epardaud.fr> wrote: > On Tue, Feb 16, 2010 at 01:47:04AM -0800, Jonas Sicking wrote: >> This is something I've been thinking about too. >> >> First of all, what is the use case? Once we have the FormData object, >> you will be able to submit processed files using XMLHttpRequest >> easily. So why do you want to use <form>s? >> >> Another problem is that if this is a displayed <input type=file>, then >> the user could overwrite the processed file with a user-selected file >> at any time. This seems undesirable. >> >> Trying to get a feel for what you're trying to build to make sure that >> we have all use cases covered. > > The rationale is simple: a JS action can filter what the user types in a > <input type=text>, and still allow the <form> to be sent regularly > (non-AJAX). Why not the same for files? In my use-case I have two > different options, sending processed files using XMLHttpRequest, or with > a normal <form> submit. XMLHttpRequest gives me better progress > notification (how I wish we could get progress notifications for a > regular <form> when POSTing), but if the set of processed files is part > of a <form> with more input elements (in the case of photos, comments, > date, whatever), it is simpler to use the regular <form> submission, and > just filter the selected Files as the user adds them to the <input > type=file>, process them, then replace them in the <input type=file>. If > the user then changes his mind about the selected file list, hey it > still works. If you have the FormData object [1], then why is it simpler to use <form> submission? [1] http://dev.w3.org/2006/webapi/XMLHttpRequest-2/Overview.html#the-formdata-interface / Jonas
Received on Tuesday, 16 February 2010 03:48:04 UTC