- From: Ojan Vafai <ojan@chromium.org>
- Date: Wed, 23 May 2012 19:01:20 -0700
- 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 be. 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