[whatwg] Make the files attribute of the input element writable

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'