W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 23 May 2012 19:01:20 -0700
Message-ID: <CANMdWTt6ttiRKGPk0+FEcYiY6=A2=q8n=vHZfF69d8ypMhr1Vw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: whatwg@whatwg.org, Nico Weber <thakis@chromium.org>
On Tue, May 22, 2012 at 6:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, May 22, 2012 at 10:41 AM, Nico Weber <thakis@chromium.org> wrote:
> > Hi,
> >
> > The files attribute of the input element is currently marked readonly
> > [1], to protect from `myInput.files = "/etc/passwd"; myForm.submit()`.
> > Since its type is now FileList and not string, that's no longer
> > necessary.
> >
> > Making the attribute writable would allow setting the files property
> > of an input element to dataTransfer.files from a drop handler. For
> > example, I would like to use this to create a larger drop-target for a
> > file input. Here's one request for this functionality:
> >
> http://stackoverflow.com/questions/8006715/drag-drop-files-into-standard-html-file-input
> >
> > Can the readonly restriction be removed from the spec?
> 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

Jonas, if killing FileList and using File[] makes sense to you, I'm happy
to send an email to public-webapps to that effect for the File API spec.

> One concern I have though is that this is pretty problematic UI-wise.
> Simply displaying the .name (if it's a file) property in the UI seems
> like a good way to scare people into thinking that they have attached
> something that they didn't.

What exactly is the concern here? Is it a security concern? If it's just a
correctness concern, then it's on the web page to do something sane with
the API. I don't think the API is especially inviting the page to do things
that would confuse the user. For example, in Nico's case, it's actually the
same set of files the user-dropped, it just widens the drop-target. I would
imagine things like this would be how nearly everyone would use this.

On Tue, May 22, 2012 at 9:16 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> It seems like making FileList mutable would serve the same use case and
> would also be more flexible (as you could upload a set of files collected
> from possibly multiple sources). And it seems like adding is a more likely
> desired behavior than replacing when dragging files onto a multi-file input.

Making it a File[] instead of a FileList could allow you to set the whole
thing or modify it. There are legit use-cases for both and supporting both
isn't terribly difficult.
Received on Thursday, 24 May 2012 02:02:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:13 UTC