[whatwg] Make files attribute of the input element writable

[Ojan Vafai]

On Wed, May 23, 2012 at 7:11 PM, Nico Weber <thakis at chromium.org> wrote:

> On Wed, May 23, 2012 at 7:01 PM, Ojan Vafai <ojan at chromium.org> wrote:
> > On Tue, May 22, 2012 at 6:38 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >> I don't think simply marking the attribute as writable is the correct
> >> solution here. At the very least we should make it possible to assign
> >> a sequence<File> to the attribute such that you can do:
> >>
> >> myInput.files = [file1];
> >>
> >> But even a sequence<Blob> should be allowed IMO.
> >
> > Makes sense to me. Can we just kill FileList and always use File[] (or
> > "readonly File[]" for the readonly cases)? The only cases where this is
> used
> > in the HTML spec are file inputs and dataTransfer. We should make
> setting a
> > non-readonly T[] to a sequence<T> work across the platform IMO.
> >
> > Allowing setting a sequence<Blob> could be made to transparently work as
> a
> > followup, no? You should be able to just set myInput.files =
> myBlobSequence.
> > As Anne points out, it's unclear what the UI for this would be.
>
> Is the UI for an array of Files much clearer? With a FileList, the
> selected files were at some point selected by the user from a file
> explorer, so it's fairly likely that an input file picker knows how to
> display them. For a general File[] array, the files might be scattered
> in multiple directories. (And the step from writable FileList to
> File[] array could be done in a transparent follow-up too.)
>

The UI issue with Blob is that Blobs don't have a "name" property, so it's
unclear what you'd show the user.

This decision doesn't affect the UI for Files. The only difference between
FileList and File[] is that you can access the entries using by calling
item(index) in addition to square bracket notation. An alternative would be
to add a setItem method to FileList, but I've been trying to get rid of as
many gratuitous *List methods as possible from the platform. When a *List
method potentially adds value (as in the case of NodeList), it's ok, but
the platform is simpler for everyone if we don't have custom types
everywhere we have a list of things.

Most of these custom list types are just legacy from before WebIDL having
T[] and sequence<T>. You used to have to specify a custom type.

For reference:
FileList: http://dev.w3.org/2006/webapi/FileAPI/#dfn-filelist
File[]: http://www.w3.org/TR/WebIDL/#idl-array