[whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

On Thu, Jan 7, 2010 at 2:22 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> 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.

The difference between a binary blob of data, and the image extracted
from a canvas element, is that the latter has a mimetype. This is
extra important here since if you call:

result = canvas.toFile("", "image/jpeg");

you won't know if the data in result is encoded as "image/jpeg", or
"image/png", since support for jpeg encoding is optional.

I don't really feel strongly about if a File object is extracted or
not, but I do think that the mimetype needs to be returned somehow, so
that it can be passed on the the XHR call. Use a File just happens to
be a convenient way to do this.

/ Jonas