Re: Please add constructors for File and FileList

Greetings Victor!


On Dec 10, 2012, at 12:02 PM, Victor Costan wrote:

> Dear Web Applications WG,
> 
> 1) Please add a File constructor.


This has cropped up a few times :)  I've logged a spec bug for this feature: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887

Could you flesh out your original use case a bit more?  As currently expressed, it sums up to "I could write better unit tests" which doesn't constitute what I'm looking for in a use case.

It strikes me that the chief ask is to bind a Blob to name.  This would make life simpler with FormData and with existing server applications.  It's been pointed out that the barrier between Blob and File is pretty thin, and I'm open to jettisoning the thought pattern that we should think of File objects as strictly filesystem backed ("on disk").  So, what if we allowed the Blob constructor to take a name also?  This might allow Blobs to fall into the "80" of the "80-20" rule :)  

Could you update the bug (or this listserv) with better use cases?  

I'm a bit less upbeat about:


> 2) Please add a FileList constructor.
> 
> What I really want is "some way to add files to an <input
> type="file">" listed in
> http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest
> 
> I think that one reasonable way to get there is to have a FileList
> constructor that takes an array of File instances, and have the
> ability to assign that FileList to the files attribute of the <input>.
> This avoids making FileList mutable.
> 
> This would also help me write better tests for my code. Currently,
> <input type="file"> is the only form field whose value can't be set
> inside JavaScript, so I can't write automated tests for <input
> type="file">-related code.
> 
> Asides from improving testing, this would allow me to implement the
> following _easily_:
> 
> * "filters" for uploaded content (e.g. resize a big image before uploading)
> * "saving" the file a user selected in an IndexedDB, and "loading" it
> back into the <input type="file"> if the page is accidentally
> refreshed
> 
> These features can be implemented without FileList support, but they
> impact the application's design. For example, filters can be
> implemented using FormData from XMLHttpRequest level 2 to upload
> Blobs, but switching from plain form submission to XHR-based
> submission can impact other parts of the application code, whereas
> changing the files behind the <input> would be a localized change.


As it stands currently, a FileList object typically stems from user action.  For instance, interacting with the file picker or with drag and drop.  In general, this model is desirable for security reasons -- the legacy HTML form and file picker ensures that web applications aren't doing things they shouldn't be doing with the underlying file system without user participation. I don't actually think it is desirable to modify <input type = "file"…> from within JavaScript.

I'd like a better understanding of the broader implications of a FileList constructor, just out of abundant caution.  I have similar concerns about https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 which is also filed on the FileList object, but these seem easier to manage.

Hope to hear back,

-- A*

Received on Wednesday, 6 February 2013 18:12:18 UTC