Re: Updates to File API


In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob.  Is
that just an oversight, or is that an intentional restriction?


On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan <> wrote:
> Greetings WebApps WG,
> I have updated the editor's draft of the File API to reflect changes that
> have been in discussion.
> Notably:
> 1. Blobs now allow further binary data operations by exposing an ArrayBuffer
> property that represents the Blob.  ArrayBuffers, and affiliated "Typed
> Array" views of data, are specified in a working draft as a part of the
> WebGL work [1].  This work has been proposed to ECMA's TC-39 WG as well.  We
> intend to implement some of this in the Firefox 4 timeframe, and have reason
> to believe other browsers will as well.  I have thus cited the work as a
> normative reference [1].  Eventually, we ought to consider further read
> operations given ArrayBuffers, but for now, I believe exposing Blobs in this
> way is sufficient.
> 2. url and type properties have been moved to to the underlying Blob
> interface.  Notably, the property is now called 'url' and not 'urn.'  Use
> cases for triggering 'save as' behavior with Content-Disposition have not
> been addressed[2], although I believe that with FileWriter and
> BlobBuilder[3] they may be addressed differently.  This change reflects
> lengthy discussion (e.g. start here[4])
> 3. The renaming of the property to 'url' also suggests that we should cease
> to consider an urn:uuid scheme.  I solicited implementer feedback about URLs
> vs. URNs in general.  There was a general preference to URLs[5], though this
> wasn't a strong preference.   Moreover, Mozilla's implementation currently
> uses moz-filedata: .  The current draft has an editor's note about the use
> of HTTP semantics, and origin issues in the context of shared workers.  This
> is work in progress; I have removed the section specifying urn:uuid and hope
> to have an update with a section covering the filedata: scheme (with
> filedata:uuid as a suggestion).  I welcome discussion about this.  I'll
> point out that we are coining a new scheme, which we originally sought to
> avoid :-)
> 4. I have changed event order; loadend now fires after an error event [6].
> -- A*
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]

Received on Wednesday, 2 June 2010 22:43:09 UTC