shumpei.shiraishi at gmail.com
Thu Jan 7 17:27:36 PST 2010
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);
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
More information about the whatwg