[whatwg] Make files attribute of the input element writable
ojan at chromium.org
Wed May 23 19:01:20 PDT 2012
On Tue, May 22, 2012 at 6:38 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Tue, May 22, 2012 at 10:41 AM, Nico Weber <thakis at chromium.org> wrote:
> > Hi,
> > The files attribute of the input element is currently marked readonly
> > , 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:
> > 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 at 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.
More information about the whatwg