- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 2 Jun 2010 16:00:37 -0700
- To: arun@mozilla.com
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Wed, Jun 2, 2010 at 3:57 PM, Arun Ranganathan <arun@mozilla.com> wrote: > On 6/2/10 3:48 PM, Eric Uhrhane wrote: >> >> Sure, why not? Why would this be limited to File objects? >> >> A File is supposed to refer to an actual file on the local hard drive. >> A Blob is a big bunch of data that you might want to do something >> with. There's nothing special about a File when it comes to what >> you're doing with the data. >> >> Just as we moved File.url up to Blob, I think File.readAsDataURL >> belongs there too. >> > > Fair enough; I'm amenable to moving it. So specifically, you're okay with a > DataURL on a Blob? It might not be anything useful; with a File, you at > least have the possibility of a whole unsliced image file. Could you give > me a use case where this is really useful for Blob objects? One that's come up for Blob.url is a packed file of image thumbnails: you can do one big download, then slice and display the pieces. If you're doing any display by data URLs, that would work there too. To be honest, I think a lot of the data URL use cases are better served by Blob.url anyway, so I'm not sure how many will remain once this spec is fully implemented, but can you think of a data URL use case that really depends on the data coming from a File on disk instead of a Blob? > Also, above you probably mean specifying that readAsDataURL (a method on > FileReader) works on Blob objects, not "File.readAsDataURL" ;-) Yeah. Brain-o.
Received on Wednesday, 2 June 2010 23:01:26 UTC