On Tue, Oct 1, 2013 at 1:44 PM, Ian Hickson <i...@hixie.ch> wrote: > On Thu, 29 Aug 2013, Jonas Sicking wrote: >> On Thu, Aug 29, 2013 at 2:45 PM, Ian Hickson <i...@hixie.ch> wrote: >> > On Thu, 29 Aug 2013, Jonas Sicking wrote: >> >> On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson <i...@hixie.ch> wrote: >> >> > On Fri, 2 Aug 2013, Jonathan Watt wrote: >> >> >> >> >> >> I'm working on Mozilla's implementation of <input type=file> to >> >> >> allow the user to pick a directory. The idea would be that the >> >> >> files in that directory and its subdirectories would be added to >> >> >> the HTMLInputElement.files FileList. >> >> > >> >> > This seems to be dangerous in that it makes it really easy for the >> >> > user to select a single item that expands into tens of thousands if >> >> > not millions of files on a remote disk, which then all have to be >> >> > synchronously enumerated to get the count so that code can then >> >> > itself enumerate through the entire list. >> >> >> >> We don't have to do any enumeration synchronously. It can all happen >> >> off the main thread. The .click() "API" is asynchronous. >> > >> > It's asynchronous to the JS, sure, but at the end of the day the user >> > can't get any work done until it's complete. It's synchronous as far >> > as the user is concerned. >> >> Sure. The alternative is that the user attaches each file separately. > > That's not the only alternative. For example, a third alternative is that > the user's selection (e.g. a directory) is returned quickly, not > pre-expanded, and then any uploading happens in the background with the > author script doing the walk and uploading the files.
It's unclear to me what you are proposing here. Can you elaborate? >> >> > So you wouldn't be able to pick a file and a directory as in the >> >> > example above? That seems unfortunate... >> >> >> >> Unfortunately most OSs doesn't have support for filepickers that can >> >> select either a file or a directory. >> > >> > True. From a UI perspective it's kind of weird that the user has to >> > decide which he wants, though. Similarly, from an authoring >> > perspective, I don't understand how I would decide whether to show a >> > multiple file picker or a directory picker. >> >> You display two buttons in the website UI, one for "pick file" and one >> for "pick directory". We don't really have a choice as long as we live >> under the two constraints of: >> >> * Websites wants to do their own "pick" UI >> * OSs can't display pickers which allow picking either a file or a directory. > > I don't think I've ever seen a native application on any platform offer > two buttons, one to pick one or more files, and one to pick one (or more?) > directories. I think this should be a large red flag. Now if I'm wrong and > this kind of UI is in fact a thing, then fair enough, but if it's not, > maybe we should go and study how this problem is solved in native apps. So the issue is that most applications doesn't have the concept of "import/open a large set of files". I.e. most applications just lets you open a single file. The first application that I could think of that is designed for opening or importing large number of files is iTunes. And indeed on windows where there is no native "open file or directory" widget, they use separate menu items for "import file" and "import folder". On OSX iTunes relies on the combined file-or-folder picker that's not available on windows. Do you have example of other windows applications which support opening/importing both files and folders? How do they solve it? Of course, we could argue that supporting attaching a whole directory tree to a webpage is not an important use case. However given that all of windows/osx/linux does have a directory picker, this seems to indicate otherwise. Another strong indication is that both Chrome and Firefox has deemed it important enough to add support for it. We added it to Firefox in response from requests from Mega and various Google properties. Mega even went so far as to write a firefox addon to support directory picking. / Jonas
