- From: Ian Fette <ifette@google.com>
- Date: Thu, 10 Dec 2009 22:16:44 -0800
2009/12/10 Jonas Sicking <jonas at sicking.cc> > 2009/12/10 Ian Fette (????????) <ifette at google.com>: > > USE CASE: > > Many sites allow you to upload multiple files, often images. HTML5 allows > > this via <input type="file" multiple>. This works well when your files > are > > all in one folder, but it may often be the case that files are spread > across > > sub-folders, and in this case you have to do multiple transactions (or > > multiple <input type=file multiple> tags, which is just awkward) to > upload > > your files. > > PROPOSAL: Allow a UA to recursively select and upload a directory of > files. > > How the UA chooses to modify the file picker dialog is outside the scope > of > > this spec, but for the sake of argument, assume that the UA lets you pick > a > > folder and say "upload all". Allow the UA to upload the files in the > folder, > > with the subdirectories included in the filename with a directory > separator. > > E.g. assume I have: > > C:\users\ian\a\b\1.jpg > > C:\users\ian\a\b\2.jpg > > C:\users\ian\a\c\3.jpg > > If the user chooses "a", the UA should be allowed to send all three files > > with filenames: > > "a/b/1.jpg" > > "a/b/2.jpg" > > "a/c/3.jpg" > > as it would for the existing <input type=file multiple> implementation, > with > > the addition of the directories and path separators (not full path, just > the > > directory the user chose and sub-paths.) > > Thoughts? > > I don't think there is anything in the spec preventing you from doing > this right now. The fact that only files in the same folder can be > selected is a limitation in the implementation, not a limitation in > the spec. > > The spec does require that only the leaf name, without any paths, are > submitted. Is that a problem? > Perhaps not a show stopper, but I think it's sub-optimal. E.g. if I am using a client application, I can point it to my "My Photos" directory and it can infer some album structure from how I've organized my photos. It would be nice if a web photo app could do the same. > > I guess I'd be ok with changing the spec to allow more of the path to > be exposed. However that would mean that there is a mismatch between > what name is submitted and what name you'd get from > input.files[n].name. > > I think that the notion of allowing more of the path to be exposed and reconciling that with .name is where the problem lies, and would like to figure out if we could resolve that. I think that there is a case to be made for including the paths -- e.g. if I'm uploading photos to flickr, picasa, or facebook, I may have already organized them locally, there's no reason that I shouldn't be able to maintain that structure when I upload to the web application. The question is then how that gets reconciled with input.files[n].name -- I would think it preferable if .name also were allowed to contain that extra information -- currently we say "The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information." [1]. I guess I would propose that be changed to "The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList." Again, open to suggestions of how this could be accomplished in a better way. [1] http://www.w3.org/TR/FileAPI/#dfn-name / Jonas > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/a84e3143/attachment.htm>
Received on Thursday, 10 December 2009 22:16:44 UTC