[whatwg] Proposing <canvas>.toBlob(contentType)
jonas at sicking.cc
Wed Apr 27 02:14:34 PDT 2011
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
More information about the whatwg