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

[Victor Costan]

On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> 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

Thank you very much for explaining!

I can file a bug against Firefox, and argue for it. I think I would
have an easier time making an argument if I knew how the API should
look like. Can you please give me a hint as to which variant you'd be
more likely to agree with? Mutable FileLists vs a  way to put together
a new FileList + writable files attribute on <input type="file">? File
constructor taking a Blob + name vs having Blobs in a FileList?

>> 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.
>

Yes, but that approach would require deeper application changes. I
think that adding a couple of <script> tags next to an existing <input
type="file"> is easier to implement.

>> 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.

Thank you! In general, read-only APIs make testing really hard :(

>> 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.

I think it would be useful to have a drop-in JS library that can
perform image resizing on the fly without requiring XHR-based form
submission.

>> 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.

FileList doesn't have to be mutable if there is a FileList constructor
that accepts File instances, or if the files attribute of <input
type="file"> accepts an array of File instances and converts it into a
FileList.

I will start a discussion on the public-webapps at w3.org. For reference,
they seem to be in favor of a File constructor.
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0692.html


Thank you very much for your consideration,
    Victor