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

[Garrett Smith]

On 1/17/13, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 7 Dec 2012, Victor Costan wrote:
>> 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?
>
> Whatever browsers are willing to implement, basically.
>
>
>> >> 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.
>
> On the one hand, we require every application that can read a file to
> modify their code to support the "drive" providers, and we require the
> drive providers to provide code to support this, and we need UA changes,
> and we make it hard to competitors of drive-like products to compete
> (since anyone popular enough to be included by the sites that support this
> will have a network effect advantage).
>
> On the other hand, we require only "drive" providers and user agents to
> write code, and every site that reads files supports every provider that
> implements the API, and there's no barrier to entry for competitors.
>
> I think the second is _significantly_ better all around.
>
> But there are other use cases (such as the ones you listed) for which it
> makes sense to be able to add files to <input type=file>.
>
>
>> > 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.
>
> Indeed, both of those solutions would work too. There could also be a
> method on HTMLInputElement to push files into .files, or to clear .files,
> or some such.

The file input's value, as useless as it is, should stay in sync with
the fileList. Any method to clear the files must also reset the
input's value to "".
.
A few ideas:
  fileInp.value = ""; // change an old property's behavior
  fileInp.files.length = 0; // changes a recent property's behavior
  fileInp.reset(); // old method name on new object
  fileInp.clear(); // new method name, new behavior (no conflict).
-- 
Garrett
Twitter: @xkit
personx.tumblr.com