- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jan 2010 15:12:44 -0800
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
Received on Thursday, 7 January 2010 15:12:44 UTC