[whatwg] canvas, img, file api and blobs

Jonas Sicking jonas at sicking.cc
Tue Feb 16 03:48:04 PST 2010

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

More information about the whatwg mailing list