[whatwg] Proposing <canvas>.toBlob(contentType)

[Jonas Sicking]

On Wed, Apr 13, 2011 at 11:42 PM, Kyle Huey <me at kylehuey.com> wrote:
> It doesn't necessarily imply that the encoding is synchronous.
>
> The problem here is that Blob.size is broken.  The point of the File API is
> to do reads asynchronously without blocking the main thread on something
> slow.  This is why the only way to get at a Blob's contents is through
> something like FileReader which is asynchronous and event driven.  Blob.size
> goes totally against all of this.  I wonder if it's possible to remove size
> entirely?  Jonas?  It's been shipped in Firefox since 3.5 though, and Chrome
> since some version from quite a while ago, so I fear it's here to stay.

Yeah, I think the current Blob and File interfaces are here to stay.
Not just because they have shipped, but because in all other
situations access to the File/Blob object is asynchronous, and so
providing synchronous access to metadata makes a lot of sense.

However, we could possibly come up with something like a UnsizedBlob
interface. We could possibly even make that a base-class of the normal
Blob interface. However it would mean introducing a lot of complexity.
All functions that currently take Blob should be changed to take
UnsizedBlob. And how would something like BlobBuilder work? Would it
return an UnsizedBlob or a Blob?

Unless we can come up with other APIs where a UnsizedBlob would make
sense, I'm tempted to say that we should use an asynchronous callback
here.

/ Jonas