W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] canvas, img, file api and blobs

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 16 Feb 2010 03:48:04 -0800
Message-ID: <63df84f1002160348v62cb08b2j1fe78848df3fa87b@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC