Re: [whatwg] Forms: input type=file and directory tree picking
On Oct 2, 2013 6:51 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 2, 2013 at 7:48 PM, Jonas Sicking jo...@sicking.cc wrote: Proposals for filesystem is just part of what we need. We also need a way to expose it through HtMLInputElement. And a way to allow not exposing the files through .files. Assuming for now that we need separate modes for files and directories, I'd suggest input type=directory, which causes a directory picker to be shown, doesn't populate .files at all, and adds an API entry point to retrieve a filesystem. If somebody suggests an implementable way to expose UI that doesn't need to separate files and directories then we may want something else, but that doesn't seem likely to me. (Implementations could still allow selecting individual files, or groups of files, as long as it's exposed transparently as if they're files in a directory. So, something like type=filesystem might be a better name.) The downside with this approach is that it doesn't work well on systems that doesn't have a filesystem in the traditional sense though. Such as most mobile platforms. I'd rather extend input type=file multiple such that platforms that have directories can expose those, and ones that don't just expose files. And on platforms that have combined file-or-directory pickers can render a single button, and platforms that use separate Widgets can render two buttons. Then we of course need to deal with pages that want to do their own styling... / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
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
Re: [whatwg] Forms: input type=file and directory tree picking
On Wed, Oct 2, 2013 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote: 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? The same thing I did, I think: an API to navigate the directory tree as needed, and to never greedily recursing the directory tree. -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
On Wed, Oct 2, 2013 at 11:52 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 2, 2013 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote: 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? The same thing I did, I think: an API to navigate the directory tree as needed, and to never greedily recursing the directory tree. Unfortunately that's forbidden by current specs. Or rather, the only implementation strategy that I can see for doing that while implementing the current spec would require synchronously traversing the full directory tree whenever element.files is accessed. At least to me that would have performance issues that are unacceptable to Firefox. Though of course you or anyone else is free to propose changes to the spec to improve that situation. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Wed, Oct 2, 2013 at 3:35 PM, Jonas Sicking jo...@sicking.cc wrote: Though of course you or anyone else is free to propose changes to the spec to improve that situation. That's what we're doing: suggesting that we expose an API to navigate the tree. (I'm not proposing actual APIs for this here, since lots of people have done that already in the filesystem API threads, but I hope we can agree that it would be a much better solution.) -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
On Oct 2, 2013 3:47 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 2, 2013 at 3:35 PM, Jonas Sicking jo...@sicking.cc wrote: Though of course you or anyone else is free to propose changes to the spec to improve that situation. That's what we're doing: suggesting that we expose an API to navigate the tree. (I'm not proposing actual APIs for this here, since lots of people have done that already in the filesystem API threads, but I hope we can agree that it would be a much better solution.) Proposals for filesystem is just part of what we need. We also need a way to expose it through HtMLInputElement. And a way to allow not exposing the files through .files. Actually, a filesystem might not even be needed. We could just expose an asynchronous iterator. Again, and with extra oomph, proposals welcome. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Wed, Oct 2, 2013 at 7:48 PM, Jonas Sicking jo...@sicking.cc wrote: Proposals for filesystem is just part of what we need. We also need a way to expose it through HtMLInputElement. And a way to allow not exposing the files through .files. Assuming for now that we need separate modes for files and directories, I'd suggest input type=directory, which causes a directory picker to be shown, doesn't populate .files at all, and adds an API entry point to retrieve a filesystem. If somebody suggests an implementable way to expose UI that doesn't need to separate files and directories then we may want something else, but that doesn't seem likely to me. (Implementations could still allow selecting individual files, or groups of files, as long as it's exposed transparently as if they're files in a directory. So, something like type=filesystem might be a better name.) Actually, a filesystem might not even be needed. We could just expose an asynchronous iterator. A use case is an image viewer for photographers, allowing the user to open a directory possibly containing tens of thousands of files. The image viewer should be able to allow the user to navigate through directories. An iterator couldn't do that--it could only grab the files in the order they happen to come in. Also, if the page already knows that the last image the user viewed is 2013/sunset.jpg, and the user opens the same directory, the page should be able to grab the same file by its filename immediately if it still exists, without having to iterate. Again, and with extra oomph, proposals welcome. I'd need to review the threads first, but I'll try to get to that and see if I have any new suggestions. The last thing I remember is movement away from the Filesystem API, and a lighter API being proposed, but I don't recall where that left off. -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
On Tue, Oct 1, 2013 at 3:44 PM, Ian Hickson i...@hixie.ch wrote: * 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. I can't find any applications off-hand which allow both in the first place, but Windows doesn't have a dialog that can do both. Typically you end up with two separate buttons/menu items, but presented as separate features, eg.Open File and Import Directory. (Drag and drop doesn't need to make this distinction. I'm not sure what should happen if you have a files input, and drag a directory into it that you couldn't have selected with the file picker.) -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
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. The advantage of avoiding the need for the 'directory' attribute would be that directory picking would work for existing content with input type=file multiple without needing to be changed. One disadvantage would be that existing content may depend on the file names in the FileList being unique. I would have liked the file names to still be unique, by prefixing the names with the relevant parts of the subpaths (that is, if I select foo.txt and bar/ which contains another foo.txt, .files would contain foo.txt and bar/foo.txt), but I think that ship sailed (and now the spec explicitly requires otherwise). We would change the File interface to add a 'path' property, which would be the path (without the file name) of the file relative to the directory that was picked. That might work. Currently authors can use HTMLInputElement.click() to open a system file picker. To give content the ability to open a system directory picker we'd add a corresponding .openDirectoryPicker() function. So you wouldn't be able to pick a file and a directory as in the example above? That seems unfortunate... In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD Wow. That's... not great in a UI. so depending on what the page is doing, directory picking could take some time. To allow content authors with styled input to provide feedback to users during scans of large directory trees we plan to have openDirectoryPicker return a ProgressPromise: https://github.com/slightlyoff/Promises/blob/master/ProgressFuture.idl We'd then fire progress events at the promise specifying how many files had been processed so far. I feel very uncomfortable with the idea that we'd intentionally have an expensive API like this. But I guess I don't really know what the use cases are, so it's hard to evaluate. Anyway, I don't have a better suggestion right now. What has the implementation experience been like so far? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
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. The advantage of avoiding the need for the 'directory' attribute would be that directory picking would work for existing content with input type=file multiple without needing to be changed. One disadvantage would be that existing content may depend on the file names in the FileList being unique. I would have liked the file names to still be unique, by prefixing the names with the relevant parts of the subpaths (that is, if I select foo.txt and bar/ which contains another foo.txt, .files would contain foo.txt and bar/foo.txt), but I think that ship sailed (and now the spec explicitly requires otherwise). We discussed this. However many people has expressed that they expect the .name property to only contain the leaf name. Trying to tell people that the name is unique and may or may not include pieces of path has lead to lots of confusion. Instead we'll ensure that path+name is unique. At least unique within a single selection. We're planning on eventually letting users bring up filepickers multiple times and select additional files each time. Currently authors can use HTMLInputElement.click() to open a system file picker. To give content the ability to open a system directory picker we'd add a corresponding .openDirectoryPicker() function. 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. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms: input type=file and directory tree picking
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. Which, while means smaller synchronous actions, is not really a better UX. In other words, synchronousness is not the only design constraint here. 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. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Thu, Aug 29, 2013 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote: 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. Which, while means smaller synchronous actions, is not really a better UX. In other words, synchronousness is not the only design constraint here. The alternative is to provide an interface that explores the supplied directory on-demand, as the page needs it, rather than greedily scanning the entire directory before giving it to script. Scanning a large directory tree in advance is almost never what applications or users want. A static file list isn't a sensible API for recursively exposing directory trees. -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
On 02/08/2013 23:39, Glenn Maynard wrote: On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt jw...@jwatt.org wrote: In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD; so depending on what the page is doing, directory picking could take some time. A static list isn't appropriate for recursively exposing a large directory. I hope that won't be implemented, since that's the sort of halfway-feature--not quite good enough, but it sort of works--that can delay a good API indefinitely. An interface to allow scripts to navigate the tree like a filesystem should be used, to avoid having to do a full recursion. I see this more as a means of getting directory picking working in the existing content out there that's using file pickers without requiring that content to be updated (which is not going to happen in the vast majority of cases). I would hope that it would not _prevent_ a filesystem-like API from being implemented, although I agree it would inevitably reduce the pressure for such an API. That said, such an API that everyone agrees on doesn't seem to be materializing any time soon. For example, a photo browser probably only wants to read data on demand, as the user navigates. Also, doing it synchronously means that if the user adds another photo, he'd have to reopen the directory (and wait for the long recursion) all over again for it to be seen by the app. A previous discussion (on drag and drop, but the issues are the same) is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html Thanks for the link. I've read through that thread. -Jonathan That centered around FS-API, which is probably not the direction things are going, but whichever API things land on for filesystem access should probably be used for this--or vice-versa, if this comes first. I suspect they're actually the same thing, since a file picker (along with drag and drop) is the likely way to expose a filesystem-of-real-files API.
Re: [whatwg] Forms: input type=file and directory tree picking
On 05/08/2013 00:54, Glenn Maynard wrote: On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote: We can't do what you are suggesting for a plain input type=file multiple since there's already a defined API for that, and that API only exposes a .files property in the DOM. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. Currently my own view is that exposing a filesystem type API must be opt-in (as in new code has to be written to use it; old code isn't going to just work). As such a new attribute [value] such as multiple=fs could be required to make use of it, and could change the behavior of the input so that it doesn't build up a FileList, but instead sets .files to an object representing the picked directory if a directory is picked. -Jonathan But we could certainly add some way to enable creating an input which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. It also requires an actual proposal for what such an input would look like. I.e. would it be an input type=file directory? Or input type=file multiple with some sort of API call saying that flattening directories into files aren't needed? Or input type=filesanddirectories? It's probably not worth worrying about this part too much until we have a filesystem API for it to enable. Any of these seem fine (though I'd lean away from an API call), or maybe input type=file multiple=fs, which would cause it to fall back on the current (files only, non-recursive FileList) behavior on browsers that don't support it. (I don't think flattening directories into files is something that should ever happen in the first place, but if it does we'd definitely need to make sure it doesn't happen in this mode.)
Re: [whatwg] Forms: input type=file and directory tree picking
On Fri, Aug 2, 2013 at 3:39 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt jw...@jwatt.org wrote: In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD; so depending on what the page is doing, directory picking could take some time. A static list isn't appropriate for recursively exposing a large directory. I hope that won't be implemented, since that's the sort of halfway-feature--not quite good enough, but it sort of works--that can delay a good API indefinitely. An interface to allow scripts to navigate the tree like a filesystem should be used, to avoid having to do a full recursion. For example, a photo browser probably only wants to read data on demand, as the user navigates. Also, doing it synchronously means that if the user adds another photo, he'd have to reopen the directory (and wait for the long recursion) all over again for it to be seen by the app. A previous discussion (on drag and drop, but the issues are the same) is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html That centered around FS-API, which is probably not the direction things are going, but whichever API things land on for filesystem access should probably be used for this--or vice-versa, if this comes first. I suspect they're actually the same thing, since a file picker (along with drag and drop) is the likely way to expose a filesystem-of-real-files API. We can't do what you are suggesting for a plain input type=file multiple since there's already a defined API for that, and that API only exposes a .files property in the DOM. But we could certainly add some way to enable creating an input which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. It also requires an actual proposal for what such an input would look like. I.e. would it be an input type=file directory? Or input type=file multiple with some sort of API call saying that flattening directories into files aren't needed? Or input type=filesanddirectories? / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote: We can't do what you are suggesting for a plain input type=file multiple since there's already a defined API for that, and that API only exposes a .files property in the DOM. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. But we could certainly add some way to enable creating an input which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. It also requires an actual proposal for what such an input would look like. I.e. would it be an input type=file directory? Or input type=file multiple with some sort of API call saying that flattening directories into files aren't needed? Or input type=filesanddirectories? It's probably not worth worrying about this part too much until we have a filesystem API for it to enable. Any of these seem fine (though I'd lean away from an API call), or maybe input type=file multiple=fs, which would cause it to fall back on the current (files only, non-recursive FileList) behavior on browsers that don't support it. (I don't think flattening directories into files is something that should ever happen in the first place, but if it does we'd definitely need to make sure it doesn't happen in this mode.) -- Glenn Maynard
Re: [whatwg] Forms: input type=file and directory tree picking
On Sun, Aug 4, 2013 at 4:54 PM, Glenn Maynard gl...@zewt.org wrote: On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote: We can't do what you are suggesting for a plain input type=file multiple since there's already a defined API for that, and that API only exposes a .files property in the DOM. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. We would also have to expose all files in the selected directory through HTMLInputElement.files, which brings the performance issues that Jonathan is talking about. But we could certainly add some way to enable creating an input which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. Help welcome. / Jonas
Re: [whatwg] Forms: input type=file and directory tree picking
On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt jw...@jwatt.org wrote: In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD; so depending on what the page is doing, directory picking could take some time. A static list isn't appropriate for recursively exposing a large directory. I hope that won't be implemented, since that's the sort of halfway-feature--not quite good enough, but it sort of works--that can delay a good API indefinitely. An interface to allow scripts to navigate the tree like a filesystem should be used, to avoid having to do a full recursion. For example, a photo browser probably only wants to read data on demand, as the user navigates. Also, doing it synchronously means that if the user adds another photo, he'd have to reopen the directory (and wait for the long recursion) all over again for it to be seen by the app. A previous discussion (on drag and drop, but the issues are the same) is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html That centered around FS-API, which is probably not the direction things are going, but whichever API things land on for filesystem access should probably be used for this--or vice-versa, if this comes first. I suspect they're actually the same thing, since a file picker (along with drag and drop) is the likely way to expose a filesystem-of-real-files API. -- Glenn Maynard
