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

[whatwg] HTMLCanvasElement.toFile()

From: Shumpei Shiraishi <shumpei.shiraishi@gmail.com>
Date: Fri, 8 Jan 2010 10:27:36 +0900
Message-ID: <104ce6581001071727y5d09e595j142cb1c26c8ced28@mail.gmail.com>
Hi.

I think the method name "toFile()" is missleading, because I agree to
the Maciej's openion.

> I don't think using File for temporary in-memory binary data, as opposed to a file on disk, makes sense.

So, how about changing the method name to "toBlob()" and signature as follows?

Blob toBlob(in optional DOMString type, in any... args);

--Shumpei

On Fri, Jan 8, 2010 at 8:15 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Thu, Jan 7, 2010 at 2:27 PM, Jo?o Eiras <joaoe at opera.com> wrote:
>>>
>>>>> 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.
>>>
>>> How about just overloading xhr.send() to handle a <canvas> element ?
>>
>> I'm reluctant to overload the meaning of sending an Element object.
>> When a Document is passed to xhr.send() we already serialize that
>> document into markup, it seems likely to me that in the future we'll
>> want to do the same thing for Elements.
>
> Additionally, this doesn't allow specifying the encoding type, such as
> JPEG or PNG, or encoding parameters, such as JPEG quality.
>
> / Jonas
>
Received on Thursday, 7 January 2010 17:27:36 UTC

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