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

[whatwg] HTMLCanvasElement.toFile()

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 07 Jan 2010 14:22:35 -0800
Message-ID: <A5B44B60-EFFF-4299-97E8-1740C90F344F@apple.com>

On Jan 7, 2010, at 11:41 AM, Jonas Sicking wrote:

> Hi web fans,
>
> So at mozilla we've been implementing and playing around with various
> File APIs lately. One of the most common use cases today for file
> manipulation is photo uploaders. For example to sites like flickr,
> facebook, twitpic and icanhascheezburger. Some of these sites allow
> additional modifications of the uploaded image, most commonly cropping
> and rotating the image. But even things like manipulating colors,
> adding text, and red eye reduction are things that sites do, or would
> like to do.
>
> We do already have a great tool for image manipulation in HTML, the
> canvas element. However if a site wants to upload the resulting image,
> after the modifications, things become more painful. Currently you
> have to call toDataURL(), send that URL using XMLHttpRequest, and then
> serverside convert to binary data. Things will be a little better once
> XHR supports sending manually constructed binary data, but you still
> have to manually convert the data url to binary data in javascript.
>
> I suggest we add a function like:
>
> File toFile(in DOMString name, in optional DOMString type, in any...  
> args);
>
> This function takes the same arguments as toDataURL(), plus an
> additional 'name' argument. It produces the same result as
> toDataURL(), except that it returns the result as a File object rather
> than as a data-url encoded string. This can then be directly sent
> using XMLHttpRequest.

I think it would make more sense to have an actual type for binary  
data (for example along the lines of my proposal on public-script- 
coord and es-discuss) and enable getting one from <canvas> and sending  
via XHR. I don't think using File for temporary in-memory binary data,  
as opposed to a file on disk, makes sense. The File should stick to  
representing files. After all, you would not make a File object to  
convert something to text for uploading. Nor would it make sense to do  
an asynchronous read from this. And under the covers, you would want  
to pass the actual binary data to the upload code, not a file with a  
file name.

Regards,
Maciej
Received on Thursday, 7 January 2010 14:22:35 UTC

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