- From: Shumpei Shiraishi <shumpei.shiraishi@gmail.com>
- Date: Fri, 8 Jan 2010 10:27:36 +0900
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