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 <jo...@sicking.cc> wrote: > On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Thu, Jan 7, 2010 at 2:27 PM, João Eiras <jo...@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 >