[whatwg] Make the files attribute of the input element writable
Ian Hickson
ian at hixie.ch
Wed Dec 5 09:11:12 PST 2012
On Wed, 5 Dec 2012, Victor Costan wrote:
>
> There was a thread on this mailing list discussing making it possible to
> set the file data behind an <input type="file"> element.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140
>
> The thread seems to have died down due to insufficient applications for
> the proposal.
Actually the reason this thread hasn't gone anywhere is that there seems
to only be implementer interest from Chrome.
See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest
> 1) This would make it possible to write JavaScript libraries that
> seamlessly scan the current page for <input type="file"> and add
> integration with Dropbox / Google Drive / Sky Drive etc. I claim that
> changing the <input> value is the easiest and most robust method of
> achieving this without requiring changes to the main application code.
> Asides from providing an easy path for developers to integrate online
> storage services into their apps, this change would make it easy to
> write bookmarklets / browser extensions that add this functionality to
> any Web application.
It seems like this use case would be better handled by having the sites
offer an API to the browser, similar to Web Intents, for picking a file.
That way you wouldn't need to update each site -- every site would support
all the drive systems you use.
> 2) If I can set the files attribute of an <input type="file">, I can
> write unit tests for any code that deals with such an <input>, such as
> XHR uploads. Tested code is less likely to break down as it is
> maintained, so it makes for a better Web.
That's an interesting use case, indeed.
> 3) Browser extensions / bookmarklets could easily filter files being
> uploaded. For example, an extension could automatically resize pictures
> larger than a certain threshold by rendering them to an off-screen
> <canvas>. As another example, an extension could detect when huge files
> are uploaded to a Web mail client or forum, automatically upload them to
> Dropbox / Google Drive / Sky Drive, and replace them in the <input
> type="file"> with tiny ".url" files pointing to the real files.
In general, browser extensions don't have to be handled by Web standard
APIs, so I'm not sure that's a compelling use case.
> With these applications in mind, I don't think FileList needs to accept
> Blobs. Instead, there should be an easy way to build a File out of a
> Blob and a file name. This capability seems to have been lost when
> BlobBuilder was deprecated by the Blob constructor.
There are places where FileList definitely needs to be readonly, so I
don't think it makes sense to make it globally writable. but there could
be a MutableFileList or something. That feedback should be sent to the
list mentioned at the top of the File API spec.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list