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

[whatwg] canvas, img, file api and blobs

From: Stef Epardaud <stef@epardaud.fr>
Date: Tue, 16 Feb 2010 10:58:23 +0100
Message-ID: <20100216095823.GA20363@inforealm.org>
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.
-- 
St?phane Epardaud
Received on Tuesday, 16 February 2010 01:58:23 UTC

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